The Protocol Between Agents Is the Protocol Between Teams

When a new AI framework arrives, it rarely looks like a replatform. It looks like progress. The demo is smoother, the orchestration is richer, the diagrams are more convincing. The cost of that progress is not visible on launch day. It shows up two or three years later, when the assumptions the framework made about what an agent is have aged, and the systems built on that substrate have to move.

The previous post, Causal Decomposition Under Suspended Judgment, was about causal decomposition applied to a failure in retrieval and to a day-one schema decision in Keystone. This post applies the same discipline at a different scale. It looks at a pattern the software industry has already lived through several times, then maps that pattern forward to multi-agent AI in 2026.

The short version is the title: the protocol between agents is the protocol between teams. If the layer where agents communicate is built as a series of one-off bets, every cross-agent feature request becomes an organizational negotiation. If the layer underneath is built on durable dimensions, the same request becomes an engineering conversation.

What follows is an argument about why that distinction matters, and why it is about to matter again.

The layer that keeps getting rebuilt

Every large software stack has layers that last and layers that churn.

The layers that last model what the business does. Payment processing. Call routing. Account records. Compliance logging. Those systems get patched for decades. They accrete fields, rules, and edge cases. They survive vendor changes and UI redesigns because they are commitments to reality: this is what a payment is, this is what a call record is, this is how a compliance event gets recorded.

The layers that churn model what the human does. The CRM view that sales reps live in. The contact center desktop where agents work. The dashboards where supervisors monitor queues. Those systems get replaced outright every few years. They carry bets about interaction models, screen layouts, device assumptions, and work rhythms that are correct for a while and then drift. When the drift passes a threshold, no amount of patching is enough. The bet has to be remade. The interface gets thrown out and rebuilt.

The difference is not that one set of engineers is better than another. The difference is where the code is attached. A service that models the business is anchored to something that changes slowly. An interface that models what humans are doing right now is attached to something that changes constantly.

Once you see that distinction, a lot of history reads differently.

Contact center desktops, ERP front-ends, sales dashboards, trading screens, hospital scheduling views, warehouse management consoles. In almost every domain, the substrate underneath has survived multiple generations of workspace on top. The routing engine that decides where a call goes has been patched and tuned for twenty years. The screen an agent sees has been thrown out and rebuilt three or four times.

The pattern is not subtle. It is structural.

Patch versus replatform

The practical difference between those layers is the kind of change they can absorb.

Service layers tend to take change as patches. A new payment method. A new routing rule. A new compliance requirement. The schema gets a new field, the engine gets a new rule set, the reporting layer gets a new view. The change is incremental. It is visible on a roadmap. It tends to affect one or two teams at a time.

Interface layers take change as bets. The move from single-channel to multi-channel work. The transition from on-premises desktops to browser-based tools. The shift from fixed workstations to remote and hybrid work. Those transitions are not just new features. They change what it means for a human to do the job. The state model, the interaction flow, and the assumptions about where the user is and what else they are doing are all wrong in ways that cannot be patched out. The shape of the job has moved far enough that the software is no longer modeling it faithfully.

When that happens, the choice is not “add another feature.” The choice is “replatform or live with permanent workarounds.” Replatforming means new architecture, new schema, new integrations, new training, and new approvals. Workarounds mean layered hacks until the system becomes a maze of exceptions. Customers pay for both.

In the contact center world, that pattern has already played out several times. Rich, accreted desktop workspaces were replaced with browser-based workspaces that matched new deployment realities but lacked years of accumulated power. Browser-based workspaces were later replaced or re-architected to fit cloud service models. In each transition, the engines underneath changed much less than the agent workspace did. The routing logic that decided which agent took a call remained recognizably itself. The screen the agent used to answer that call did not.

If you are the customer in that story, the distinction is academic only until you are asked to pay the bill. The bill is not the license fee. It is the migration effort: retraining agents, rebuilding workflows, re-wiring integrations, and re-obtaining compliance approvals for a system that nominally does the same job it did before.

That is what “replatform” means in practice. It is not a new version number. It is a coordination event everyone has to attend.

Schema as a bet

The deep reason interface layers replatform rather than patch is that they carry stronger bets about the shape of work.

A schema that models a call record can add new fields without breaking existing records. A schema that models “what the agent is doing right now” has to make assertions about modality, tempo, and state that are incompatible with future modes of work.

Is the agent on a fixed workstation or a mobile device. Are they handling one interaction at a time or several. Is the work synchronous, asynchronous, or mixed. Is the workspace local, browser-based, or cloud-hosted. Is state kept in memory, in a local database, in a shared service.

Every answer to those questions becomes an architectural assumption. Once the assumption is wrong, the code that rests on it has to be rebuilt. The schema cannot carry the new reality without being replaced.

That is where the vertical cost lives. It is not just that services and interfaces have different feature sets. It is that one layer’s schema can absorb change, while the other layer’s schema has to be retired when the bet it represents expires.

You see this when a customer needs a workflow that crosses the boundary between “what the current interface can express” and “what the business actually requires.” The service can usually be extended. The interface often cannot. The response is either a major version rev that forces every consuming component to migrate, or a series of hacks that treat the interface as a patch bay.

