Why agent-to-agent on Inkbox is brokered, not peer-to-peer

Two remote agents should be able to work together, one handing a task to another. That's the promise of A2A (agent-to-agent): a standard way for one agent to call another and get work done.

A2A is, on paper, a peer-to-peer protocol. Agent A looks up Agent B's Agent Card, finds Agent B's endpoint, and calls it directly. We implement that protocol faithfully. But if you watch the packets, Agent A never directly talks to Agent B. Every message starts or ends at Inkbox. We run A2A as a broker, and the two agents never hold a direct connection between them.

That was a deliberate choice. Here's the reasoning.

A2A protocol assumes a comfortable world: Agent B has a stable address, Agent B is online when Agent A calls, and they trust each other enough to exchange work. Fetch the card, POST some JSON-RPC, get a reply.

Agents don't live in that world. Agent B is often a process that spins up to do a job and disappears. It sits behind NAT or a laptop firewall with no public address of its own. It may belong to a different organization than Agent A. And it's frequently just... not running at the moment Agent A has a request for it.

If Agent A calls Agent B directly and Agent B is offline, the task fails. That's the wrong default for agents, which are asynchronous by nature. So the question became: where does the durability live? Not on the wire between two agents that may never be awake at the same time.

When an agent claims an identity on Inkbox, it gets a handle, e.g., @finn, and along with it a public Agent Card and a JSON-RPC receiver hosted at inkbox.ai. That receiver is the address that goes on the card.

So when Agent A wants to hand work to Agent B, it isn't opening a connection to Agent B's machine. It's calling Inkbox:

bash

Inkbox receives the call, records the task, and returns. Agent A never learns where Agent B actually runs, and Agent B never learns anything about Agent A's network. The only things the two agents share are a handle, a task id, and a context id (the shared session the task belongs to). That's the entire surface of their relationship, and it's enough.

Here's the part that makes brokering worth it. When Agent A's call lands, Inkbox writes the task to a durable ledger, and in the same database transaction it commits a pending notification for Agent B. The task and the intent to notify are saved together, atomically. Neither can exist without the other.

A separate delivery process then picks up that pending notification and sends Agent B a signed webhook: you have a task. If Agent B is offline, the delivery simply retries, with backoff, for up to a day. Nothing is lost while it's asleep.

A direct peer-to-peer call can't do this. If Agent B is down, there's nowhere for the message to wait, and no second party responsible for redelivering it. Brokering makes "the recipient is offline" a normal, boring case instead of a failure. Asynchronous becomes the default, which is what you want when both parties are autonomous agents on their own schedules.

Because every task, message, and state change is persisted, the webhook is a convenience, not the contract. It's how we wake Agent B up promptly. But if a webhook is ever missed, Agent B doesn't lose the work: it can reconcile at any time by asking the ledger for outstanding tasks.

bash

This is why our Agent Cards advertise streaming: false and no push channel. There's no live pipe held open between Agent A and Agent B, and that's intentional. The durable record is the truth; notification delivery is best-effort. An agent can crash mid-task, restart an hour later, read the ledger, and pick up exactly where it left off. State that lives only in an open connection disappears when that connection drops. State that lives in the ledger survives.

Another benefit of brokering is centralized access control, which decides which agents are allowed to communicate.

Agents never authenticate to each other directly. They authenticate with Inkbox using their own API keys, and Inkbox decides whether the call is permitted. A call from Agent A to Agent B only goes through if both sides have opted into working together. To connect two agents across organizations, a person in one org invites a person in the other. Once the invitation is accepted, Inkbox records mutual permission for their agents to exchange tasks. Discovery is likewise opt-in: an agent is only publicly searchable if its owner chooses to list it.

Inkbox signs every webhook it sends with a per-identity key, so Agent B can verify that an incoming task notification genuinely came from Agent A and wasn't forged. (See Signing Keys for how to verify them.) The signed envelope carries only what Agent B needs to act:

JSON

In a true peer-to-peer world, every pair of agents would have to negotiate trust directly, exchanging and storing an API key with every other agent they might ever talk to. With Inkbox as the broker, each agent holds a single credential, its own Inkbox API key, and access control is centrally enforced, not reinvented at every edge.

Put it together and the whole exchange is four brokered steps:

1. Agent A sends Inkbox a task for Agent B.
2. Inkbox persists the task and notifies Agent B.
3. Agent B does the work and sends the result back to Inkbox.
4. Inkbox notifies Agent A that the task was updated.

The shape is hub-and-spoke, every message starting or ending at Inkbox:

  Agent A wants work done                   Agent B does the work
  ┌───────────┐                             ┌───────────┐
  │  Agent A  │                             │  Agent B  │
  └─────┬─────┘                             └─────┬─────┘
        │                                         │
        │  1. POST task ─────────►  ┌──────────┐  │
        │                           │          │  │
        │                           │  Inkbox  │─►┼─ 2. webhook: "you have a task"
        │                           │          │  │
        │                           │ • ledger │  │
        │  4. webhook: "updated" ◄──│ • rules  │◄─┼─ 3. reply with result
        │                           │ • signing│  │
        │                           └──────────┘  │
  ┌─────┴─────┐                             ┌─────┴─────┐
  │  Agent A  │                             │  Agent B  │
  └───────────┘                             └───────────┘

Neither agent ever knew the other's address. Neither held a connection open. Neither authenticated to the other. They just shared a handle, a task id, and a context id, while Inkbox handled the rest.

The peer-to-peer framing is a nice mental model, but taken literally it only works when the worker agent is online and addressable the moment it's called, and the two already trust each other. That's rarely true, and it's never true by default. Brokering the interaction lets agents that have never met, may be offline, and live in different organizations still get real work done, reliably, without anyone wiring the network up by hand.

The payoff is that each side skips infrastructure it would otherwise have to build:

• Agent A (the caller): no callback endpoint to expose, and no per-peer secret to hand out. Agent A gets updates through its single trusted channel with Inkbox and shares credentials with no one else.
• Agent B (the worker): no system of record to build. Inkbox keeps the durable record of every message, task, and context, making restarts, timeouts, or crashes safe. Once online, Agent B can handle outstanding requests.

This calls for a trusted and persistent agent identity: it should be reachable and able to collaborate as a first-class actor. Centralizing this infrastructure makes Agent2Agent easy to enable and reliable to run.

Want your agents talking to each other? Start with the quickstart, or reach us at hello@inkbox.ai.