Fleet 1.13:Teams are now shipping 5x more PRs with autonomous pipelines.See what's new →
FleetFleet
Glossary

Agent Handoff

An agent handoff is the structured transfer of work from one AI agent to another, including the context, artifacts, and state information the receiving agent needs to continue without reprocessing everything from scratch.

Handoffs are the seams in a multi-agent system. Poor handoffs — where the receiving agent lacks context, receives ambiguous state, or has to redo work the previous agent already did — are a primary source of inefficiency and errors in multi-agent workflows. Good handoff design is as important as the individual agent implementations.

A well-structured handoff includes: what was accomplished (with references to artifacts like PR numbers, commit hashes, or file paths rather than re-embedding content), what decisions were made and why, what the next agent is expected to do, and any constraints or warnings the previous agent discovered. This is roughly equivalent to a good engineering handoff memo.

Handoffs can be synchronous (the previous agent waits for confirmation that the next agent received the context) or asynchronous (the previous agent publishes to an event bus and moves on). Asynchronous handoffs are more efficient but require careful event schema design to ensure the receiving agent has everything it needs in the event payload.

How this relates to Fleet

Fleet implements handoffs through fabric events. When an agent completes a stage, it publishes a structured event with the relevant context fields. Downstream agents receive this payload as an environment variable (FLEET_TRIGGER_PAYLOAD) when started. The schema of these events is defined by Fleet's event type catalog, ensuring consistent handoff structure across agent types.

Frequently asked questions

What information should every agent handoff include?

At minimum: the repository and branch the work is on, the issue or ticket number the work addresses, references to the artifacts produced (PR URL, commit hash, test results URL), a summary of what was done and what was not done, and any blockers or decisions that the next agent needs to be aware of. More detail is better than less; the receiving agent can ignore extraneous context but cannot recover missing context.

How do you handle handoff failures when the receiving agent is unavailable?

Event-bus-based handoffs provide natural retry semantics: the event remains in the bus until a consumer processes it. If the receiving agent is temporarily unavailable, the event waits. If no consumer appears within a configured timeout, the orchestration layer should alert a human operator. Designing for agent unavailability — rather than assuming all agents are always running — makes multi-agent systems significantly more resilient.

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.