The important part is not the technology choice. It is the pattern: schema as a bet, bet as something that ages, replatform as the way expired bets get handled.

Multi-agent frameworks are the new interface layer

Multi-agent AI in 2026 is sitting directly on top of that pattern.

The frameworks that dominate the space today are all trying to give teams a way to express “what agents do.” LangGraph focuses on graph-structured workflows where nodes are agents and edges define communication paths. CrewAI packages multiple independent agents into coordinating crews with explicit handoff semantics. OpenAI’s Agents SDK provides a model-native harness, orchestration patterns, and guardrails for agents that operate over files, tools, and sandboxed environments. Microsoft’s Agent Framework ships its own set of multi-agent orchestration patterns: sequential, concurrent, handoff, group chat, and manager-style coordination.

These are serious engineering efforts. They solve real problems. They are not toy projects.

What they have in common, though, is that they are interface layers. They are making bets about what an agent is and how agents should communicate.

Is an agent defined primarily by its prompt and tools. Is state kept per-agent, per-conversation, or per workflow. Are agents peers in a swarm, subcontractors under a supervisor, or nodes in a fixed graph. Are handoffs explicit function calls, implicit message routing, or centralized orchestration. Does the framework assume synchronous tool calls and fast loops, or can it accommodate long-running tasks and human pauses.

Each of those choices is a bet about the shape of agent work today.

Those bets will age.

Not because the people building LangGraph or the Agents SDK or Agent Framework are careless. They are not. They are building against the reality they see, and they have to pick a shape in order to ship. The reason the bets age is that “what an agent is” is changing as quickly now as “what a human contact center agent does” was changing in the early 2000s. The job is in motion.

Agents that respond in under a second to user input are one category. Agents that initiate work based on system signals are another. Agents that coordinate other agents, wait for humans, or sit inside compliance workflows are a third. Agents that migrate between environments, live across tenants, and carry identity from one substrate to another will be a fourth.

None of those worlds will look exactly like the world the current frameworks are optimized for.

When the mismatch is big enough, the choice will not be “add a feature.” It will be “replatform the agent layer or force customers to live with workarounds.” That is the same choice interface owners faced when moving from desktop to web and from web to cloud.

From the customer’s perspective, the risk is straightforward. If you build your systems directly on top of a framework’s internal assumptions about what agents are and how they talk, you are building into the interface layer. That layer will be rebuilt. When it is, you will pay.

The protocol between agents is the protocol between teams

There is a second pattern layered on top of the first, and it has more to do with organizational design than with code.

Whenever a system is built out of multiple engines, agents, or services that do not share a substrate, every cross-component capability becomes a negotiation between teams. The protocol at the technical boundary becomes the protocol at the human boundary.

If engine A speaks one data model and engine B speaks another, a feature that requires both engines to cooperate will need two PMs, two engineers, and often two managers to agree on what to build, how to sequence it, and whose roadmap absorbs the cost. The technical difficulty might be modest. The organizational difficulty rarely is.

Multi-agent frameworks are introducing that pattern at a new scale.

In the early years of agent work, most teams are building one agent per use case. A retrieval agent. A planning agent. A support agent. A compliance agent. Tool interfaces are custom, state representations are local, and inter-agent communication is ad hoc. As the number of agents grows, so does the number of teams attached to them. Each agent lives in its own boundary, with its own assumptions and its own owners.

When a customer wants a workflow that crosses agents and frameworks, it will not be enough to wire up a new graph. It will require schema changes, API changes, and coordination across teams who each own a piece of the protocol. The protocol between agents will quite literally be the protocol between teams. Every missing field, every misaligned assumption, every incompatible notion of state will be paid for in meetings.

That cost is not visible in v1. It arrives in v3, v4, and v5, when agents have multiplied, teams have specialized, and customers have built workflows that cross the boundaries of the original bets.

This is where the substrate decision matters. If the only place agents meet is inside framework-specific graphs and SDKs, then every time those graphs or SDKs commit to a new shape, the organizational protocol has to follow it. If there is a layer underneath that carries the shared dimensions all agents must respect, then the technical protocol and the team protocol both have somewhere solid to stand.

Four dimensions that survive replatforming

The second case in the causal decomposition post named four dimensions that Keystone treats as day-one substrate commitments: agent identity, tempo, task state, and cost.

Those dimensions are not framework features. They are properties of the work itself. They describe what an enterprise needs to know about any agent doing work under governance, regardless of which framework the agent is attached to.

They are worth restating here, because they are the defense against the pattern above.

Agent identity. Every audit entry, every state record, and every authorization decision carries a first-class field for “which agent did this.” Without that, multi-agent governance collapses almost immediately. You cannot answer “who is allowed to call this tool,” “who took this action,” or “did the compliance agent verify what the retrieval agent claimed” if you cannot reliably attach identity to events. In a single-agent v1, identity looks redundant. In a multi-agent v2, it is the difference between traceable behavior and opaque execution.

