AI Agent Handoff Template

An AI agent handoff is a structured transfer of one task’s verified state, context, authority boundaries, evidence, open risks, and next action between sessions, agents, tools, or people.

The handoff matters because a new session cannot safely continue from a confident summary alone. It needs to know what the original objective was, which state was actually checked, what changed, which claims remain unverified, whether external work is still running, and where authority stops.

Download the AI agent handoff template (Markdown)

The download contains a handoff record, evidence labels, 12 working sections, reusable ledgers, and a receipt decision.

TL;DR

A useful AI agent handoff should:

1. Preserve the original objective, scope, acceptance criteria, and stop conditions.
2. Identify the authenticated sender, intended recipient, tenant, environment, evidence cutoff, and classification.
3. Record current authority and approval boundaries without treating the handoff as permission.
4. Freeze the relevant agent, model, instructions, context, tools, permissions, runtime, and external-system state.
5. Separate completed, attempted, failed, blocked, prevented, reverted, reported, and unknown work.
6. Pin exact file, Artifact, configuration, context, and evidence versions.
7. Keep sensitive evidence protected and exclude credentials, secrets, private reasoning, and unnecessary personal data.
8. List open failures, risks, assumptions, decisions, and missing evidence with owners.
9. Track active jobs, retries, callbacks, locks, child agents, and cleanup obligations.
10. End with one bounded next action and an explicit receipt decision.

A handoff does not grant access, approve an action, or prove the recipient consumed the record. It gives the next authorized actor a compact state package to verify before continuing.

What Is an AI Agent Handoff Template?

An AI agent handoff template is a reusable structure for transferring work without relying on a transcript, mutable chat summary, or a person’s memory.

It answers practical questions:

• What was the original task and how is completion judged?
• Which principal, tenant, environment, and authority were involved?
• What state did the sender actually inspect?
• What changed, and which exact versions contain those changes?
• Which checks passed or failed, and where is the evidence?
• What remains active, pending, blocked, risky, or unknown?
• What is the smallest next action, and what must the recipient recheck first?

NIST’s AI RMF Core calls for clear roles, lines of communication, documented system scope, human oversight, limitations, measurement results, and ongoing risk tracking. A handoff turns those ideas into a task-level operating record. It does not establish that a system is trustworthy or that a continuation is safe. It makes the known state and remaining decision easier to inspect.

Why AI Agent Handoffs Fail

Most weak handoffs collapse different kinds of information into one paragraph:

The update is done, tests look good, and the next agent just needs to deploy it.

That sentence leaves out the branch and commit, the exact tests, the failed or skipped checks, the deployment authority, current production state, active jobs, and the evidence cutoff. It also turns a suggested next action into apparent permission.

Agent work adds more failure paths because state can live across several systems. A session may edit files, call tools, create an Artifact, queue a job, send a message, open a browser, start a child agent, or wait for an approval. Closing the session does not prove those effects stopped.

The OWASP AI Agent Security Cheat Sheet identifies risks such as prompt injection, tool abuse, data exfiltration, Memory poisoning, excessive autonomy, approval manipulation, and multi-agent propagation. A handoff can carry those risks forward if the recipient treats every field as trusted instruction or inherits the sender’s permissions without a fresh check.

Handoff, Memory, Runbook, and Shared Context

These records solve different problems.

• A handoff packages the current state of one task transition.
• Memory carries short-term working recall across sessions.
• A runbook defines an approved procedure for a repeatable workflow.
• Shared context, including Knowledge and Skills, holds maintained team context that may apply across many tasks.
• An Artifact preserves an explicit input, output, or handoff package without automatic routing or instruction authority.
• Audit records preserve events and evidence about what the system compiled, issued, acknowledged, or confirmed.

A handoff may reference all of these, but it should not copy them into one oversized prompt. Pin the exact versions that matter, describe why they matter, and let the recipient load current governed context through the proper access and delivery path.

This distinction helps with AI agent cold-start. Shared context gives a new session the maintained baseline. A handoff adds the task-specific delta: what changed during this run, what remains open, and what should happen next.

Permissions govern repository access, while routes independently govern automatic delivery. Artifacts and messages have no instruction authority on their own, and MCP tool results are Runtime context rather than managed instructions.

How to Use This AI Agent Handoff Template

