When Claudio "Tag" Tagliabue titled his session “The Reference Architecture for Enterprise Agentic AI …nuff said”, he was making a promise: that he was going to put something concrete and reusable on screen, rather than another conceptual framework for a problem that already has too many of them.
He kept it. The session at apidays Singapore 2026 generated more follow-up questions than any other Day 1 talk — which is why we’re dedicating a full article to it here.
Claudio is IBM’s Field CTO for Automation in Asia Pacific. He has presented at apidays conferences several times, leads IBM’s automation practice in the region, and has spent the last several years helping enterprises navigate a question that sounds simple but isn’t: how do you adopt agentic AI without breaking your underlying IT systems?
The Problem Tag Started With
Before presenting the architecture, Claudio named something that many in the room recognised but rarely say out loud:
“I cannot keep up with AI evolution. There’s just too much happening. New models, new frameworks, new standards, new attack vectors. Every man and his dog has got an agentic AI solution.”
His response was not to recommend slowing down, but to offer a stable architectural frame that remains useful regardless of which specific models, protocols, or vendors are in vogue at any given moment.
The challenge, he argued, isn’t choosing between agents and traditional automation. It’s understanding that you need both — and designing the layer between them deliberately.
Pure agentic systems carry real non-functional limitations: they are probabilistic by nature, meaning the same question can produce different answers in different runs. They are expensive — Claudio cited a customer whose popular public chatbot was being rolled back because token costs were scaling faster than revenue. And they create new identity and security challenges that traditional perimeter models weren’t designed for.
Pure traditional automation, on the other hand, can’t handle the complexity of modern enterprise problems on its own. The answer is the best of both worlds: agents for dynamic, creative reasoning; deterministic tools for reliable, auditable execution.
The Three Orchestration Layers
Before walking through the architecture, Claudio established a precise vocabulary for orchestration — a term that gets used loosely enough to mean almost anything. He distinguished three distinct layers:
Agent orchestration
Multi-agent coordination: the process by which multiple autonomous agents interact, share context, and negotiate to complete a task. This is where protocols like the Agent-to-Agent (A2A) Interoperability Protocol operate. Highly dynamic, highly non-deterministic.
Tool orchestration
The process by which a single agent selects and sequences tools to complete a workflow. This is where frameworks like LangChain and LangFlow operate. Also dynamic and probabilistic — the agent decides which tools to use and in what order.
Backend for agents
The layer Claudio spent the most time on, and the one that generated the most discussion. This is the deterministic layer: composing your existing integrations, APIs, and automation into reliable, predictable units that agents can consume without having to reason about the underlying complexity.
“Backend for agents is the idea of composing your deterministic tools — that you’ve already developed and spent ages integrating — for agent consumption. Don’t refactor. Bring them together so agents can much more easily consume them.”
This third layer is where MCP gains its current popularity. But Claudio was careful to note that MCP is not the only approach and may not always be the right one. GraphQL, traditional REST APIs, Kafka for asynchronous flows, and conventional integration middleware all have roles to play here, depending on the use case.
The Full Architecture — Working from the Top Down
New consumers:
the interfaces through which users interact with agents — web applications, chatbots, agent orchestration frameworks. These are no longer your primary API consumers; your APIs are increasingly being consumed by agent systems, not humans directly.
Agent catalog and control plane:
the mechanism by which agents are registered, discovered, and governed. Claudio distinguished three categories: pre-built agents (for specific functions like HR or procurement), custom agents (built by your team), and IT-engineered agents (embedded in enterprise software you already use — Salesforce, Dynatrace, SAP each ship with their own).
Multi-agent orchestration:
the coordination layer. Agents that need to hand off tasks and share context use protocols like A2A. The A2A protocol is new and not yet industry-standard, but the pattern it addresses is stable.
The agent runtime:
where individual agents plan, use skills, reflect, and maintain memory. Skills — guardrails that constrain agent reasoning to a set of predefined steps — operate here, limiting the number of tools an agent considers and reducing token consumption significantly.
The model layer:
the LLMs and other AI models that power agent reasoning. Claudio argued for a multi-model approach: fit-for-purpose models for fit-for-purpose tasks. Not every reasoning task requires a frontier model. An AI gateway selects models based on function and cost.
The tool layer — the backend for agents:
your existing applications, APIs, integrations, CI/CD pipelines, and remediation processes. Composed — not rebuilt — into reliable tools that agents can invoke.
The gateway layer — the enforcement points:
API gateways, MCP gateways, event gateways, model gateways. Governance, authorisation, rate limiting, cost tracking, and circuit breakers all live here.
The Non-Functional Concerns: Identity, Security, and Money
Claudio spent equal time on the non-functional concerns that most architecture diagrams omit.
Identity is the hardest.
Claudio estimated that 80% of his conversations about agents end up in agent identity. The naive approach — have the agent use your credentials — is dangerous. If an orchestrating agent uses an admin’s credentials, it may have access to far more than the task requires, and those credentials may be inherited by every sub-agent in the chain. The correct model is dynamic credential generation: short-lived, scoped tokens generated at runtime for each agent action, with full audit trails.
Security requires zero trust, implemented properly.
“Agentic AI is going to force us to do authorisation and zero trust right,” Claudio said. “We’ve always been talking about zero trust. Now we’ve got to do it.” The additions for agentic systems: agent identity management, delegation of control, circuit breakers that can halt agent activity if something goes wrong, and immutable audit logs at the gateway level.
Cost is a first-class concern.
A customer Claudio spoke to the previous week was rolling back a popular public-facing chatbot because the more users it attracted, the more it cost. Token economics need to be in the architecture from day one. AI gateways that do semantic caching, prompt routing to cheaper models, and token limiting are prerequisites, not features.
The Gateway Sprawl Problem
Claudio’s most pointed observation was about gateway sprawl. Every vendor now sells a different gateway: API gateway, MCP gateway, model gateway, event gateway, agent gateway. Each solves 20% of the problem and creates 80% of additional complexity.
“If tomorrow no one wants to use MCP anymore and UTCP becomes the standard, I don’t want to have to change gateway, change my backend system, or change my agents. A unified approach lowers your total cost of ownership.”
His advice: don’t make this your problem. Make it your vendor’s problem. Ask every vendor you work with for a unified approach that covers all gateway types under a single control plane, and that is protocol-agnostic — so if MCP is superseded, you don’t have to change your backend or your agents.
Practical Dos and Don’ts
Claudio closed with a list worth printing out:
Don’t:
- Hardcode deterministic workflows into agents — you’ll build a very expensive BPM engine
- Focus only on models — think tools, skills, and their interaction with critical systems
- Refactor your IT estate — rip-and-replace creates work with no additional business value
- Treat identity and security as an afterthought
Do:
- Start small and evaluate continuously — things will go wrong; course correct fast
- Build circuit breakers and enforcement points so you can halt agent activity when needed
- Invest in observability — trace what agents do across all your systems
- Demand a unified gateway approach from your vendors
Why This Matters Now
What made Claudio’s session different from the surrounding conversation about agentic AI was its grounding in what enterprises have already built. The argument isn’t “start over.” It’s “the decade of investment you’ve made in APIs, integrations, and automation is your competitive advantage — if you compose it correctly.
The organisations that treat their existing API estate as the raw material for the agentic layer, rather than as legacy to be replaced, will be in production while everyone else is still planning the refactor.
If this architecture is a conversation your leadership team needs to have, the Blue Connector Executive Lunch & Learn applies frameworks like this one to your specific context — in 90 minutes.
Bring this conversation to your leadership team.
The Blue Connector Executive Lunch & Learn translates frameworks like Claudio’s into decisions your C-suite can act on. 90 minutes. Real examples. A decision framework you keep.
Jon Scheele is the founder of Blue Connector and local partner for apidays Singapore. He hosts The Loop Asia podcast and has worked at the intersection of APIs, integration, and enterprise technology in Asia-Pacific for over a decade.
Connect on LinkedIn: linkedin.com/in/scheelejon
Learn more at: https://www.blueconnector.co/ai-readiness