Tempo. Different agents operate on different time horizons. Customer-facing engagement agents need sub-second responses. Compliance agents can afford several seconds. Batch analytics agents work on much longer scales. If tempo is not a first-class field and dispatch parameter, the orchestrator will either block fast workflows on slow agents or exclude slow agents entirely. Both outcomes break guarantees. Treating tempo as substrate allows the system to route work and evaluate behavior correctly when agents with different rhythms share a workflow.

Task state. Work exists as tasks with explicit state: created, in progress, completed, failed. That state lives in the data plane, not implicitly in agent code. Without first-class task state, a hung agent, a rate-limited tool, or a failed call leaves the orchestrator with no way to detect stuck work, reassign tasks, or recover gracefully. Once there is more than one agent, “who owns this task right now and what state is it in” stops being an implementation detail and becomes the central question of orchestration.

Cost. Every operation records what it consumed in tokens, latency, and dollars, and every dispatch carries a budget. Agent registries hold cost profiles, and audit entries carry cost fields. Early frameworks treated cost as incidental because inference was cheap and the focus was on making agents work at all. As multi-agent systems start consuming an order of magnitude more tokens than conversational interactions, and as regulated enterprises start asking for cost-per-query reports and cost-bounded behavior, cost will move into the center of governance. If it is not in the schema from day one, retrofitting it later will be a migration, not a patch.

All four dimensions have something in common: they are substrate-level commitments that do not depend on any particular agent framework. They survive framework churn.

Whatever happens to LangGraph, CrewAI, the Agents SDK, or Agent Framework over the next few years, enterprises will still need to know who did what, on which tempo, in what task state, at what cost. The substrate that carries those answers is the layer that can be patched without being thrown out.

Day-one substrate versus future retrofit

The practical difference between treating those dimensions as day-one substrate and treating them as future enhancements is the kind of work required to add them.

If identity, tempo, task state, and cost are present in the schema from the first commit, future code can start using them as soon as there is a reason. They are available for queries, dashboards, and governance without forcing a data migration. The argument about whether to use them is an engineering conversation.

If they are absent, every future capability that depends on them requires a schema change, a backfill, a redeploy, and an organizational negotiation. The argument about whether to add them is a roadmap conversation. The cost is paid not just in engineering hours but in coordination at the human layer.

In the causal decomposition post’s second case, the day-one substrate decision in Keystone was a deliberate choice to incur eight to twelve hours of schema and interface work in order to avoid months of retrofit later. Two tables, a handful of fields on the audit schema, a few extra parameters on dispatch interfaces, and observability attributes. That is not heroic engineering. It is boring work, done early, informed by watching what happens when it is not done.

Applied to multi-agent AI in general, the claim is simple: every team that builds a serious governed agent system over the next few years will either pay for these dimensions up front or pay for them later. Paying later is more expensive.

Why this matters beyond one platform

Most engineers building multi-agent systems in 2026 have not yet lived through a full replatform cycle in their own stacks. They have seen local refactors and infrastructure migrations. They have not watched an interface layer get replaced three or four times while the service layer underneath stayed recognizably itself, and they have not sat in the customer conversations where the cost of those replacements was negotiated.

Most buyers signing contracts for agent frameworks have not lived through it either. They are being told they are buying “the future,” and in a narrow sense they are. What they are not being shown is the pattern: interface layers are bets, bets age, expired bets replatform, and replatforming is paid for by customers whose workflows, approvals, and training are built on the old shape.

This post exists for that audience.

It says: the pattern you have already seen in desktops, web UIs, and cloud workspaces is about to show up in agent frameworks. The layer where agents live and talk will be rebuilt. The substrate that models what the business needs to know can either be attached to that layer or kept separate from it.

Building on the substrate means committing to dimensions that do not age with frameworks. Building directly on frameworks means committing to assumptions that do.

The protocol between agents will always be reflected in the protocol between teams. The only real choice is whether those protocols sit on top of a durable substrate or float in the interface layer.

Keystone’s position in that pattern

Keystone is opinionated about where it belongs in this picture.

The platform is built as governed retrieval and orchestration for regulated environments, with the substrate holding identity, tempo, task state, cost, and evidentiary audits as first-class citizens. The agent layer above it is treated as replaceable. Frameworks are tools. Substrate is the commitment.

The public eval ledger exists so that the decisions made at that substrate can be inspected, rerun, and criticized. The keystone-engage and keystone-verify repos exist so that the architecture is not just described but visible. The day-one schema choices are not secret. They are artifacts.

Ledger: https://github.com/getkeystone/keystone-ledger
Engage: https://github.com/getkeystone/keystone-engage
Verify: https://github.com/getkeystone/keystone-verify

The point is not that Keystone is uniquely correct. The point is that Keystone is built as if multi-agent replatforming is inevitable and the substrate must survive it.

If the tech industry repeats the pattern it has already lived through, there will be enterprises in 2028 looking at agent frameworks the way contact center buyers looked at workspaces in previous cycles: useful, necessary, and expensive to move off. There will also be a smaller number of systems that treated the substrate as a separate commitment and can patch through the transition.

This post is a record that says, in advance, which side Keystone intends to be on.