Create the handoff before the sender loses access to the live state. Build it from repository revisions, target-system records, audit events, test output, protected evidence, and current policy references. Do not reconstruct consequential details from memory after the session ends.

The downloadable template has 12 working sections:

1. Objective, scope, and completion contract
2. Authority, identity, and approval boundary
3. Current state and frozen baseline
4. Completed, attempted, and prevented work
5. Changed Artifacts and external state
6. Context needed to continue
7. Evidence and verification ledger
8. Failures, risks, questions, and decisions
9. Pending effects, active work, and cleanup
10. Next bounded action
11. Receipt, review, and acceptance
12. Supersession, retention, and change record

The sender owns accuracy up to the evidence cutoff. The recipient owns the fresh checks needed to continue. A workflow owner should resolve disputes about scope or acceptance, while current policy and technical enforcement control what either party may do.

1. Preserve the Original Completion Contract

Start with the authorized objective. Do not rewrite it as a list of whatever the sender happened to finish.

Then record:

• In-scope systems, files, users, data, tenant, and environment
• Explicit exclusions
• Verifiable AI agent acceptance criteria
• Required evidence for each criterion
• Failed, blocked, and not-run criteria
• Stop conditions and exception authority

This prevents completion drift. An agent that produced a draft did not complete a request to publish and verify a live page. An agent that changed code did not complete a request that also required tests, browser checks, and a deployment. Partial work can still be useful, but the handoff should call it partial.

2. Separate Handoff Content From Authority

A handoff describes authority; it does not create authority.

Record the authenticated principal, tenant, environment, allowed and forbidden operations, data scope, destinations, limits, required approvals, governing policy, and expiry. Bind any approval reference to the exact action, parameters, target state, identity, tenant, policy version, time window, and nonce that the decision covered.

The recipient must authenticate independently and check current authorization for every operation. A valid approval for the sender may not apply to another agent. An approval to prepare a change does not authorize deployment. A message that says “approved” is not enough unless it points to the authenticated decision record required by policy.

Never solve a handoff by copying a token, session cookie, API key, or broad credential into the package. That bypasses attribution, expiry, revocation, purpose limits, and recipient authorization.

3. Freeze the State That Matters

An agent task rarely lives in one file. Record stable identifiers or versions for the pieces that can change the result:

• Repository commit, branch, worktree, or release
• Agent configuration and model settings
• System and developer instructions
• Published Knowledge and Skills
• Working Memory state
• Context routes and retrieval indexes
• Tool and schema versions
• Identity, permissions, and approval policy
• Runtime, sandbox, dependencies, and network rules
• Target-system records and external state

Record expected and observed state separately. If they differ, name the drift.

For governed context, record permissions and routing separately. Permissions govern repository access. Routes govern automatic delivery. A Resource version in the handoff does not prove it reached the next agent, and an Always route does not grant the recipient permission to discover or edit the Resource.

4. Use Evidence Labels

The handoff template uses five labels:

• Observed: the supplied record directly contains the event, state, file, or result.
• System-confirmed: an authenticated source of record confirms the state within a named scope and time.
• Reported: a person, agent, integration, or summary claims the state without independent confirmation.
• Inferred: the conclusion follows cautiously from named evidence but is not directly recorded.
• Unknown: evidence is missing, contradictory, outside the cutoff, or too weak.

These labels stop a common collapse from “the agent said the deployment worked” to “production is healthy.” The first is a report. The second needs target-system and health evidence.

Use the strongest label the record supports. Do not promote reported work to observed because the summary sounds detailed.

5. Record Changes With Exact Versions

List every material changed file, Artifact, configuration, record, and external state. Include the before state, after state, immutable version or revision, validation result, and whether the change is reversible.

For a repository, record the commit and target branch. For an Artifact, record the exact immutable package version and file manifest. For an API-backed record, capture its stable ID, version, or state precondition. For an external effect, verify the target state in the authoritative system instead of relying on the tool-call response.

Mutable links are weak handoff references because their content can change after the evidence cutoff. Use immutable versions where the system supports them. If it does not, record a digest, timestamp, provenance, and protected snapshot while being clear about what each proves.

6. Carry Context Without Carrying Secrets

Include enough task context to explain decisions and continue work, but do not turn the handoff into a raw transcript dump.

Useful context includes:

