%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "edgeLabelBackground": "#FAF7F0", "clusterBkg": "#EFE9DC", "clusterBorder": "#766F65"}}}%%
flowchart TB
A["Agent interface<br/>how do agents address<br/>one another as peers?<br/><small>A2A · Google, Apr 2025</small>"]
T["Tool interface<br/>how does a harness reach<br/>outside capabilities?<br/><small>MCP · Anthropic, late 2024</small>"]
M["Model interface<br/>how do you call a model?<br/><small>Open Responses · community</small>"]
G["<small>vendor-neutral stewardship (MCP · A2A)<br/>Linux Foundation, Dec 2025</small>"]
A --- T
T --- M
T -.- G
classDef world fill:#EFE9DC,stroke:#766F65,color:#16171B
class G world
19 Protocols and Interoperability
Every pattern in the last chapter came with a luxury so pervasive it went unnamed until the closing paragraph: ownership. One party wrote every brief, held every credential, read the whole journal, and could rewire the topology over lunch. This chapter crosses the property line. Your agent must now deal with an agent you did not build, cannot inspect, will never redeploy, and have no particular reason to trust. Inside one system, disagreement between components is a bug; between systems, it is a Tuesday. Nothing on the far side can be fixed, only negotiated with; the interface is no longer a convenience — it is the entire relationship.
Chapter 5 has already told the language half of this story and it will not be retold: the modern protocols are the agent communication languages rediscovered — the performative returned as the typed method, the directory as the machine-readable card — and that argument is settled. What the language story leaves untold is the systems story, where interoperation is actually won or lost: how strangers find one another, how payloads keep their meaning, how conversations outlive their connections, and — hardest of all — who an agent is and on whose behalf it acts when it arrives at a stranger’s door asking for something expensive. Vocabulary makes conversation possible; these services make it safe to have.
The posture toward this chapter’s dating problem is Chapter 16’s — names named, dates dated, perishables quarantined, principles kept — but it holds an asset Chapter 16 did not: the field has run the whole experiment before. The classical era did not merely sketch agent interoperability — it built the complete standards stack, a departure lounge fitted out to international standards for flights that never boarded. That failure is the most instructive artefact in this chapter, because it was a failure of institution rather than of design — and this time the planes exist, the fares are real, and the question has moved from whether anyone will come to whether the operators can agree on a timetable.
19.1 Crossing the Property Line
Begin with what you can no longer see. Inside your own system the journal records everything. Across the property line, the counterparty’s inner life is gone: you see the messages it sends and nothing of why; its journal, if it keeps one, belongs to somebody else’s debugging session. When a run goes wrong at the boundary, the trace stops at the edge of your estate, and investigation turns into correspondence: what was sent, what was acknowledged, what the specification says should have happened next. And what you cannot see, you also cannot reach: no redeploying the far side, no patching its prompt, no adding the missing field to its output. Error handling across the line treats the counterparty the way sailors treat weather — forecast, endured, planned around, never repaired.
The second loss is structural: shared time and shared interest die together. Within one estate, an upgrade is a decision; across estates, it is a rumour — there is no moment at which everyone changes together, because there is no everyone. The old mainframe world could declare a flag day — the appointed hour when every terminal switched formats at once; a network of independent owners has nobody entitled to declare one, so the counterparty population is spread across every version still breathing. Interest diverges the same way: the far side is not hostile, merely owned — it optimises for its proprietor’s customers, costs, and roadmap, and your integration, however vital, is one row in its analytics. Part IV taught the vocabulary, and it now becomes operational: the counterparty is a player, not a component.
What replaces all of it is writing. Chapter 6 defined common ground as what the parties know they share, and inside one system that ground accumulates for free — in the shared codebase, the shared types, the assumptions of people who attend the same retrospectives. Across the property line, none of it accumulates; common ground must be manufactured in advance and published, which is what a specification is: common knowledge established by document rather than by acquaintance. This is why specifications are long, pedantic, and obsessed with the meanings of ordinary words — pedantry is what shared understanding looks like when nobody shares a repository; the alternative is not informality but quiet divergence, discovered in production.
The resulting artefact deserves precision, because protocol names something with three properties a pattern never has. A protocol is public: its whole value lies in strangers implementing it from the text alone. It is versioned: since its speakers cannot be upgraded together, the document must manage its own history. And it is owned by no participant: changes happen by governance — proposals, working groups, consensus — rather than by refactoring, which is why protocols evolve at the speed of treaties, and are right to: the stability is the product itself, the fixed point letting a thousand independent parties build without watching one another. The contrast with a pattern is now exact: a pattern is advice you may take, adapt, or violate by editing your own code; a protocol offers no such freedoms — there is nobody to seek an exemption from, and deviation does not make you interesting, it makes you unreachable. This — interoperability — is the property the whole apparatus exists to buy: independently built systems working together on no basis but conformance to a shared, published agreement.
The good news is that this discipline has a track record, the most successful in the history of engineering. The internet’s protocols outlive the products that speak them by decades — SMTP, published in 1982, is older than most of the people whose mail it carries; the companies are mortal and the agreements are not. The design lesson underneath is the narrow waist: agree on as little as possible, and make that little universal. The internet standardised one thin packet format in the middle — an hourglass, physical media blooming below the pinch and applications above — and the shape is no accident: every clause added to a universal agreement is a clause every implementation must carry forever, so the smaller the waist, the longer the life. The agent protocols will be tested against it, since nothing bloats faster than a specification with enthusiastic sponsors.
One discipline is already fixed: the old robustness principle,1 conservative in what you send and liberal in what you accept, survives as the must-ignore rules that let last year’s client talk to next year’s server. The principle is a trade-off, though, not a creed: every leniency in a parser is behaviour an attacker may compose, and decades of exploits assembled from charitable readings of malformed input have taught modern protocol security to prefer strict parsing, canonical encodings, and explicit version negotiation exactly where trust is thinnest — the internet’s own architects now counsel a “virtuous intolerance” of ill-formed messages,2 and an agent protocol, whose payloads reach an audience more suggestible than any parser, has more reason than most to listen. The prior question, though, is what the agreements should be about; the field’s answer is currently consolidating, and it arrives — as the preface trailed — at three altitudes.
19.2 One Consolidation, Three Altitudes
Strip away the product names and the consolidation is easy to state. Any agent system dealing with the world beyond its own process needs answers to three questions, one per layer of the stack. At the bottom: how do you call a model? In the middle: how does a model’s harness reach capabilities? At the top: how do agents address one another as peers — find a counterparty, delegate a task, follow its progress, collect the result? Three questions, three altitudes: model interface, tool interface, agent interface (Figure 19.1). The questions are fixed by the shape of the stack — they are Chapter 2’s model-plus-harness, Chapter 4’s tools, and Chapter 5’s messages, asked at the property line — and they will outlive every current answer, which is the reason to learn the questions rather than the answers first.
At the model altitude, the problem was the oldest and dullest: every laboratory shipped a bespoke endpoint, every framework kept a warehouse of adapters, and the ecosystem paid an integration tax of every-client-times-every-provider. The consolidation happened the way such things usually do — a de facto shape hardened, then was surrendered to neutral ground: the market leader’s stateful, tool-aware endpoint was generalised into Open Responses,3 a vendor-neutral, community-governed specification of the request, the streamed response, and the tool-call loop, implemented so far by the aggregators and local-inference runtimes. The significance is not the schema but the truce: the layer has, for the moment, stopped being a place to compete.
One altitude up sits the Model Context Protocol, introduced by Anthropic in late 2024, the period’s runaway adoption story (2024). MCP standardises the meeting between a model’s harness and the outside world’s capabilities: servers advertise tools, resources, and prompts in a common format; clients discover and invoke them through typed requests — one protocol in place of the same N-by-M adapter problem, one layer higher. The wire details have kept moving beneath the stable name — the July 2026 revision removed sessions and the opening handshake altogether, each request now carrying its own version and capabilities so a server can stand behind an ordinary load balancer (Model Context Protocol Project, 2026). Chapter 5 read MCP against the classical languages; read as infrastructure, its contribution is the ecosystem inversion: before it, every agent product integrated each service by hand; after it, a service implements one server and is reachable from every client — which is why adoption ran ahead of every rival scheme.
At the agent altitude the corresponding standard is the Agent2Agent protocol — A2A — born at Google in April 2025 and donated to the Linux Foundation within three months (2025). A2A answers the top question: an agent publishes its Agent Card — the machine-readable self-description Chapter 5 recognised as the directory facilitator’s return — at a well-known address; counterparties fetch it, open a session, and delegate tasks, typed objects with an explicit lifecycle — from submitted through input-required to completed, failed, or canceled (the specification’s own spelling) — that survives disconnection and supports cancellation, so that the long-running engagement the pattern chapters assumed inside one system has a wire format between systems. It is the youngest layer and the least settled, for a structural reason: it is the altitude where the counterparties are most autonomous, so the altitude where the most must be agreed.
Then, in December 2025, the governance consolidated too. The Linux Foundation — already home to Kubernetes, Node.js, and PyTorch — announced the Agentic AI Foundation (AAIF), co-founded by Anthropic, Block, and OpenAI, with MCP donated as a founding project alongside Block’s goose agent framework and OpenAI’s AGENTS.md convention.4 A2A was already resident under the same roof, a Linux Foundation project of its own rather than a ward of the new foundation, and the platinum membership reads like the industry’s group photograph: the founders plus Amazon, Google, Microsoft, Bloomberg, and Cloudflare. The precedent is exact: this is the Kubernetes move — a strategic asset surrendered to a neutral foundation so that rivals will standardise on it rather than against it — and that competitors who agree on very little agreed to fund the same secretariat is the strongest signal in this chapter that the consolidation is meant seriously. Rivals do not share a lifeboat for fun.
That is the story at the time of writing — and shift it may: whether this arrangement survives its members’ quarterly ambitions is a question the reader is better placed than the authors to answer. The durable residue is a reading discipline: whatever standards hold the three altitudes when you read this, ask of each the question its layer exists to answer, and notice what consolidation buys: a layer that stops being a place to compete becomes a floor to build on, and the competition climbs a storey. What it does not buy is any of the services that make the top altitude actually work between strangers; those are the next two sections, where the engineering lives.
19.3 The Mechanical Services: Discovery, Schemas, Lifecycle
Chapter 16 taught the move: when the products are perishable, inventory the services — what any entrant must provide because the problem demands it, whoever is selling. Interoperation between agent systems demands six, and they divide by difficulty. Three are mechanical — finding a counterparty, keeping meaning intact in transit, keeping a conversation alive longer than a connection — solved, in outline, decades ago: the classical stack specified every one of them, down to the yellow pages (Foundation for Intelligent Physical Agents, 2002). Three are hard — identity, authentication, delegation — and get the next section to themselves. The division is worth respecting because the mechanical services fail loudly and the hard ones fail quietly, and a team that has wired up the first three can believe, on no further evidence, that it has finished.
Capability discovery answers the strangers’ first question: what can you do, and how do I ask for it? The classical answer was a building — FIPA’s directory facilitator — and the modern answer is an address: the counterparty publishes its self-description at a well-known location on its own domain, the directory dissolving into the web and its name system. The dissolution is elegant — registration, the classical scheme’s perpetual headache, becomes simply being reachable — but notice what else dissolved: any pretence of a librarian. Nobody curates the open web’s agents, nobody deregisters the dead ones, and nothing in a well-known URL stops its owner claiming whatever reads well.
The boundary’s character, tasted early: a self-description is an advertisement, and Chapter 12 priced advertisements — a claim that costs nothing to make carries no information beyond its maker’s interests. An agent card that announces expert legal analysis; fast; reliable is bidding in a Contract Net with no penalty for overbidding, and Section 12.2’s winner’s curse follows at the boundary: the counterparty selected on self-description is systematically the one that overstates itself most handsomely. The mitigations cannot come from the card; they come from everything around it — capabilities probed rather than believed, with cheap test tasks before expensive real ones; claims witnessed, by signatures over the card so its assertions are at least attributable; and history kept, Chapter 13’s reputation machinery, because the one thing an advertisement cannot buy is a record. Staleness is the same problem in time: a card is a claim about the day it was published, and the counterparty behind it upgrades, degrades, and repurposes without notifying your cached copy.
Schemas answer the second question: when a message arrives, what does it say? The mechanical layer is genuinely settled — typed payloads, declared formats, validation at the door; Chapter 17’s performatives going public, an enum become a treaty clause. The trap is mistaking the layer for the meaning. A schema validates structure: that the field named price holds a number is checkable by machine; that the number includes tax, is denominated in the currency you assume, and refers to the item you asked about rather than the item plus compulsory extras is not, and never will be — Chapter 5’s ontology problem, returned at the systems level with money attached. Validation passing means the message is well-formed, not that the two of you mean the same thing — and that gap is where cross-boundary integrations quietly rot.
The gap widens at every translation, because neither counterparty actually thinks in the wire format: your framework’s rich internal object is flattened into the protocol’s neutral shape at your edge and reconstructed into a different framework’s rich object at theirs — Appendix C’s Rosetta stone become a runtime component, one system’s task another’s goal a third’s conversation, every crossing a lossy hop of the kind Chapter 18 taught you to count. The discipline that keeps the loss survivable is the must-ignore rule Section 19.1 already named: extension fields an implementation skips when it does not understand them, so a richer counterparty can say more without breaking a plainer one.
Lifecycle answers the third question: what, exactly, are we in the middle of? A task delegated across the boundary may run for hours, and the connection that delivered it will not live that long, so the protocol must give the engagement an existence independent of any transport: an identifier, a queryable state, a way to resume after silence. Silence is the deep problem: a client that hears nothing cannot distinguish a lost request from a lost reply, so it must retry, and a retry that might duplicate must be safe to receive twice — idempotency, the dullest word in distributed systems, and the one deciding whether a flaky network double-books your customer’s flight. Cancellation completes the trio and changes character at the line: within your own estate, cancelling a task is an act; across it, cancel is a request to a party with its own accounting, perhaps mid-purchase on your behalf; the protocol can promise delivery of the request but not the undoing of the world.
The last lifecycle service is living with version skew, the machinery Section 19.1 promised. Since no flag day is coming, counterparties must discover each other’s vintage, not assume it — versions declared in an opening handshake or, as MCP has it since July 2026, carried on every request (Model Context Protocol Project, 2026) — and specifications must evolve additively, new fields beside old rather than in their place, with deprecation as a published calendar measured in years rather than a release note measured in days. None of this is glamorous, all of it is settled practice from the protocol traditions that came before, and every part of it can be built by a competent team in a quarter. The note to end the mechanical services on: necessary, known, and not where interoperation fails — that happens one floor up, at the questions the schemas cannot ask (who is this, says who, on whose behalf?), and that floor is next.
19.4 Strangers with Business: Identity, Authentication, Delegation
Start with the question that sounds philosophical and bills by the hour: what, for identity purposes, is an agent? Every candidate from the software’s own anatomy fails on inspection. The process? It dies and respawns hourly, and one task may span twenty of them. The model? Shared verbatim by a million other agents. The prompt and configuration? Amended silently on someone else’s schedule. The conversation history? Forked, summarised, and garbage-collected. An agent is software that spawns by the thousand, mutates in place, and holds no body stable enough to hang a passport on — and yet the counterparty across the boundary needs something that persists, because every service the previous section described silently assumes it.
The workable answer gives up on the software and anchors in the institution: identity attaches to the accountable party — the deployment, and behind it the organisation — the individual agent a short-lived officer of that identity, the way a bank clerk acts under the bank’s name and the bank, not the clerk, answers for the account. It is what the standards’ signed self-descriptions gesture at: not this process is who it says but this organisation stands behind this endpoint and can be held to it. And the anchoring must make identity scarce: Sybil’s lesson (Chapter 13) is that any system in which identities cost nothing is governed by whoever mints the most (Douceur, 2002), and an agent ecosystem is the cheapest identity-minting environment ever constructed — reputation, rate limits, one-vote-per-participant, every downstream defence inherit their strength from whatever made identity expensive.
Authentication is the one part of this section the field did not have to invent, and the counsel is correspondingly short: the web’s cryptographic machinery — keys, signatures, certificate chains — transfers whole and proves possession and provenance as well for an agent as for anything else. The trap is the conflation the security literature has warned about for fifty years: authentication answers who is speaking; it says nothing about what they may do. A perfectly authenticated counterparty is a perfectly identified stranger — the signature proves who published the advertisement, not that the advertisement is true, and who sent the request, not that the request is within its rights. That second question is authorisation, and for agents it carries a complication the web’s borrowed machinery does not settle: the same well-authenticated agent may be acting for a different principal on every task it runs.
Which makes delegation the hardest-working service of the three. Every request that crosses the boundary stands at the end of a chain — a human authorised an agent, which spawned a subagent, which invoked a tool against a third party’s service — and the question the receiving side must answer is not “who sent this message?” but “on whose behalf does this chain act, and how much of that principal’s authority survives to this hop?” The engineering principle is attenuation: authority should narrow at every link — the subagent gets the customer’s authority over this booking, not the customer’s authority at large; the tool call gets read access to this record, not the database — scoped, expiring, task-bound credentials in place of the master key. Attenuation is Chapter 18’s brief discipline reborn as security: the brief said no more context than the subtask needs; the credential says no more authority. And like the brief, it fails in one direction only — nobody ever accidentally under-delegates — so the chains rot toward the master key unless the protocol makes narrowing easier than copying.
The canonical failure of unattenuated authority was described in 1988, in three pages, and re-enacted faithfully ever since. Hardy’s compiler held one standing permission of its own — it could write to the system’s billing file — and a user, entitled to invoke the compiler but not to touch billing, simply named the billing file as the output destination; the compiler, acting on the user’s request with its own authority, obliged (1988). He called it the confused deputy: a program wielding its own credentials in the service of somebody else’s intent, and Chapter 6 met its modern incarnation before the name — prompt injection is a confused deputy whose confusion is verbal, a model with standing permissions obeying instructions that arrived as data. At the boundary, deputies are the default architecture: an agent with durable credentials — your email, your database, your payment method — processing requests, cards, and task payloads that arrive from strangers over the wire. Hardy’s cure remains the cure: authority should travel with the request rather than sit ambient in the deputy — act on the requester’s ticket, never your own — and every design review of an interop surface can start with his question: which of this agent’s standing permissions can a stranger’s input cause it to spend? Figure 19.2 traces the hops at which that question must be asked.
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "edgeLabelBackground": "#FAF7F0", "clusterBkg": "#EFE9DC", "clusterBorder": "#766F65"}}}%%
flowchart TB
U(["Human principal"])
A(["Agent"])
K["Standing key<br/>durable credential"]
T["Tool / third-party<br/>service"]
R[("Protected resource<br/>billing, email, payments")]
X(["Stranger's input<br/>over the wire"])
U -->|"authority for<br/>this task"| A
A -->|"attenuated:<br/>this booking only"| T
T -->|"read this<br/>record only"| R
A -.-|"held ambient"| K
X -.->|"asks for something<br/>expensive"| A
A -->|"confused<br/>deputy: spends<br/>its own key"| R
linkStyle 4 stroke:#A4161A,color:#A4161A
linkStyle 5 stroke:#A4161A,color:#A4161A
classDef world fill:#EFE9DC,stroke:#766F65,color:#16171B
classDef risk fill:#F4D7D5,stroke:#A4161A,color:#16171B
class K,R world
class X risk
All of which cashes the cheque Section 19.1 wrote: at the boundary the cooperative assumption is not weakened but gone, and Part IV stops being background theory. The counterparty optimises for its owner, so every mechanism must be priced for gaming, not merely for error — Chapter 12’s discipline. Its messages are crafted, not merely emitted, so Chapter 5’s deception graduates from philosophical worry to line item: flattering agent cards, task descriptions engineered to steer your model, tool results bearing instructions. And every interop surface is an input channel to a language model’s context, which makes each one attack surface in the technical sense Section 20.9 will treat properly; this chapter’s contribution is the posture: nothing that arrives over the wire is information until something on your side of the line has decided so — until then it is material, submitted by a party with interests.
The three hard services share a property the mechanical three do not: they cannot be bolted on. Discovery, schemas, and lifecycle can be retrofitted to a working system; identity, authorisation, and attenuated delegation are load-bearing walls — decisions about what flows through every message, credential, and hop — and a protocol that postpones them acquires an installed base whose every deployment embodies the wrong answer. The current standards, to their credit, carry the beginnings — Table 19.1 records where each service stands — and end-to-end attenuation across autonomous hops remains the open engineering frontier of the consolidation: the place where the treaties are thinnest. What a treaty can and cannot fix is, fittingly, the closing question.
| Service | The question it settles | Fault line | Where the standards stand (late 2025–early 2026) |
|---|---|---|---|
| Capability discovery | What can you do, and how do I ask for it? | Mechanical — fails loud — bolts on | Self-description at a well-known address (the Agent Card); the directory facilitator dissolved into the web. But no librarian curates or deregisters, and a card is an advertisement, not an affidavit (Chapter 12). |
| Schemas | When a message arrives, what does it say? | Mechanical — fails loud — bolts on | Settled: typed payloads, declared formats, validation at the door, must-ignore extension fields. Structure is checked; shared meaning is not — Chapter 5’s ontology problem, with money attached. |
| Lifecycle | What, exactly, are we in the middle of? | Mechanical — fails loud — bolts on | Settled: task identifier, queryable state, resumption after silence, idempotency, cancellation, additive versioning. Buildable by a competent team in a quarter. |
| Identity | Who is this? | Hard — fails quiet — cannot bolt on | Signed self-descriptions anchor the accountable party; but identity must be made scarce (Chapter 13’s Sybil), and the software holds no body stable enough for a passport. |
| Authentication | Says who? | Hard — fails quiet — cannot bolt on | The web’s keys, signatures, and certificate chains transfer whole — but they answer who is speaking, never what they may do. |
| Delegation | On whose behalf — and how much authority survives to this hop? | Hard — fails quiet — cannot bolt on | Where authorisation lives: scoped, expiring, task-bound credentials and declared security schemes have begun, but end-to-end attenuation across autonomous hops is the open frontier — the treaties are thinnest here. |
19.5 Interfaces, Not Solvents
Section 1.7 wrote the epitaph — the classical languages were ratified into a world that had very few agents to use them — and the institutional post-mortem deserves its detail: every clause is a lesson. FIPA, registered in Geneva in 1996, did the work and did it well: a communication language with formal semantics, agent-management and directory specifications, interoperability tests, and in JADE a faithful, industrial-strength implementation of the whole stack (Bellifemine et al., 2007). What it did not have, and could not summon, was traffic. Interoperability is a network good: its value to any participant is the other participants, and a standard adopted before valuable agents existed offered its early movers all of the compliance costs and none of the counterparties. The standards did not fail on their technical merits — most were never exercised hard enough to fail — they were simply beautifully engineered answers waiting decades for their question.
The internet’s standards culture is the counter-model, and its founding creed was delivered in 1992, when David Clark told the IETF’s assembled engineers: “We reject: kings, presidents and voting. We believe in: rough consensus and running code.”5 The practice behind the slogan inverts FIPA’s order of operations: implementations first, interoperation demonstrated between independent codebases, and ratification last — the standard less a blueprint than the minutes of a meeting the market has already held. A specification written after the running code documents solved problems; a specification written before it legislates guesses, and guesses defended by an installed base are the hardest guesses in engineering to withdraw.
Score the present consolidation against that test and the results are usefully uneven. MCP passes it cleanly: the protocol shipped, the ecosystem inverted, adoption ran far ahead of any committee, and the donation to neutral governance ratified a fact rather than proposing one. The model-interface layer runs the same way — Open Responses generalised a shape the market had already converged on, though its adoption ledger is still filling in. A2A is the more classically-shaped bet: a specification published with impressive sponsorship and an ecosystem still growing into it, which is to say the altitude where the counterparties are most autonomous is also — fittingly — the one where the standard is most nearly a hope. None of this is a prediction; it is a monitoring instruction, and the durable test survives any reorganisation: wherever running code and real traffic lead and ratification trails, expect the standard to hold; wherever the order reverses, remember Geneva.
Now for the title’s claim, and the first thing no protocol can do: settle architectural disagreement. Chapter 18’s patterns assumed a designer who chose the topology; at the boundary, each party arrives with its topology already chosen, and the protocol has no opinion. Let two organisations connect their systems, each built — reasonably, independently — around a supervisor that expects to lead: each addresses the other as a subagent, each awaits the other’s report, and every message is schema-valid, well-authenticated, and correctly sessioned while the joint system does nothing whatever. What the protocol has provided is not a resolution but a shared language in which to have the disagreement — genuinely worth having, but the lenses still apply across the property line, and the composed system’s information flow, control structure, and failure modes were designed by nobody: Section 18.5’s composition warning operating at treaty scale, between parties who cannot read each other’s journals.
The second and third impossibilities follow the same grammar. A protocol cannot guarantee quality: one can be defrauded in perfectly valid JSON — the payload that parses is not the work that satisfies, so Chapter 21’s evaluation machinery becomes at the boundary not optional but urgent. And a protocol cannot manufacture trust: it carries identity, signatures, and scopes — the rails Section 19.4 laid — but trust accumulates the way Chapter 13 said it does, from history, stakes, and costly demonstration. The rails move the cargo; they do not inspect it, and they certainly do not vouch for the shipper.
The adoption judgement nearly writes itself. Where the counterparties are strangers, the standard is not a choice but a precondition — there is no bespoke integration with a party you cannot call a meeting with. Where you own both ends, bespoke is tolerable and sometimes right — Chapter 17’s typed messages are a private protocol, and none the worse for it — but the gravity of tooling usually decides anyway: clients, servers, debuggers, and hosted infrastructure accrete around the standard until speaking it is cheaper than not, whatever the technical merits. The practical rule is the narrow waist applied to your own estate: speak the standard at your edges, whatever dialect you speak within. Hold on to the distinction the vendors will happily blur: adopting a protocol is not an integration strategy, any more than installing a telephone is a negotiation strategy — the protocol gets you a dialling tone, and everything this book has said about what to say still applies.
Part VI has now assembled the whole apparatus: a framework chosen or declined, a runtime built, patterns to shape it, protocols to connect it to strangers. What none of that yet delivers is a system anyone should rely on — state that survives a crash, retries that do not double-charge, budgets that hold under pressure, a human who can approve the irreversible step before it happens rather than read about it afterwards. Connected, in short, is not dependable. Making it dependable is unglamorous, decisive, and the business of the next chapter.
19.6 Summary
- Between systems, the standing assumptions die. No shared harness, no shared journal, no right to rewire the far side, no presumed alignment of interests — a pattern becomes a protocol, an interface nobody controls and everybody must speak.
- The consolidation is one story at three altitudes. One way to call a model (Open Responses), one way to hand it capabilities (MCP), one way for agents to address each other (A2A) — names dated and quarantined; the three questions they answer are not.
- The mechanical services are fixed by the problem, and an agent card is an advertisement, not an affidavit. Discovery is FIPA’s directory facilitator reborn, schemas carry meaning across frameworks that share no code, lifecycle covers the long-running task and the dropped connection — and self-description is a claim priced at nothing, so verification and reputation must come from machinery.
- Identity, authentication, and delegation are the hard services. Identity for software that spawns by the thousand; authentication that says who is speaking without saying what they may do; and the delegation chain, where authority must attenuate at every hop — the confused deputy waits wherever it does not.
- At the boundary Part IV reports for duty, and FIPA’s failure is the standing lesson. A counterparty has incentives, not bugs, and wire inputs are attack surface; the classical stack standardised everything before anyone had agents worth connecting — running code and real traffic are what make a standard take, which is why this round may differ.
- Interfaces are not solvents. Two systems that disagree about who leads do not interoperate because they share JSON: protocols carry messages across the property line, not intent, not quality, and not trust — and a connected system is not yet a dependable one, which is Chapter 20’s business.
19.7 Exercises
Exercise 1. The running team federates with Meridian, a triage service it did not build, cannot inspect, and cannot redeploy, and the first fortnight’s post-mortem lists seven incidents. (i) Meridian’s status field arrives as an integer where the team’s validator requires a string, and every request is rejected at the door within the hour. (ii) Both sides validate "priority": 2 without complaint — but Meridian’s scale runs one-is-highest and the team’s runs five-is-highest, and the team’s most urgent tickets spend a week at the back of Meridian’s queue. (iii) The team’s cached copy of Meridian’s card, fetched in March, still advertises flaky-test triage; Meridian repurposed itself for documentation summarisation in May, and delegated jobs now return schema-valid prose summaries where fixes used to be. (iv) The team cancels a triage job and receives a well-formed confirmation; an hour later a pull request from the cancelled job arrives anyway, opened by a Meridian worker that was mid-task when the cancel landed. (v) After every botched job the counterparty resurfaces at a fresh endpoint with a fresh card and a fresh key — “MeridianPro”, then “MeridianPrime” — and each newcomer’s reputation in the team’s ledger starts pristine. (vi) Because every inbound request carries a valid signature over a valid card, the team’s gateway grants such requests read access to the private fork automatically. (vii) So that Meridian “can fetch context itself”, the coder embeds the team’s repository-wide write token in the task payload, and a Meridian subcontractor is later found pushing branches. (a) For each incident, name the service of Table 19.1 under stress and classify it mechanical or hard — one service is stressed twice, at two different depths; name the pair and say what separates the depths. (b) Say whether each failure was loud or quiet as experienced, reconcile any mismatch with the table’s fault-line column, and state the general rule the mismatches share — what the plumbing checks, and what it cannot. (c) For each incident, give the chapter’s remedy and say whether it bolts onto the running integration or requires rebuilding the interface, justifying each verdict from Section 19.3 or Section 19.4 in a sentence.
Exercise 2. The running team ships version 2 of its cross-boundary task schema. No flag day can be declared — Section 19.1 says why — and each counterparty still on version 1 upgrades in any given month with probability 0.1, independently, so the un-upgraded fraction in month t is 0.9^{t}. The team serves 200 cross-boundary sessions a month, spread uniformly over the counterparty population. (a) Compute the version-1 fraction after a year, the expected number of months a given counterparty stays on version 1, and the first month in which the remnant falls below 1% — then say what these three numbers do to any sentence beginning “once everyone has upgraded”. (b) A breaking release renames the field in place, so every session with a version-1 counterparty fails, at 1,500 tokens of cross-estate correspondence each — the trace stops at the edge of the estate, so each failure is investigated by letter. Show that the failed sessions over the whole life of the skew number 200 \times \sum_{t \ge 1} 0.9^{t} = 1{,}800 exactly, price the bill, and compute the share of it that lands in the first year. (c) An additive release — the new field beside the old, must-ignore rules doing the rest — fails nothing but carries 30 tokens of dead weight per session while the old field survives; find the deprecation horizon D^*, in months and years, at which carrying the retired field has cost as much as the rename, and say what the size of D^* teaches about deprecation calendars measured in years. (d) Say which direction of version skew each half of the old robustness principle protects in this scheme — the version-1 reader of a version-2 message, and the version-2 reader of a version-1 message — and why the session handshake must declare versions rather than assume them.
Exercise 3. Three counterparties answer the running team’s call for a subcontracted flaky-test triage. All three Agent Cards read “expert triage; fast; reliable”, the fees are identical, and the true per-job success rates — visible in no card — are 9/10, 3/5, and 3/10. A failed job costs the team 24,000 tokens of rework and cross-boundary diagnosis. (a) Selecting on the cards is selecting uniformly at random; compute the expected failure probability and the expected damage, and explain — from Chapter 12’s pricing of costless claims — why uniform is the optimistic model of card-led selection rather than the pessimistic one. (b) The team instead probes: one cheap test job to each candidate, passed independently with the candidate’s true rate; the real job then goes to a passer chosen uniformly, falling back to a uniform choice over all three if nobody passes. Compute exactly — fractions, not decimals — the expected success rate of the counterparty so selected, the expected damage, and the all-in comparison with (a) at 600 tokens per probe. (c) Find the probe price at which the two policies break even, and say in one sentence what the probe is buying — what a test job converts an advertisement into. (d) The chapter offers three mitigations — capabilities probed, claims witnessed, history kept; match each to the card failure it answers (overstatement, unattributability, the missing track record), say where staleness fits among them, and explain why a signature over the card does none of the probe’s work — the distinction Section 19.4 sharpens into authentication versus authorisation begins here as authentication versus truth.
Exercise 4. A proposed agent-interoperability standard costs each adopter C = 20 engineer-weeks to implement and conform; a reachable counterparty is worth 0.5 engineer-weeks a year, and parties evaluate over a four-year horizon, so an adopted counterparty is worth 2 engineer-weeks; adoption is voluntary and sequential, and a party adopts when the counterparties already reachable repay the cost. (a) Show that from an installed base of zero no party ever moves, compute the net payoff each of n = 60 parties would enjoy had all adopted at once, and name the strategic structure this pair of facts identifies — then say why, at the property line, no flag day is available to reach the good outcome. (b) Compute the critical mass k^*, and restate MCP’s launch in the model’s terms: a sponsor who ships the client side inside products that already have users delivers an installed base b by unilateral action — give the condition on b under which every subsequent adoption pays from day one, and say why the ecosystem inversion of Section 19.2 is this threshold crossed rather than any schema improved. (c) The classical stack: with valuable deployed agents scarce, take the horizon value of a counterparty at 0.1 engineer-weeks and recompute k^*; set the result against an agent population numbered in dozens, and write the epitaph — all of the compliance costs and none of the counterparties — as an inequality. (d) Translate the running-code test into the model: which parameter does ratification-first assume into existence, which parameter does sponsorship of the A2A kind actually move — C, via donated SDKs and secretariats, rather than b — and why Section 19.5 accordingly scores that altitude “the most nearly a hope” as a monitoring instruction rather than a verdict; close with the case in which the coordination problem vanishes because one owner holds both endpoints, and the practical rule the chapter derives for the team’s own estate.
Further exercises for this chapter continue in the web edition’s exercise bank.
The principle is Jon Postel’s, laid down in the 1980 TCP specification: “be conservative in what you do, be liberal in what you accept from others” (RFC 761, https://www.rfc-editor.org/rfc/rfc761).↩︎
RFC 9413, Maintaining Robust Protocols (IAB, 2023, https://www.rfc-editor.org/rfc/rfc9413), which argues that silently tolerated errors decay a protocol ecosystem, and that liberality in what you accept should be traded for strictness plus actively maintained specifications.↩︎
https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation.↩︎
From Clark’s plenary talk at the 24th IETF meeting, July 1992; the original slides survive at https://groups.csail.mit.edu/ana/People/DDC/future_ietf_92.pdf.↩︎