Enterprise Integration Patterns in the Agentic Era, Part 2: Agent-Native Integration Architecture for Higher Education and Fintech
Part 1 said which integration patterns survive the agentic caller. Part 2 is about building: the mistakes of the first ninety days, the two domains where getting it wrong costs most, and the architecture we build to.
"The conventional integration estate satisfies the regulator by documentation. An agent-native one satisfies it by construction."
The problems this article is about
Part 1 was for the architect deciding what to keep. This part is for the people who have to fund it, run it and answer for it.
- We wrapped our APIs in MCP and pointed an agent at them. It works in the demo and does something alarming in the third week. What did we miss?
- Our integration estate passes audit today. If agents are composing systems at run time, what does "passes audit" even mean — and what will DORA, a data protection officer or a student appeals board actually ask to see?
- We are a university (or a payments firm). Our integration is already governed by standards — LTI, OneRoster, ISO 20022, Open Banking. Does agentic integration replace those, or sit on top of them?
- What does the target architecture look like, in terms our current integration team can recognise, and what does the migration path look like from the estate we actually have?
- Is this cheaper to run and cheaper to change than what we have — or is it a second integration estate on top of the first?
How our R&D wing is working on it
The Software Lens is Aitina Tech's research and development wing, and this series is built from two sources. One is client work: the consulting practice integrates student record systems, learning platforms, ledgers and payment processors, and increasingly the brief includes "an agent has to be able to use this". The other is Nexcubator, our own product venture, where we are building an agentic integration layer between two systems of record — the HR platform and the finance ledger — as a controlled experiment whose findings will be Part 3.
Everything in this article is therefore either something we have seen go wrong on a real estate, or something we are testing on our own. Where a claim is one we are still testing, it says so.
Six pitfalls, in the order they appear
These are the mistakes we see in the first ninety days of putting agents in front of an existing integration estate. They answer problem 1, and most of them are organisational as much as technical.
Wrapping REST in MCP and calling it done. A thin MCP server over an existing API, with the OpenAPI summary copied into the tool description, is a reasonable first step and a terrible last one. The agent can now call the endpoint; it still cannot reason about when it should. Without a semantic description, worked examples and explicit refusals in the manifest, the agent will use the capability in ways nobody intended — and it will do so confidently.
Leaving guardrails in the client. The rule "never refund more than the original payment" lives in the checkout application, because that was the only caller. The agent calling the refund capability directly has never heard of it. Every guardrail that lives in a calling application has to be found and moved to the capability boundary before an agent is allowed near it. This is the largest piece of work in most programmes and the most underestimated.
Trusting the canonical model to do semantic work. Two systems both have a field called status. The canonical model mapped them to a shared enumeration years ago; it has been wrong in three edge cases ever since and humans learned to work around it. An agent will not. Semantic drift that was tolerable under human callers becomes confidently wrong decisions.
No cost model on the capability. A human-written client calls an API a predictable number of times. An agent reasoning about a hard problem may call it forty times in a loop. A capability without a declared cost per invocation and a per-caller budget is an unbounded liability the moment an agent can reach it.
Evidence reconstructed from logs. The first time an auditor or an appeals board asks why a decision was made, the organisation discovers the agent's reasoning is spread across seven log streams with inconsistent identifiers. Evidence must be an output of the integration layer — one signed record per capability invocation, correlated per task, retained — not something assembled afterwards.
Building the catalogue and forgetting the ontology. A catalogue of well-described capabilities that use six different meanings of "customer" is a catalogue an agent cannot safely compose across. The semantic layer is not optional and it is not the integration team's job; it belongs to the people who own the concepts.
Higher education: one student, one login, one truth
A university runs eight or more systems, and each keeps its own copy of the student: the student record system (Ellucian Banner, Oracle PeopleSoft Campus Solutions, Tribal SITS, Workday Student), the learning platform (Moodle, Canvas, Blackboard Learn, Brightspace), identity (Microsoft Entra ID, Shibboleth, Okta), the library (Ex Libris Alma, SirsiDynix), timetabling (CELCAT, Scientia), finance (Unit4, Oracle Fusion), accommodation (StarRez, Kx) and the CRM that recruited the student (Salesforce Education Cloud, Dynamics 365). The CIO is asked for two things, every year:
- One login. A student or lecturer signs in once and every system trusts it.
- One truth. The same student, module, grade and fee in every system, at the same time.
Everything else — analytics, chatbots, "AI for students" — sits on top of those two.
Why the record drifts today
A student enrols in Banner on Monday. The nightly file reaches Moodle. The library connector failed on Tuesday and nobody was told, so the student has no library account. Finance is on its third retry and about to create a duplicate fee. The timetable was re-keyed by an RPA bot that made a typo. Accommodation is working from last week's CSV. Every morning a report lists the mismatches — thirty-seven today — and someone fixes them by hand in a spreadsheet. That is what "integration" means in most universities, and it is where every AI project quietly dies, because an agent built on inconsistent records gives confidently inconsistent answers.
How we have solved it, in each era
Before AI. One directory for logins, pushed into every system overnight. Nightly files for data, and the morning mismatch report. It worked. It was a day behind, and every new system meant a new connector.
The SOA era. One login through federation — Shibboleth and eduGAIN, later Entra ID. One truth through an integration platform — WSO2, Azure Integration Services, MuleSoft, or an API gateway such as Apigee or AWS API Gateway — where Banner announces a change once and every other system listens. Seconds instead of a day. The cost: every change goes through the integration team, the retries and failures are still there, and none of it can be used by an AI agent.
The agentic era. Keep the login. Keep the gateway. Behind them, wrap each system as a capability 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, with the written version in From SaaS to SaaC. Each capability carries a description an agent can read, rules it cannot break, a receipt for every call, and the ability to reason over what its system holds. A consistency agent asks every capability the same question — do you know student 10482 the way the Registrar does? — creates the missing library membership within the library's own rules, refuses to guess at the duplicate fee and raises it to a person with the evidence attached. No retries in the dark, no re-keying, no spreadsheet. And when a student asks "I failed one module and I'm on a scholarship — what happens to my funding and my visa?", the same capabilities give one answer, drawn from four systems, with a record of exactly what was consulted. Nothing is torn out; the old connectors are retired one at a time as the capabilities take over.
Where the five problems land: the rules move to the capability, so a pilot agent cannot read any student's record (1); the receipt is the audit trail for the data protection officer and the appeals board (2); LTI, OneRoster and eduGAIN stay exactly where they are (3); the target is your systems, wrapped, with one definition of student (4); and whether it is cheaper is what Part 3 measures (5).
| Before AI | SOA era | Agentic era | |
|---|---|---|---|
| One login | Directory sync into each system | Federation: Shibboleth, eduGAIN, Entra ID | Unchanged; agents act on the student's behalf, within limits |
| One truth | Nightly files, morning mismatch report | Change announced once, everyone listens | One definition of student; every capability held to it |
| A record missing in one system | Found tomorrow, fixed by hand | Retried; failures still land in a queue | Found and fixed by the agent, or raised with evidence |
| Adding a system | A new connector | Connect it to the platform | Publish its capability; the catalogue does the rest |
| A question across systems | A week of extracts | A report someone builds | An agent answers, with evidence |
| Proof for the DPO or appeals board | Logs, if kept | Logs, pieced together | A receipt for every call, by design |
| Typical tooling | Directory, scripts, files | WSO2, Azure Integration Services, MuleSoft, Apigee, AWS API Gateway | The same gateway, plus SaaC capabilities, a catalogue and a receipt store |
If this is your estate — Banner or SITS in the middle, a morning mismatch report, an AI pilot on the way — book a free hour with an integration architect. We will tell you which system to wrap first and what the receipt for it should contain.
Fintech and payments: one customer, one regulator
A payments firm has the same shape with a regulator watching: a core ledger (Temenos, Mambu, Thought Machine), a card processor (Fiserv, FIS, Adyen, Stripe), a fraud engine (Feedzai, Featurespace), a KYC provider (Onfido, Jumio), a sanctions screen (ComplyAdvantage, Dow Jones), a general ledger and the Open Banking APIs its customers integrate against. It is asked for one consistent customer across all of them, and proof to the regulator of what happened. The standards stay strict: ISO 20022, SEPA Instant, PSD2 and Open Banking, PCI DSS 4.0, and DORA, which since January 2025 treats the resilience of third-party integrations as a supervisory matter.
Before AI, end-of-day files and IBM MQ, with the customer record reconciled overnight and a KYC check repeated by every system that could not see the others. In the SOA era, an ESB in the middle — IBM Integration Bus, WSO2, MuleSoft, Azure Service Bus — and, with PSD2, an API gateway in front: Apigee, WSO2 API Manager, Azure API Management. Consistency improved; the logic deciding when to call fraud, sanctions and KYC settled into application code, and every change became a compliance event. In the agentic era, the gateway and the standards stay and each system is wrapped as a SaaC capability. A payment that trips a fraud rule no longer waits in a queue for an analyst to check four systems: an agent consults the capabilities for transaction history, counterparty risk, sanctions and customer contact in seconds and proposes a decision for a human to confirm — with rules it cannot break (it never contacts a customer about a sanctions match) and a receipt for every call. The conventional estate satisfies DORA by documentation. An agent-native one satisfies it by construction.
Running a ledger, a processor and a fraud engine that do not agree about the customer? Book a free hour and bring the DORA register; that is usually the fastest way to find the first capability.
The architecture we build to
This answers problem 4. It is described in the vocabulary of Part 1 so that an integration team that knows the canon can see where each pattern went.
Layer 1 — Systems of record. The SIS, the ledger, the LMS, the fraud engine. Unchanged; wrapped, not rewritten. Fowler's Strangler Fig governs the move: new surface in front, traffic shifted gradually, old connectors retired when nothing calls them.
Layer 2 — Capability boundary. Each system exposes capabilities with four parts: a manifest (identity, semantic description, schemas, examples, cost, SLA, refusals), a surface (MCP for agents, REST or gRPC for services, events for asynchronous consumers), a kernel (the logic, usually a thin adapter) and guardrails enforced by infrastructure the kernel cannot bypass. The Anti-Corruption Layer, the Message Translator and the Idempotent Receiver all live here. Nothing of a system of record's vocabulary crosses this line. These are SaaC capabilities — built to the pattern set out in From SaaS to SaaC and The Anatomy of a Capability, hired per invocation, settled by a receipt — and each is agentic in its own right: the kernel of progression.rules reasons over the regulations and the student's record and returns a judgement with its evidence, rather than a row from a table. Part 3 publishes one such capability end to end.
Layer 3 — Capability catalogue and semantic layer. Every manifest is published here; every agent discovers through it. Alongside it sits the ontology — the organisation's core concepts defined once, owned by the business — which lets an agent recognise that the SIS's "enrolment" and finance's "registration" are the same event. This is what the Canonical Data Model becomes.
Layer 4 — Agents and orchestration. Agents discover, compose at run time, and act within each capability's guardrails. Orchestration is distributed — any agent can orchestrate, there is no bus. Long-running and human-in-the-loop steps use the asynchronous patterns.
Layer 5 — Evidence and settlement. One signed receipt per invocation: who, on whose authority, inputs, result, cost. Correlated per task, retained per regime. What the auditor, the appeals board and the DORA supervisor read — and the raw material from which the organisation learns.
Cross-cutting — identity and authority. OAuth 2.0 and OpenID Connect carry the human's authority; the boundary checks it; the receipt records it. An agent never holds standing credentials to a system of record, only delegated, scoped, time-limited authority to invoke capabilities.
Readers of the SaaC and AIM articles in this library will recognise the shape: layer 2 is the anatomy of a capability, layers 2 to 4 are AIM's three layers, layer 5 is the receipt that settles the work, and the semantic layer is what the organisational knowledge layer is built on. Integration is where those ideas meet the systems you already own.
Standards you should expect to see in the design
Agent-native integration is not a departure from standards; it is where they finally get used as intended. Expect OpenAPI 3.x and JSON Schema for surfaces and manifests; AsyncAPI and CloudEvents for events; the Model Context Protocol for agent-to-capability invocation, with Agent2Agent where agents from different organisations cooperate; OAuth 2.0, OpenID Connect and SCIM for identity; LTI 1.3, OneRoster, Caliper and eduGAIN in higher education; ISO 20022, Berlin Group, UK Open Banking, FIX, PCI DSS 4.0 and DORA in payments. The patterns come from Hohpe and Woolf, Fowler and Evans. What is new is a caller that actually reads the manifest.
The Nexcubator experiment, and problem 5
Problem 5 — is this cheaper to change than what we have, or a second estate on top of the first — is the one we cannot answer from the literature, and it is the one decision makers are right to insist on. It is why the Nexcubator work exists.
The experiment is narrow on purpose: the HR platform and the finance ledger, currently joined by a nightly connector and a set of rules living in the HR application, re-joined through a small set of capabilities with manifests, MCP surfaces, boundary guardrails and signed receipts. Part 1 lists what we are measuring. The two measurements that bear on problem 5 are the cost of a change — adding a field, changing a rule, admitting a new caller — under the connector versus under the capability layer, and the proportion of the old connector's logic that turned out to be business rules that had no business living in an integration.
We are also testing the Strangler Fig claim in layer 1 directly: the connector stays running beside the capability layer until the receipts show the agent path is answering every question the batch used to, and we will report how long that took and what broke.
Part 3 reports the findings, including where Parts 1 and 2 turn out to have been wrong.
Synthesis
The mistakes of the first ninety days are predictable: wrapping without describing, guardrails left in the client, semantics left to a canonical model, no cost model, evidence reconstructed from logs, a catalogue without an ontology. The two domains where getting it wrong costs most — a student's funding, a regulator's finding — are also the two where the standards work is most advanced, and the standards survive: the agent-native layer sits on top of LTI and ISO 20022, it does not replace them.
The architecture is five layers and a cross-cutting concern, and every one of them has a name an integration architect already knows. The conventional way will not be switched off. It will be strangled, one capability at a time, by an integration layer that agents can read — and whether that is cheaper than what it replaces is a question we intend to answer with numbers, not adjectives, in Part 3.