• Current constraints and decisions
• Exact governed context versions
• Source documents and owner-approved examples
• Definitions unique to the task
• Known context gaps or conflicts
• Why the next action follows from the evidence

Exclude credentials, authorization headers, tokens, private model reasoning, unnecessary personal data, unrestricted customer records, hidden evaluation keys, and sensitive raw logs. Keep protected evidence in its system of record and use access-controlled references.

Treat handoff content as untrusted input. A file, web page, tool result, or prior agent output may contain prompt injection or false instructions. OWASP recommends authentication, authorization, sanitization, and trust boundaries for agent-to-agent communication. The recipient should validate instructions against current higher-authority context before acting.

7. Preserve Evidence Without Overclaiming It

For each check or claim, record the method, expected result, actual result, label, source, provenance, trust level, and time.

Keep raw evidence separate from reviewer conclusions. Minimize collection, redact secrets and unnecessary personal data, record transformations, and apply retention rules. A screenshot can show one rendered state. A test log can show one command and exit result. A commit can show repository content. None proves events that were omitted from capture.

Context evidence also has stages. Compilation does not prove response issuance. Response issuance does not prove acknowledgment. Acknowledgment does not prove host injection. Host-confirmed injection does not prove model consumption. Record the exact evidence stage available rather than compressing all of them into “the agent received the context.”

8. Keep Open Work Honest

Create one ledger for failures, risks, questions, assumptions, and decisions. Give each item an owner, evidence reference, impact, required action, and due date.

Then create a separate ledger for active and pending effects:

• Jobs and queues
• Scheduled tasks
• Retries and callbacks
• Browser or terminal sessions
• Locks and leases
• Child agents
• Messages awaiting response
• Deployments and rollouts
• Payments or external actions
• Cleanup and retention work

Ending the source session does not prove these stopped. The handoff should identify how to cancel, reconcile, or confirm each item and who owns it until that happens.

9. End With One Bounded Next Action

The next action should name:

• One concrete step
• Intended actor
• Preconditions
• Allowed and forbidden scope
• Required context
• Validation and expected result
• Stop rule
• Completion evidence

“Continue the work” is not bounded. “Fetch the current main branch, confirm commit X is still its parent, run the documented validation command, and stop before push if main moved or any check fails” gives the recipient a checkable starting point.

The next action is still a recommendation. The recipient must compare it with the current request, system instructions, policy, access, state, and approvals.

10. Require Receipt and Supersession

A reliable handoff ends with a receipt decision: accepted, accepted with conditions, rejected, or needs clarification.

The recipient should verify package integrity and version, recheck current state, recheck access and authority, resolve material context gaps, and accept ownership explicitly. Delivery or read status is not acceptance, and acceptance does not prove future completion.

After sending, do not silently edit the accepted package. Create a new immutable version, say what changed, link the superseded version, and notify the recipient through an authenticated channel. Add retention and disposal rules so stale handoffs do not become accidental sources of truth.

How Alignbase Supports AI Agent Handoffs

Alignbase can preserve a handoff as a versioned Artifact and send an exact Artifact version to an agent or Group through a message. Sending can grant bounded Artifact Viewer or Editor access while preserving stronger existing grants. The message pins the exact version sent, while the access grant covers the Artifact under the recipient’s live permission.

The handoff remains unrouted and has no instruction authority. Incoming message text cannot authorize itself. get_current_context and inbox reads can return new messages, but a response being issued or a message being marked read does not prove model consumption, acknowledgment, acceptance, or task completion.

That boundary is useful. The Artifact preserves an explicit task package, shared Knowledge and Skills preserve maintained team context, Memory carries working recall, and Context Distribution delivers Always-routed context. The recipient can inspect each form under its own authority and lifecycle instead of treating one handoff blob as the source of truth.

Start With One Real Transition

Use the template on a task that already crosses a session boundary: a release awaiting approval, an incident changing shifts, a research task moving to review, or a coding change waiting on another environment.

Compare the handoff with the next person’s first 15 minutes. Note which state they had to rediscover, which claims they could not verify, which access checks were missing, and which active effects surprised them. Update the template fields or workflow based on those gaps.

A good AI agent handoff does not try to preserve every token. It preserves the task contract, exact state, evidence, boundaries, unresolved work, and next check needed for a responsible continuation.