Agent Delegation Through the Lens of RIP and BGP
Agent frameworks usually model a handoff as a tool call. The OpenAI Agents SDK exposes transfer_to_<agent_name>, and AutoGen’s Swarm uses a similar pattern in which a language model selects the next branch. For a fixed team declared before execution, that gets the job done. Once agents can discover peers, delegate recursively, lose capabilities, or recover from failure, the handoff depends on distributed state and inherits the usual distributed-state problems. Each participant may hold a different or outdated view of available destinations and authority. A coordinator may route procurement to sourcing, sourcing may route approvals to finance, while finance still routes procurement back to the coordinator based on an earlier configuration. Each transfer appears locally reasonable, but the task loops globally, in effect, a routing loop. Prompt instructions cannot fix this because changing one model’s behaviour does not update stale state held elsewhere.
What routing history teaches
Routing protocols have dealt with this shape of problem for decades, and network engineers have catalogued the ways it goes wrong. Those lessons transfer as principles even where the mechanisms do not map directly.
- Claims need a liveness rule. Routing state cannot remain valid forever independently of the peer that advertised it. An agent capability should likewise expire, be renewed, or become invalid when its advertising relationship fails.
- Withdrawal must be explicit. Silence is ambiguous: a quiet peer might be slow, partitioned, or gone. Routing protocols can announce that a route is dead rather than simply omitting it. An agent that loses access to a system should emit a withdrawal immediately, which peers propagate on receipt.
- Paths must be recorded. Early protocols like RIP could form loops because their advertisements carried distance but not the full path by which a route had been learned. A fix is to carry a path inside the message, akin to how BGP prevents loops in route advertisements. Applied to delegation, every agent that forwards a task appends itself, and every agent rejects a delegation whose path already contains its own identity (no, you probably don’t need blockchain for this, just use a normal append record). The recorded path prevents loops and lets a receiving service apply policy to the lineage: a finance agent can accept tasks that stayed inside the company and reject tasks that crossed an external broker.
- Versions must only move forward. Each authoritative record carries an issuer-scoped version that increases and never repeats. Once an agent has seen version 42 for that record, it rejects version 41 regardless of how plausible the presenting agent sounds. In a distributed system, old state is always still in flight somewhere and refusing lower versions keeps it from becoming current again.
Reachability is not the same claim as authority
An advertisement can say two things that look alike. 1) I can find suppliers. 2) I can approve purchases. The first describes capability, and the second describes authority. An agent should never acquire authority because another agent advertised it.
Authority travels with the route but has to be verified on its own, and one concrete delegation shows the whole rule. For example:
A coordinator holds a token allowing purchases up to €5,000 on one project. When it delegates sourcing, the child token carries the same project, a €1,000 ceiling, a shorter expiry, and no permission to delegate again. Every hop can shrink what a token allows and no hop can grow it, so an agent three steps down the chain cannot talk its way back up to €5,000, and a peer advertising “I can approve purchases” hands it nothing.
Macaroons use contextual caveats to attenuate delegated web credentials. A 2026 Internet-Draft applies the same narrowing rule to agent delegation chains, with the whole chain verifiable against the issuer’s trust anchor.
Independent verification also limits delegation forgery. A compromised or malicious agent cannot establish authority merely by claiming that another agent delegated it. The recipient verifies the credential chain back to the original trust anchor, including its scope, expiry, and attenuation at each hop.
Everything above governs who may be handed a task and with what authority. The action itself can still go wrong: a lost acknowledgement produces a second payment, or two delegates reach the same executor at once. Handling that takes operation identities, deduplication, and a deliberate commit boundary. The Cordon research system, for example, stages and validates external effects before releasing them.
Keep the state outside the model
The model is good at deciding what work should happen next and which specialist suits it. It should not also be the system’s memory of which delegations are current. Let the model request a route and let a control service answer with eligible ones, after checking signature, expiry, version, loop, and attenuation in plain code without a model in the path. The model chooses among survivors where semantic judgment helps. It is restricted from inventing delegates, widening tokens, erasing paths, or restoring expired routes through persuasive text.
Operators also get visibility into revocation propagation time, stale advertisements, rejected loops, and the exact path behind any committed action as opposed to standard transcripts that only show that one model called another.
None of this requires running a routing protocol between agents. It requires the state those protocols were forced to make explicit: recorded paths, expiring claims, announced withdrawals, and monotonically increasing versions. Frameworks currently leave all of that to the application, so the state exists whether or not anyone builds a place to read it.