The next agent opens the project and asks what it should do. The previous one already investigated the problem, rejected an attractive but unsuitable approach, and prepared a partial result. How much of that work can the new participant recover without asking a person to reconstruct it?
An AI agent handoff is the transfer of responsibility together with enough evidence to continue it correctly. It includes the objective, applicable decisions, current results, unresolved work and limits on what may happen next. Passing the original prompt preserves only a small part of that information.
You can examine handoff quality with a practical test. Give an incoming agent a project it has not seen, ask it to continue a bounded responsibility, and inspect the decisions it makes from the available records. The exercise below provides a method and a fictional case, not a report of measured model performance.
What needs to survive the change of agent?
Continuity is useful when it preserves meaning. An incoming agent needs to distinguish work that has been completed from work that was merely proposed. It must know whether a result is still applicable and which source establishes that status.
Some context can remain specific to the original environment: an unsaved file, a local tool session or a detail held in a conversation that another client cannot read. A handoff should identify those dependencies and preserve the necessary outputs in a location the next participant is authorized to access.
The receiving agent may use a different model, tool set or execution environment. That makes readable project records important. It also means that access must be checked independently. A source reference can identify a file without giving the new agent permission to open it.
The Agent2Agent protocol's task guide illustrates a related distinction: interactions can share task context, while clients still need to manage the relationship between original and revised Artifacts. A communication mechanism helps participants exchange information; the application must preserve which result the team intends to use.
A handover with an unfinished decision
Consider a company replacing the system that renders its transactional emails. It wants to move order confirmation messages to the new renderer while leaving password recovery and marketing messages unchanged.
The outgoing agent has compared several templates and prepared a migration checklist. A design discussion contains a suggestion to include translated messages in the same change. The delivery lead has not accepted that suggestion. Two currency display cases still need investigation.
Create five short source records for the exercise:
| Record | Contents |
|---|---|
| Scope S2 | The accepted change covers English order confirmations. Password recovery, marketing and translated messages are excluded. The delivery lead owns scope changes. |
| Proposal P4 | A designer suggests adding translated confirmations. The record is marked as a proposal awaiting a decision. |
| Check log L7 | The recorded comparison covers 32 synthetic message fixtures. Thirty matched the accepted expectations. Two Japanese yen display cases remain unresolved. The log identifies the renderer revision it examined. |
| Draft D3 | A migration checklist describes the 30 matched cases and lists the two unresolved ones. It has not been accepted as a release decision. |
| Activity A9 | A preview batch was rendered locally. No customer messages were sent and no production routing was changed. |
The numbers and records belong to this fictional exercise. They make the expected interpretation inspectable. The check log is a claim about a particular comparison, so the receiving agent should preserve its revision and scope when discussing the result.
The incoming assignment is to prepare the next validation plan and identify what blocks a release recommendation. Sending email, changing routing and accepting the proposal are outside the assignment. Keep the exercise in a test environment with those actions unavailable.
Compare three ways of introducing the work
Prepare three starting packets for separate sessions. Each session should use the same incoming assignment and have access to the same permitted source collection.
Packet A contains the original request to replace the transactional email renderer. It gives no account of subsequent decisions or investigation.
Packet B adds a short conversation summary: most fixture comparisons matched, the checklist is drafted, and the team discussed translation. This is a plausible summary, but it leaves important distinctions to be recovered from the underlying evidence.
Packet C provides a structured handoff. It identifies S2 as the accepted scope, links the proposal without treating it as accepted, names D3 and L7, records the unfinished currency checks, and states what the previous agent did and did not execute.
Keep a source index equally available in all three conditions. Otherwise, the comparison may simply measure whether one agent had the evidence while another did not. Here the variable is how the handoff introduces and organizes information that participants can retrieve.
For a separate test of a missing source, remove it deliberately in every relevant condition and record that change. Evaluate whether the agent asks for the missing evidence or continues with an unsupported assumption. Do not combine those results with the complete source test.
Judge the continuation by its consequential decisions
A useful response should preserve the accepted scope, treat translation as unresolved, identify the two currency cases, and keep a partial comparison separate from readiness to release. It should also avoid claiming that customer mail has already moved to the new system.
Ask a reviewer to inspect the output and any source reads that are available. Evaluate the following dimensions separately:
Scope: does the plan stay within the accepted change?
Evidence: can the reviewer trace important statements to the right records and revisions?
Remaining work: are the unresolved checks carried forward accurately?
Execution state: are a rendered preview and a production change distinguished?
Authority: does the agent leave consequential decisions with the responsible person?
Record time and repeated investigation as secondary measures. An agent might reach a correct result through a longer source search. Another might produce a quick, polished plan that incorrectly includes translation. Those outcomes should remain distinguishable.
Treat an unsupported release recommendation or an attempted customer send as a serious failure even if the rest of the response is accurate. A total score can hide such a mistake. Our guide to LLM evaluation explains why acceptance criteria should follow the consequences of the task.
There are several valid next plans. One may begin by examining the currency expectations; another may first confirm that the available fixtures correspond to the current renderer revision. The test should accept sound reasoning supported by the record, without requiring a particular phrasing or sequence.
Keep the comparison fair enough to learn from
Use fresh sessions so one condition does not inherit knowledge from another. Record the model, client, relevant settings, available tools, time limit and source versions. Randomize the order in which conditions are run, and repeat them across more than one case if the result will inform a product decision.
Do not allow a session from Packet C to write corrections into the collection later used by Packet A. Give each run an isolated working copy. Keep any persistent personal memory or shared scratch space out of the test unless it is explicitly part of the design.
The incoming agent also needs enough operating instructions to use the tools. Equal access on paper is insufficient if only one condition knows how to locate the source collection. Provide the same connection and retrieval instructions to every condition.
Have the reviewer use a recorded answer key based on the source records. A second reviewer can examine ambiguous cases. If a model helps grade outputs, validate its judgments against human review before relying on them.
A few successful continuations reveal what happened in those sessions. They do not establish that a handoff format will work for every model or responsibility. The most useful result may be a specific failure, such as a summary repeatedly losing the distinction between a proposal and an accepted decision.
Separate project handoff from runtime recovery
A project record helps a different participant understand the work. A runtime checkpoint serves a related but narrower purpose: preserving execution state so a particular system can resume.
For example, LangGraph's persistence documentation distinguishes checkpoints of a thread's graph state from stores holding application data across threads. A saved execution position is valuable inside that runtime. It does not by itself make the project understandable to an unrelated agent in another environment.
Both forms of continuity may be needed. The running application needs a safe way to recover, while the wider team needs a readable account of what happened and what remains. Avoid using an execution status as the sole explanation of project readiness.
Our article on agent harnesses covers recovery and execution controls. For selecting what an incoming model needs to see, the complementary practice is context engineering.
Make the handoff a maintained part of the project
Swarm Spaces can retain the discussion, source Artifacts, decisions and recorded Runs around the email migration. The outgoing participant can leave a reviewable checkpoint, and an authorized incoming agent can retrieve the relevant records before continuing.
For this exercise, keep the accepted scope and the proposal clearly identified. Store the draft plan with the evidence it uses, preserve the check log's revision, and record the next responsibility. The incoming agent should be able to explain why the two currency cases remain open without depending on the original conversation.
A human can then review the proposed continuation in the same project context. If the team accepts translation later, record that decision and update the affected plan. The old handoff remains useful as history, while the current task must point to the revised scope.
The connection guide describes access from compatible agent tools. Each participant still needs the appropriate connection and an environment capable of doing its assigned work.
Ask what the next participant can establish
A good handoff allows a new agent to recover the applicable facts, question uncertain ones and propose a sensible continuation. It should also make the limits of the record apparent.
Try the exercise with a small real responsibility after removing sensitive data and disabling consequential actions. Preserve the actual outputs and review them against the same criteria. When a continuation fails, improve the source record, retrieval path or handoff according to the failure you observed.
The question is whether useful work survives the change of participant. Answering it requires examining what the next agent understands and does, not simply whether the original conversation was saved.