Your integration architecture is not ready for what's coming

You’ve spent years designing flows. Defining sequences. Coding field-by-field transformations. And it works.

But the consumer of your integrations is about to change. It’s no longer an application that executes what you tell it. It’s an AI agent that reasons, decides, and acts on its own.

And that changes everything.

The flow is dead. Long live the tool

In the traditional paradigm, you design the flow: step 1, step 2, transformation, step 3. The system executes. Predictable. Controlled. Slow.

An agent doesn’t need your flow. It needs operations it can invoke. It needs to know what each one does, what input it expects, and what it returns. The rest is up to the agent.

The fundamental unit is no longer the integration flow. It’s the tool — an operation with a semantic contract that the agent understands, exposed via MCP (Model Context Protocol), the open standard that defines how agents discover and invoke operations.

You stop designing how systems communicate. You start designing what capabilities are available.

But be careful: the agent doesn’t solve everything

This is where most agent narratives fall short. They tell you the agent orchestrates, decides, and transforms data. True. But no one tells you what happens when the agent creates a customer in System A, tries to create it in System B, fails… and leaves you with an inconsistent state between two systems of record.

No LLM fixes that.

Transactional consistency across systems is still required. What changes is where it lives. It no longer lives in the flow, because there is no flow. It lives inside each operation that needs it.

If an operation writes to multiple systems and inconsistency has financial or legal impact, that operation must internally implement the consistency mechanisms it needs — saga pattern, step-level compensation — and the agent never sees the technical details. It only receives “success” or “failure with data so you can decide what to do at the business level”.

If the agent has to reason about partial compensations, the design is wrong.

The key is a clean separation. The agent decides what to do and when. The implementation of each tool resolves how to do it internally — including transactionality, compensations, and retries. The boundary is the response contract: the agent receives business outcomes, never technical details of a distributed transaction.

And that transactionality inside each operation relies on concrete mechanisms: saga pattern, step-level compensations, guaranteed idempotency. The agent sees none of this. It only sees the result.

That separation materializes in two types of tools

Granular — simple read or write in a single system. The basic building block. The starting point.

Process — transactional operation across multiple systems. Internal consistency guaranteed, step-level compensation, idempotency. The piece that solves transactionality where it matters.

The agent invokes them the same way — via MCP. The difference lies in the response contract and in who manages the complexity. The implementation resolves transactionality internally; the agent makes business decisions based on the result.

Idempotency is a requirement for both types: if the agent invokes twice with the same parameters, the result must be equivalent to a single invocation.

You don’t need to anticipate which ones are process tools from the beginning. You start granular. Observability tells you when to evolve.

Start small. Iterate fast

Don’t try to design the full catalog from day one. Start with an MVP: one business domain, granular tools, observability from the beginning — if you can’t reconstruct what the agent decided and why, you’re blind — and a reconciliation process for when something fails.

Then let the data speak. Does the agent always combine the same write tools? Are there inconsistencies in testing? Does reconciliation cost more than implementing internal consistency? These are the signals that tell you which granular tool should become a process tool.

A concrete example: Customer domain. MVP with 6 independent granular tools. Observability reveals that create_systemA and create_systemB are always used together and that when one fails, inconsistency appears. Next iteration: a process tool create_customer_all_systems with internal transactionality. The two granular ones are retired. From 6 tools to 5, but with guaranteed consistency.

The catalog evolves. It is not redesigned.

And this is not about theory. It’s about platform

You can design the most elegant architecture in the world. If you don’t have governance, security, and traceability from day one, it’s worthless.

MuleSoft Agent Fabric solves exactly that with four pillars: Registry to catalog tools and agents. Broker to orchestrate between agents. Governance with Flex Gateway for authentication, authorization, and MCP/A2A policies in every interaction. Visualizer to see in real time what each agent decides, what it invokes, and what happens.

It’s not development. It’s configuration. From day one.

What’s coming: the network of agents

Today it’s one agent with its tools. Tomorrow it’s sales, operations, and finance agents talking to each other via A2A (Agent-to-Agent, the communication protocol between agents), each with its own tool catalog, each making decisions.

Everything you solve today — security, traceability, governance, transactionality — multiplies in a multi-agent scenario. The architecture is the same. The scale changes.

And it’s happening faster than you think.

This is a thesis, not a revealed truth. But the alternative to starting is not waiting. It’s falling behind.

---

References

• Agent Fabric — platform for governance, security and traceability for agents: docs.mulesoft.com/general/learning-map-agent-fabric
• MCP (Model Context Protocol) — the standard for exposing capabilities to agents: MuleSoft MCP · MCP for Beginners (Microsoft)
• A2A (Agent-to-Agent Protocol) — the communication protocol between agents: What is A2A?