a2a — When AI Agents Talk to Each Other

Most AI agent frameworks follow a master-slave model. One "orchestrator" agent controls everything — it delegates tasks, collects results, and makes all the decisions. This works for simple workflows, but it breaks down when agents need to debate, disagree, or discover solutions the orchestrator did not anticipate.

a2a takes a different approach: agents talk to each other as peers. There is no central chain of command. Each agent decides who to message, what to share, and when to escalate. The framework is just the message bus — a shared SQLite database that agents use to discover each other and exchange messages.

No Orchestrator, No King

In a2a, every agent starts independently. They connect to the same SQLite bus, announce their capabilities via a structured manifest, and listen for messages that match their expertise. When an agent needs help — a code review, a security audit, a deployment — it broadcasts a request. The agents that can help respond, and the conversation proceeds as a peer-to-peer exchange.

This means you can have a Claude agent debating with a GPT-4 agent, a local Pi agent running specialized analysis, and a terminal-based agent executing commands — all in the same conversation, all as equals. No single point of failure, no bottleneck, no dictatorial orchestrator telling everyone what to do.

SQLite as the Bus

The message bus is a SQLite database. Every message is a row. Every agent reads and writes to the same file. This is deliberately simple — no Kafka, no RabbitMQ, no Redis. A SQLite file that lives in ~/.a2a/{project}/database.db. Back it up with your project. Sync it with your team. Fork it to replay a conversation.

A SQLite bus means every agent has full, queryable access to the entire history. An agent can search past conversations for relevant context, analyze patterns across multiple sessions, or resume a discussion that another agent started hours ago. The database is the memory.

Built for AutoMaintainer

a2a was built for AutoMaintainer. The multi-agent fleet that reviews PRs, runs tests, and ships code is powered by a2a's peer-to-peer architecture. Each agent in the fleet — the code writer, the reviewer, the tester, the deployer — is an independent process that communicates via the shared bus. When the reviewer finds an issue, it messages the writer directly. The writer fixes it and messages the tester. The orchestrator is just another agent in the conversation, not the controller.

This is why AutoMaintainer can run a verified gate without a single point of failure. If one agent crashes, the others continue. The conversation persists in SQLite. The work recovers.

Beyond Code

The a2a pattern works for any multi-agent scenario. Research teams where agents divide papers to analyze and share findings. Trading systems where a data agent, a strategy agent, and a risk agent negotiate positions. Customer support where a triage agent, a resolution agent, and an escalation agent handle tickets as peers.

Anywhere you need multiple AI agents to work together without a central commander, a2a gives you the bus. The agents bring the intelligence.

a2a-skill on GitHub — open-source, MIT, SQLite-powered agent coordination.

Next in this series: The Self-Hosted Stack — tying it all together.