Agent-to-agent delegation

Two shapes, not one

A subagent is a specialist nested inside one parent. The parent hands off a task, the subagent runs in its own context, and a result comes back. It has no page of its own, no channels, and no ongoing memory between calls. It exists to do a job and report.

A peer is a separate top-level agent with its own page, its own channels and its own memory. One messages the other and waits for a reply, and the pair builds up a running relationship over time.

Choosing

One line: use a subagent when the work is a step inside someone else's job; use a peer when the other party has its own responsibilities, its own inbox and its own working memory.

Examples make it concrete. "Research this company before I draft the email" is a step inside the drafting job — subagent. "The support agent asks the billing agent about an invoice" is two colleagues with separate remits — peers. A support agent asking a billing agent is not a manager and a helper; both own their domain.

Second test, if the first is ambiguous: would it be odd for this thing to have its own inbox? If yes, subagent. If it would sensibly receive messages from people or other agents on its own account, peer.

Why the choice is expensive to get wrong

They are configured in different places and behave differently, so switching later is a rebuild rather than a setting. More importantly the memory model differs: a subagent forgets between calls by design, while a peer accumulates. Building a peer that should have been a subagent gives you an agent carrying context it does not need; the reverse gives you one that re-learns the same thing every time.

Setting up peers

Placement is set per agent, not by drawing on a chart:

• A manager — one, from a picker.
• Direct reports and co-workers — several. Setting one side updates the other, so naming an agent as your report makes you its manager without a second edit.
• Messaging permissions — receiving and sending, each either everyone, nobody, or a named list. Generating them from the org chart is the right default for most teams.
• A service restriction — optionally, peers get read-only service: they may ask questions, but tools that change something only run for the manager. Useful when one agent holds a sensitive connection.

Visibility is not permission

The control people miss, and the reason teams degrade into committees. Two separate settings:

• Visibility — which peers this agent is told exist.
• Messaging permission — which it may actually contact.

Knowing a colleague exists is not permission to message them, and the safe default is to tell an agent about nobody except those it can already reach. The reasoning is behavioural rather than security-theoretical: an agent that knows about twenty colleagues will try to involve them. It will ask for second opinions, forward things, and generally act like an over-eager new hire with everyone's number. A team where everyone can call everyone produces loops, duplicated work and a log nobody can follow.

Restricting the roster is cheaper than detecting the mess afterwards.

What good delegation looks like

• The task travels, the transcript does not. A handoff carries the question and the relevant facts, not the parent's history.
• The result comes back shaped. A subagent that returns its entire working has not helped.
• Failure surfaces. If the other side does not answer, the parent reports that rather than waiting silently.
• Approval stays at the edge. One gate on the thing that leaves, not a gate per hop.
• You can see it happen. Handoffs visible live, so you can tell a collaborating team from one agent doing everything.

A note on protocols

Delegation between agents inside one deployment is a platform concern. Delegation across organisations is a protocol concern, and the emerging standards for it — agent cards, agent-to-agent messaging over HTTP — are worth knowing about if you expect to work with someone else's agents. The security rule that matters there is the same one as above, with higher stakes: an agent should only be able to reach parties you named, never an arbitrary address it was given at runtime.