I do not want a tiny digital monarchy where one “main” agent knows everything and a flock of disposable workers waits for orders.
The setup I am interested in is closer to a team of peers: agents with the same standing, each responsible for a defined area, each using the model and tools that actually suit that area. One might be fast and cheap at digging through public documentation. Another might be slower but better at architecture. A third might own a narrow operational surface.
Same authority sounds tidy. It is also how you accidentally give six chatbots the keys to the same shed and discover nobody knows who left the lawnmower running.
That is why the useful part of A2A is not that agents can talk. Agents have always been able to talk if you are willing to glue enough HTTP requests together. The useful part is that A2A gives the conversation a contract: an Agent Card says what a peer claims to do and how to reach it; a Task has an ID, state, messages, and eventual artifacts; the agents do not need to expose their private memory, hidden reasoning, or tool implementations to collaborate.
Same authority is not shared root access
The first design choice is to separate standing from permission.
I can treat agents as peers in a decision-making sense while giving them radically different capabilities:
- A research peer can search the web, read public documents, and return cited findings. It cannot send mail, publish a post, or touch a production system.
- An operations peer can inspect a service and prepare a repair plan. It still needs an explicit approval before it changes anything outside its own scratch space.
- A publishing peer can format a finished article, but it should receive an approved body and image—not a free pass to rummage through every private note looking for inspiration.
That is not hierarchy. It is an ownership boundary.
The model choice belongs inside that boundary too. I do not need the biggest reasoning model to count rows in a CSV, and I do not want a bargain model deciding whether an unfamiliar request is safe to run against a live system. “Best” is not a global setting. It is a property of the task, the cost, the failure mode, and how reversible the result is.
Give every agent a job description that could survive contact with reality
An Agent Card is useful for discovery, but it is not a magical résumé that deserves blind trust. Before I let one agent call another, I want a small human-readable contract for each peer:
- What problem does it own?
- Which tools may it use?
- What inputs are allowed to cross into its context?
- What counts as a complete artifact?
- Which actions require my approval?
- Who owns cleanup if its task fails halfway through?
That last question is not glamorous, which is exactly why it saves you later.
For example, “research the available options and return three sourced recommendations” is a decent task. “Figure out the deployment” is agent soup. The first has a scope, a deliverable, and a natural stopping point. The second invites duplicate work, invented assumptions, and a suspicious amount of confidence.
A2A’s Task and context IDs are helpful here. They give a follow-up question somewhere to go without turning every new message into a fresh, amnesiac job. But a context ID is not permission to keep talking forever. I want a turn cap, a timeout, and a clear owner for the final answer.
Start with a one-way bridge
The safest early A2A setup is boring: one coordinator calls one specialist for a bounded task. The specialist returns a result. Nobody starts a group-chat cult.
This is especially important when two agents run on the same machine. Same host does not make them the same trust boundary. They can have different credentials, session histories, browser profiles, model subscriptions, and the kind of old assumptions that become expensive folklore.
A2A is the bridge between those boundaries, not an excuse to flatten them.
For a private setup, direct configuration is usually better than open discovery. I already know which peer I expect to call, so I would rather pin its local URL, give it a unique token, restrict its advertised skills, and keep the connection on loopback than publish a catalogue of every capability to the internet. Agent Cards are deliberately discoverable; that is useful, but it also means the description itself can reveal more than intended.
The habits I want from day one
A few rules make this much less exciting in the best possible way:
- One task, one owner, one side-effect authority. Two agents may advise on a deployment. Only one may execute it, and neither gets to do it without the right approval.
- Pass artifacts, not raw lives. Send the brief, the relevant facts, and a requested output shape. Do not shovel full personal transcripts, secret stores, or an agent’s entire memory across the wire.
- Treat peer output as evidence, not instructions. A trusted peer can still be wrong, compromised, or simply having a Tuesday. Validate claims, preserve normal approval gates, and never let a returned sentence become executable policy by accident.
- Use idempotency and explicit retry rules. A network timeout does not prove a task failed. Check task state or the intended external result before trying again, especially around publishing, payments, messages, and infrastructure changes.
- Cap loops and budgets. Limit turns, task time, retries, rate, and model spend. “The agents will work it out” is not a control plane.
- Log the handoff. Record who asked whom, what was requested, the result, and whether a side effect happened. Debugging a multi-agent system without that trail is archaeology with worse log formatting.
Where this is actually useful
I can see this paying off when the specialization is real:
- A fast research peer gathers current sources while an architecture peer turns them into a decision with trade-offs.
- A narrowly scoped operations peer checks a service and returns a repair plan, while the human-facing agent explains the consequence and asks for approval.
- A security-focused peer reviews an artifact for secrets and unsafe assumptions before a separate release peer touches a public surface.
- A local personal agent keeps private context private while asking an external specialist a deliberately sanitized question.
What I do not need is a committee of agents voting on whether to use a semicolon. More agents do not automatically produce more intelligence. They often produce more prose about process.
The real future I want is not autonomous agents with identical god-mode access. It is peers with clear ownership, constrained power, compatible protocols, and enough discipline to know when to hand the decision back to me.
Further reading: the A2A 1.0 specification, Agent Card discovery guidance, Hermes A2A documentation, and OpenClaw’s A2A channel documentation.
