Communication: when agents talk, and when they should not

The part closes on its most tempting trap. Multi-agent demos love showing agents in conversation, negotiating, debating, coordinating in prose. Production fleets mostly should not talk, and the systems that work treat inter-agent communication as a cost center admitted grudgingly, pattern by pattern. This chapter gives the three patterns in escalating order of power and regret, the independence tension that verification imposes on all of them, and a sober decode of A2A, the protocol for the cases where talking is genuinely the job.

Default: results-only

In the base pattern, agents never address each other at all. Workers receive units from the scheduler, write results (structured, schema-validated, evidence-linked) to the ledger, and the platform routes: verifier units reference finder results, the merger reads verified results, every hop a scheduled unit with budgeted spend.

This looks like the absence of communication; it is actually communication through the platform, and its properties are why it is the default: every message is durable, auditable, budgeted, and replayable, because messages are ledger entries. There is no conversation to transcribe, no emergent chatter to cap. The topology chapter's orchestrator-worker and pipeline shapes, and both meshes in the capstones, run entirely on this pattern. Exhaust it before the next one; it goes further than intuition suggests, because most "agents need to discuss X" cases are really "X should be a unit whose result others consume."

Sometimes: the blackboard

Some coordination genuinely cannot route through decomposed units, because it is discovered during them: two workers auditing different shards find related symptoms; a worker learns a fact (the repo vendors a second project) that changes everyone's job. The blackboard pattern gives the fleet a shared, structured workspace: a DynamoDB table or S3 prefix where agents post claims, indexes, and discoveries, and consult before acting.

The discipline that keeps blackboards from becoming swamps: data, not control. Healthy blackboard content is claim registries ("shard 17 taken"), dedup indexes ("finding-hash H already reported"), and discovered facts with provenance. Unhealthy content is instructions: agents steering other agents through posted prose, at which point you have rebuilt an orchestrator, minus the budget, audit trail, and determinism. Two mechanical cautions travel with the pattern: reads and writes are tool calls (spend), and, more subtly, a shared workspace is an injection surface between agents; one compromised worker can poison what every colleague reads, so blackboard entries carry provenance and the trust chapters treat them as untrusted input.

Rarely, then genuinely: A2A

The third pattern is direct agent-to-agent tasking, and its honest scope is narrow inside one platform: your own fleet already has a scheduler, so agents hiring each other through it is the results-only pattern wearing extra steps. Direct messaging earns its place at boundaries: your platform's agents engaging another team's agent, another company's, another vendor's, where there is no shared scheduler, ledger, or trust domain.

That boundary case is what A2A (Agent2Agent) standardizes, and the concepts chapter's one-liner can now be decoded properly. An A2A agent publishes an agent card (a signed capability description: what it does, how to reach it, how to authenticate); counterparties create tasks against it and follow a task lifecycle (submitted, working, input-required, completed, failed) with messages and artifacts flowing inside it. The governance matters as much as the wire format: donated to the Linux Foundation, spec at 1.0, with the major agent platforms (AgentCore Runtime and Strands on the AWS side included) shipping support, it is the current best bet for cross-vendor agent interop, in the same structural slot MCP occupies for tools.

The relationship to MCP deserves its precision back: MCP connects an agent to capabilities (typed calls, immediate results, no judgment on the far side); A2A connects an agent to counterparties (long-lived tasks, negotiation, judgment on both ends). The gallery's back-office agent filing a request with a supplier's procurement agent is A2A-shaped; that same agent reading its own company's pricing API is MCP-shaped, and mixing up the two produces either a tool call with feelings or a negotiation with a database.

The independence tension

One design constraint stretches across all three patterns, imposed by the mesh: verification requires ignorance. A refuter that has read the fleet's blackboard has read the finder's conclusions; a panel that shares a workspace shares a bias. Meanwhile dedup and coverage want sharing. The resolution the capstones use is phase separation: finders work blind (results-only, no blackboard reads), dedup runs as plain code between phases, verifiers judge blind, and only verified results reach the shared workspace that later phases consult. Sharing flows downstream of judgment, never upstream into it.

What to standardize, today

Closing the part with its buying guide: standardize your result and event schemas first (they are the platform's real protocol, and entirely yours); adopt MCP for tools now (mature, everywhere, and you have built it from scratch, so nothing about it is magic); adopt A2A when a genuine cross-boundary counterparty exists, not before; and let conversational multi-agent patterns stay in the demos until a measured task needs them.

Don't be confused: communication vs delegation. Delegation (spawning a sub-agent, Chapter 22) creates a subordinate whose budget, tools, and lifetime the parent's run controls through the scheduler. Communication addresses a peer whose behavior you do not control and whose messages you must treat as input, with everything Part 8 says about untrusted input. The same message content ("please audit shard 17") is an instruction in the first case and a request in the second, and systems that blur subordinate and peer end up trusting exactly the parties they should not.

Part 6 is complete: topologies chosen by physics, a scheduler in plain code, three AWS mappings, failure semantics that made a mid-run murder boring, a mesh that prices precision, and a communication doctrine of deliberate silence. The swarm machinery of the reference architecture now exists end to end in runnable form.

👉 Next, per the map: the supporting planes that ground this machinery on real infrastructure (Part 4's skeleton, Part 5's sandboxes), then memory, trust, and operations on the road to the capstones.