Enterprise Integration Patterns in the Agentic Era, Part 1: Why EAI, SOA and API Integration Break When the Caller Is an Agent
Every generation of integration architecture was a bet on who the caller is. The caller is now a reasoning agent, and most of what we built for the last one will not survive unchanged.
"Integration is where architecture meets the organisation. Every seam in the system is a seam in the company."
The problems this article is about
If you run technology for a university, a payments firm or any organisation with more than a handful of systems, these five questions are probably already on your desk. If they are not, they will be within a budget cycle.
- We have an integration platform already — an ESB, an iPaaS, an API gateway. Why does it stop working the moment an AI agent tries to use it?
- Our canonical data model took three years to agree. Is it an asset or a liability when agents are doing the integrating?
- Every integration we have was written for one consumer. How does an agent that composes systems at run time even find them, let alone use them safely?
- Where do the rules live? The "never refund more than the original payment" logic is in the checkout app. The agent calling the refund API has never heard of it.
- When an agent-driven integration does something wrong, what do we show the auditor, the regulator or the student appeals board?
These are integration questions, not AI questions. The AI is simply the thing that makes the old answers stop working.
How our R&D wing is working on it
The Software Lens is the research and development wing of Aitina Tech. We do not have the luxury of theorising about integration: the consulting practice integrates student record systems, ledgers, CRMs and payment processors for clients, and every one of those engagements is now asked "can an agent use this?" So we are doing three things, and this series reports on them as they happen.
First, we are re-reading the integration canon — Gregor Hohpe and Bobby Woolf's Enterprise Integration Patterns, Martin Fowler's writing on integration, evolution and migration, and Eric Evans's Domain-Driven Design — against a caller none of those authors had in mind, and recording pattern by pattern what survives. That is the bulk of this article.
Second, we are building it. Nexcubator is Aitina Tech's own product venture and the platform on which the R&D wing applies its research. Its current piece of work is an agentic integration layer between two systems of record — the HR platform and the finance ledger — built on capabilities rather than connectors. The experiment is described next; its findings will be Part 3.
Third, we publish the reasoning in the open so it can be argued with. Nothing here is a vendor position. Where we are wrong, we would rather find out in print than in a client's production estate.
The Nexcubator experiment: two systems, joined two ways
Nexcubator is the platform on which our R&D wing applies this research, and its current integration work is deliberately ordinary: the HR platform (people, roles, retention signals) and the finance ledger (budgets, payroll, cost centres). Every organisation has this pair. Today they are joined the way most systems are — a nightly connector moves records across, and the rules about what finance may see live inside the HR application, where no other caller can find them.
A manager asks: "If my two flight-risk engineers leave, what does it cost this quarter, and what retention budget do I have?" Today that is two exports, an analyst, a spreadsheet and two days — and nobody can say afterwards which rule decided what was shared.
What we are building instead. Each system exposes one capability — people.retention_risk on the HR side, budget.headcount_cost on the finance side — built to the SaaC pattern: Software as a Capability, the framework Aitina Tech's R&D wing pioneered and first published on The Software Lens YouTube channel. Each capability has a description an agent can read, rules it cannot break, and a signed receipt for every call. Each is agentic in its own right: people.retention_risk does not fetch a field, it reasons over tenure, manager changes and market signals and returns an assessment with its evidence. An agent asks both, each decides what it may share, and the manager gets the cost and the budget in seconds, with the reasoning and a receipt the auditor can read.
What we are measuring, so Part 3 has something to say. Whether the rules hold when the caller is no longer the application that used to own them. How much of the old connector turned out to be business rules in disguise. Whether one shared definition of employee, team and cost centre is enough for the agent to compose the two correctly. What the receipts cost to produce and what they are worth to an auditor. And the one that matters to a decision maker: whether this is cheaper to change than the connector it replaces. Part 3 will publish one of these capabilities end to end — manifest, rules, kernel, receipt — as a worked example you can copy, and will say plainly where this article turns out to have been wrong.
If there is an ESB, a canonical model or a connector estate on your desk today and an agent pilot on the way, book a free hour with an integration architect and we will walk it with you.
Three generations of integration, and the assumption underneath each
EAI (1990s) bet on a central team moving data between a few stable systems. Hub-and-spoke brokers, adapters per system, a transformation engine and one team that owned the mappings — TIBCO, webMethods, IBM MQ and Message Broker, Microsoft BizTalk. It replaced point-to-point spaghetti and it worked, until the set of systems stopped being small or stable and the hub that knew everything became the hub that had to approve everything.
SOA (2000s) bet on shared contracts that everyone would honour. Services with published interfaces, SOAP and WSDL, registries, enterprise service buses — WSO2, MuleSoft, Oracle SOA Suite, IBM Integration Bus, later Azure Service Bus and Logic Apps — and the patterns Hohpe and Woolf catalogued in 2003 — routers, translators, the Canonical Data Model. The principles were sound. The bet failed because contracts negotiated across an organisation move at the speed of the slowest committee, so the bus accumulated the logic nobody could get changed elsewhere. By the end of the decade the bus was the monolith.
The API platform (2010s) bet on the human developer. Fowler and James Lewis's "smart endpoints and dumb pipes", REST described by OpenAPI and fronted by an API gateway — WSO2 API Manager, Azure API Management, Apigee, Kong, AWS API Gateway — events, Bounded Contexts, Consumer-Driven Contracts. It is the best integration architecture the industry has produced, and every part of it assumes a person who reads the documentation, writes the client once and operates it for years: human-readable docs, API keys issued to people, versioning by URL, error messages written to be read in a log.
That assumption is now false, and that is the whole story.
What changes when the caller reasons
An agent does not read the developer portal. It discovers a capability at run time, reads a machine-interpretable description of what it does and what it costs, decides whether to call it, constructs the call, interprets the result and decides what to do next — often composing several capabilities nobody explicitly programmed it to combine. It stresses the integration layer at four points.
- Discovery. A one-line OpenAPI summary is enough for a developer who has been told about the API and useless for an agent searching a catalogue. The semantic description — what this does, when to use it, what it must never be used for, worked examples — becomes part of the contract.
- Composition. Human-built integrations are designed flows. Agent-built integrations are assembled at run time. The boundary of each capability matters far more than the choreography between them, because the choreography can no longer be reviewed in advance.
- Guardrails. When a developer writes the client, a human has decided the call is appropriate. When an agent composes it, nobody has. The rule has to move from the calling code to the capability boundary, where it holds regardless of who is calling.
- Evidence. Human-run integrations produce logs. Agent-run integrations must produce evidence: what was called, on whose authority, with what inputs, at what cost. In a regulated domain that is not observability; it is the audit trail.
Those four points are the answers to problems 1, 3, 4 and 5 above. Problem 2, the canonical model, gets its own treatment below.
Which patterns survive, which change jobs, which die
Survive intact
Messaging and asynchronous events. Agents make asynchronous integration more necessary, not less: a reasoning step takes seconds, a human approval takes days. Publish-Subscribe Channel, Event Message and Message Store are exactly the primitives that decouple the pace of reasoning from the pace of the systems. CloudEvents and AsyncAPI give them a standard shape.
Idempotent Receiver. Agents retry, and they retry more than any human-written client because they treat a failure as information. Every capability an agent can reach must be idempotent or must reject duplicates explicitly. This moves from good practice to non-negotiable.
Anti-Corruption Layer. Evans's translation layer is the single most important pattern in agentic integration, because agents are the ultimate boundary-crossers. Without one at each capability, one system's vocabulary leaks into the reasoning about another.
Tolerant Reader. Fowler's 2011 pattern — read what you need, ignore what you do not recognise — is how agents already behave and how capabilities must be built to be called by them.
Strangler Fig. Fowler's migration pattern is how every organisation will actually get there: wrap the existing integration in a new surface, move traffic gradually, retire the old path when nothing calls it. Nobody with a live SIS or a live ledger rebuilds the integration layer in one move.
Survive with a new job
Canonical Data Model — problem 2. As a single enterprise schema every system must map to, the CDM was already failing under SOA and it dies under agents, because the agent does not want your canonical schema; it wants each capability's own vocabulary, described well enough to reason about, with translation at the boundary. But the idea underneath it — a shared, machine-readable understanding of what a student, a payment, an account means — survives as the semantic layer of the capability catalogue. A canonical ontology rather than a canonical message format, owned by the people who own the concepts, not by an integration team. If your three-year CDM captured real business meaning, that meaning is the asset; the XSD is the liability.
Message Translator. Translation does not disappear, it moves: from the hub, to the bus, to each capability boundary. There is no longer a central place where it happens, and pretending there is recreates the ESB.
Service Registry. UDDI failed because nobody maintained it and nothing read it. The capability catalogue — machine-readable manifests, read constantly by agents deciding what to call — is the registry SOA promised, finally with a reader. The Model Context Protocol, published by Anthropic in late 2024 and now widely adopted, makes tool discovery and invocation a first-class protocol concern; Google's Agent2Agent protocol, released in 2025 and moved to the Linux Foundation, covers the agent-to-agent layer above it.
Consumer-Driven Contracts. Ian Robinson's pattern assumed known consumers who could express their expectations as tests. Agentic consumers are not known in advance. The contract reverses: the capability declares in its manifest what it promises — schemas, examples, cost, latency, refusals — and is tested against its own declaration.
Die
The ESB as a home for logic. The bus survives as plumbing, if at all. As the place where routing, transformation and business decisions accumulate, it is finished: agents route around it or, worse, invisibly through it.
Bespoke point-to-point connectors. Already the most expensive pattern per unit of value; under agents also the most dangerous, because the agent cannot see them and will duplicate or contradict them.
Versioning by URL with silent semantic changes. A /v2/ that changes meaning while keeping field names confuses a developer for an afternoon and an agent indefinitely, because the agent's understanding came from the description and the description did not change.
The integration team as gatekeeper. Conway's law predicts this one will fight hardest. When the integration layer is a catalogue of capabilities owned by the teams that own the systems, the central team's job becomes platform and governance — catalogue, guardrail infrastructure, evidence store — not the approval of every mapping. Keep the old role and your agents queue behind the same committee your developers did.
Synthesis
Integration architecture has always been a bet on the caller. EAI bet on a central team and lost when the systems multiplied. SOA bet on shared contracts and lost when the contracts could not keep up. The API platform bet on the human developer, won for a decade, and that bet is expiring. The reasoning caller discovers rather than being told, composes rather than following a flow, and needs its limits enforced at the boundary rather than in code it never sees.
Most of the canon survives. Messaging, idempotency, the Anti-Corruption Layer, the Tolerant Reader and the Strangler Fig matter more, not less. The Canonical Data Model dies as a schema and returns as an ontology. The registry finally gets a reader. The bus, the bespoke connector and the integration team as gatekeeper do not make it.
Next: Part 2 covers the pitfalls we meet in the first ninety days of putting agents in front of an existing estate, what this looks like in higher education and financial services specifically, and the five-layer architecture we build to. Part 3 reports the Nexcubator findings.