The hard part of running an agent platform is not building agents. It is upgrading the ones you already shipped.
IBM's Technology Lifecycle Services organization has run a six-agent platform in production since fall 2025, and it got there on one early decision: use A2A for every agent boundary and MCP for every tool boundary. That uniformity did what it was supposed to do — "that uniformity is what let five of our six specialist agents be built by separate teams, one in an entirely separate environment," writes Tony Erwin, who describes himself as a senior architect in IBM Infrastructure's AI Center of Excellence and Chief Architect for the TLS Agentic Platform.
It also left the platform team without a lever. The team built a better reasoning pattern, shipped it inside a shared library that every agent on the platform already uses, and watched most of the fleet decline to adopt it. Not because anyone disagreed. Because reworking a functioning agent lands on somebody else's sprint board, and there was no eval harness to prove the change was worth the schedule risk.
Decoupling buys you contributors. It costs you the ability to raise the floor across everything they build. If you are about to publish A2A and MCP interfaces so other teams can plug into your platform, budget for the second thing before you spend the first.
What IBM Actually Put in Production
This is a real production system with a named stack, not a pilot. Per Erwin's build postmortem, the TLS Agentic Platform runs six specialist agents — Case, Asset, Doc, Client Management, Contract, and HACoC — behind a Supervisor agent that routes intent over A2A. All of them are Python on LangGraph, chosen on the principle that "control flow is code you write, not behavior you hope the model produces." A Next.js backend-for-frontend sits in front.
Underneath: IBM Cloud Kubernetes Service with an Istio service mesh and network policies, Red Hat AI Inference serving models through LiteLLM, PostgreSQL for state persistence, Cloudant and Cloud Object Storage for documents, Milvus via watsonx.data for vectors, and Salesforce behind a proxy API as the case system of record. Langfuse does distributed tracing. IBM App ID handles authentication and IBM Verify performs OAuth 2.0 token exchange where a downstream system uses a different identity provider.
Two details matter more than the logo list.
The first is ownership. Only the Supervisor and the Case Agent were built by the platform team itself. Every other agent belongs to a different team — Support Insights owns the Asset Agent and runs it in a separate environment entirely. That is the payoff of the boundary decision, and it is the whole reason a six-agent platform existed within months of a May 2025 workshop.
The second is identity. Erwin's rule is unambiguous: "Carry the user's identity through every hop — propagate or exchange, never substitute a service account," because "the moment one delegation drops the caller's identity, authorization quietly leaves the enterprise's model for yours. Easy to get wrong, brutal to retrofit." If you are still deciding how agents authenticate to each other, that sentence is worth more than most vendor decks — and the tooling to issue and govern agent identities is now a real product category rather than a research topic.
The Improvement That Never Made It Onto Anyone's Schedule
The platform team built the better pattern, distributed it, and still could not get it adopted — and distribution was never the obstacle.
A deep agent, in the shape the industry has converged on, is an agent whose capabilities live on a filesystem rather than in its graph. Anthropic defines a Skill as "organized folders of instructions, scripts, and resources that agents can discover and load dynamically to perform better at specific tasks," and published the format as an open standard for cross-platform portability in December 2025. The mechanism is progressive disclosure: per Anthropic's own table, a skill's name and description cost roughly 100 tokens and are always loaded, the full SKILL.md body stays under 5k tokens and loads only when the skill is triggered, and bundled reference files cost nothing until read. LangChain's deepagents implements the same standard, and the effect it advertises is the one that matters operationally — it "keeps startup context compact while still making rich capabilities available on demand."
IBM built that harness into AI CoE Agent Utils, its shared Python library: persistent memory, skills as self-contained directories, subagents that isolate units of work, and automatic summarization and offloading to stay inside the context window. Adding a capability becomes "a new skill directory rather than a change to the agent's core graph."
The library is not some optional side project. Erwin says it is "now used by every agent and MCP server in the platform," and it spread outward — the AI CoE adopted it for its own assistant, IBM's Supply Chain team took it up, and the IBM Power team started using it and contributing code back.
Every agent already imports the library that contains the harness. And still: "Most of our agents still aren't deep agents... because most of those agents belong to other teams, each with its own domain backlog, and reworking a functioning agent reads as a large change with schedule risk attached."
That is the finding, and it is not a technology finding. The code was shipped. The teams had it on their import line. What failed was scheduling. Erwin's own summary — "anything that isn't new function loses to new function almost every time" — is the most portable sentence in the entire postmortem, and it applies to every platform team reading this. We saw the constructive version of the same dynamic at Toyota North America, where a platform team spent its capital on making one security review cover fifty agents rather than on the agents themselves. The lever a platform team actually holds is what it makes cheap, not what it recommends.
A2A Standardizes the Wire and Says Nothing About the Insides
A2A is doing exactly what it was designed to do, and the upgrade gap is a direct consequence of that design rather than a defect in it.
The specification is explicit that agents collaborate "without needing access to each other's internal state, memory, or tools". That opacity is the feature. It is why an agent in a separate environment, owned by a separate team, on a separate release train, can join the fleet at all. It is also, precisely, why no operator can reach across the boundary and change how a peer agent reasons.
This is the microservices argument, replayed. At the Microservices Practitioner Summit, Ben Christensen described the "distributed monolith" in a talk InfoQ covered in February 2016 — services coupled through shared binary dependencies, "paying all the cost of a distributed system but losing a lot of the benefits." His prescription was to expose only data contracts and network protocols and hide implementation entirely, so consumers could evolve independently. IBM followed that prescription correctly. The bill for following it correctly arrives ten years later in a different currency: when the platform team learns something true about how agents should reason, it has no way to make that truth propagate.
Worth steel-manning the other side. The in-process alternative — one repository, one deployable, agents as function calls — would have let the platform team refactor all six agents in an afternoon. It also would have meant those five agents were never built, because five other teams would have had to work inside somebody else's release train. Erwin's framing is the right one: "if you want your agents to be independently versioned, independently deployed, independently scaled, and independently testable, A2A is the right abstraction." The trade is real. It is just rarely priced.
Without Evals, the Most Vivid Story Wins
The reason the deep agent migration lost the scheduling argument is that nobody could put a number on the win.
An eval is a versioned set of test cases with machine-checkable pass/fail assertions, run against an agent on every change, so that "this is better" becomes a diff rather than an opinion. Promptfoo, the tool the platform team eventually standardized on, describes itself as an "open-source CLI and library for evaluating and red-teaming LLM apps" — declarative test cases, assertions, CI integration, running locally.
IBM built a Promptfoo integration into AI CoE Agent Utils "so any agent on the platform could add eval coverage cheaply." Erwin's verdict on the timing: "It arrived later than it should have." The cost, in his words: "When agents started producing subtly wrong answers in certain cases, we didn't always have the scaffolding to know it had happened."
The business measurement was missing on the same axis. There was "no baseline for how long escalation prep actually took before. No consistent measure of how much of that we removed" — which meant the team ended up "arguing about impact from anecdotes, which means the most vivid story wins."
Stack those two gaps and the deep agent stalemate is over-determined. A domain team is asked to spend a sprint reworking an agent that currently satisfies its users. The platform team cannot show a regression suite proving the current agent fails cases the new pattern passes, and cannot show a business metric moving. The domain team is not being obstructive. It is making the correct call under the evidence available, and the evidence available is anecdotes.
This is the same failure that shows up when a model version changes underneath a working prompt — the technique that paid on the old model quietly stops paying, and without a re-run eval set nobody notices. It is also why grading agent pilots on an average score rather than a hard pass/fail completion rate produces numbers that cannot settle an argument.
Observability landed late for a related reason. "We flew blind too long: tracing stalled on shifting internal roadmaps." The lesson Erwin draws — reach for proven open source now rather than waiting on a strategic internal platform — is the same conclusion we reached comparing agent monitoring options.
Your Fleet Upgrade Is Already Scheduled — By Someone Else
Even if you never want to change how your agents reason, you will run a fleet-wide migration, because the protocols underneath you version on a calendar you do not control.
MCP uses dated spec versions in YYYY-MM-DD form, incremented on "the last date backwards incompatible changes were made". The current revision is 2026-07-28. Deprecated features "remain in the specification for at least twelve months, or at least ninety days under the policy's expedited-removal exception" before they become eligible for removal. That is a real clock on every MCP server your teams own.
A2A has its own. The v1.0 release "tightens specification behavior, which includes breaking changes in the interaction protocol." The AgentCard evolved compatibly so an agent can advertise both v0.3 and v1.0 behavior, which lets "clients migrate progressively rather than through a single cutover" — a mercy, and still a migration somebody has to schedule. The protocol itself is now governed by a technical steering committee drawn from AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow, and it passed 150 supporting organizations as of April 2026, up from more than 50 a year earlier.
The governance picture consolidated this month. The Linux Foundation formed the Agentic AI Foundation on December 9, 2025 with MCP donated by Anthropic, goose by Block, and AGENTS.md by OpenAI. In August 2026, A2A joined the same foundation, which by that account had grown from 49 founding members to more than 250. Both of your boundary protocols now sit under one neutral roof — good for interoperability, and it means both roadmaps advance on their own cadence regardless of your backlog.
So the question is not whether you will ever push a change across agents you do not own. You will. The question is whether the first time you try is a routine drill or a crisis. IBM's answer, arrived at the hard way, is that a platform team needs a data factory, not an agent factory — "the real constraint was never agent code — it was data access." The same logic applies to migrations: the constraint is never the patch, it is who has room to apply it. Whichever orchestration platform you select, score it on how it handles version skew across agents you did not write, not on its feature grid — and price a framework migration realistically, because teams routinely underestimate what a rewrite of working agent code costs.
What to Do Before You Publish Your Agent Interfaces
This Week:
- Write down who can force a change across every agent on your platform, and what that costs in sprints. If the honest answer is "nobody" or "unknown," you have IBM's problem and you have it before you have IBM's agents. Put a name and a number on paper.
- Check whether your shared agent library ships an eval integration. Not a plan for one. If a domain team cannot add ten test cases to its agent in an afternoon, it will never have the evidence to justify a migration — and neither will you.
- Audit identity propagation on every hop you already run. Trace one real user request from the front end through the supervisor, the specialist agent, the MCP server, and into the system of record, and confirm the caller's identity survives all four. Erwin's "brutal to retrofit" is the operative phrase.
This Month:
- Capture the business baseline you are about to destroy evidence of. Time the current manual process — escalation prep, contract lookup, whatever your first agent replaces — before the agent ships. Once it is live, the pre-state is gone and every impact argument becomes an anecdote contest.
- Use the Agent Card as your fleet contract, because it is the only one A2A gives you. A2A extensions let an agent declare a capability as
required: true, which "signals to clients that some aspect of the extension impacts how requests are structured or processed, and that the client must abide by it." Define a house extension for whatever you consider non-negotiable — trace propagation, identity forwarding, eval coverage — and have the supervisor refuse to route to agents that do not advertise it. Declaration is enforceable; a wiki page is not. - Run a conformance suite against every agent, including the ones other teams own. The A2A TCK is a pytest conformance suite that validates implementations across gRPC, JSON-RPC and HTTP+JSON against RFC 2119 MUST/SHOULD/MAY levels. A red MUST is an argument you can win at a planning meeting.
Before You Publish the Interface:
- Fund a platform-owned migration budget and name it in the contributor agreement. Not a request that domain teams find time. A standing commitment that when the platform ships a fleet-wide change, the platform team writes the patch, runs the evals, and opens the pull request against the domain team's agent. Adoption dies at the point where the cost lands on the team that gets no credit for it. Move the cost.
- Decide your version-skew policy now. How many protocol revisions back will your supervisor route to, and what happens on the day an agent falls behind? Multi-agent systems already drift in ways nobody intended when a supervisor rewrites a task on the way down. Skew between agent versions is the same failure with a longer fuse.
The Bottom Line
Every architecture decision has an adoption bill, and the industry keeps paying it late. Service-oriented architecture promised independent deployment and delivered version skew nobody owned. Microservices promised team autonomy and delivered shared libraries stuck three majors behind. Agent boundaries are the same trade at a higher altitude: A2A and MCP genuinely let five teams contribute six agents to one platform in months, and they genuinely leave you unable to improve any agent you do not personally own.
The fix is not a different protocol. It is admitting that "independently deployable" also means "independently frozen," and paying for the thawing mechanism — evals, a business baseline, a required-extension contract, and a migration budget that lives with the platform team — before you publish the interface rather than after. IBM has a working six-agent platform, an inner-sourced library adopted across three more organizations, and a candid public account of what it would do differently. That is a better position than most enterprises will be in this year.
Standardize the boundary and you get contributors. Fund the migration and you get to keep improving. Do only the first and your agent estate is permanently as good as the day each team shipped.
Continue Reading
- Toyota Ships an Agent in 4 Days. One Review Covers 50.
- Agent Orchestration Platforms: Score Exit, Not Features
- Your Supervisor Rewrote the Task. The 'Do Not' Fell Off.
- LangChain Alternatives: Fix Durability Before You Rewrite
- The 2026 Agentic AI Stack: 8 Layers, 3 You Can Skip
- Best AI Agent Monitoring: Langfuse, Then a Real Kill Switch