AI Agent Handoffs: How to Give the Next Person a Receipt

The weakest moment in an agent workflow is often not the prompt or the tool call. It is the handoff.

Try the Zambo demo · Explore Zambo

An agent finishes a website audit, research task, code review, or operational check. Someone else - an account lead, a client, a developer, a finance reviewer, or a second agent - now needs to decide what to trust, what to act on, and what still needs checking. Too often, they receive a long chat transcript and a confident summary.

That is not a useful handoff artifact. It is a reconstruction problem.

A better default is to give the next person a receipt-centered handoff packet: a short delivery note that links the work to an inspectable record of the execution, identifies the evidence and limits, and states exactly what the recipient should do next. Zambo execution receipts are designed for this kind of handoff: they package a tool call as a stable record with request context, an observed result, a timestamp, and a SHA-256 commitment that can be checked later.[1]

A receipt is not a certificate of correctness. It does not prove that an agent’s analysis was right, that a recommendation should be implemented, or that an outside-world outcome occurred. It gives the next person a better starting point: a way to inspect what ran, what was recorded, and what evidence was or was not captured.[1][2]

Why chat transcripts make poor handoff artifacts

A chat is useful while work is in progress. It records questions, revisions, dead ends, and working assumptions. But it is a poor source of truth for a later reviewer.

This is not an argument for deleting transcripts. Keep them where they are useful for collaboration, debugging, and context. The point is narrower: do not make a reviewer read an entire conversation to understand one consequential piece of work.

Zambo distinguishes receipts from traces, logs, and metrics for the same reason. Traces explain a request’s route through systems; logs help investigate events; metrics show aggregate behavior. A receipt is the portable record for one selected execution that another person or system needs to inspect.[1]

The receipt-centered handoff workflow

A practical workflow has six steps. It works for a small consulting engagement, an agency delivery queue, or a product team’s internal review.

1. Define the review question before the agent runs

Write one sentence that the reviewer should be able to answer.

• “Did the audit run against the public production URL we approved?”
• “Which repository revision was reviewed, and what risks did the tool report?”
• “Was the draft analysis delivered with source links for the account lead to validate?”
• “Did the requested action reach the destination system, or did the system only accept the request?”

Then define the acceptance condition and risk level. A read-only website audit might need a receipt plus a spot check. A production code change, financial action, or customer message needs stronger controls: scoped authorization, a human approval, and an independent read-back from the system that owns the state.[3]

2. Keep the job scope narrow and shareable

Give the agent only the inputs necessary for the task. For a reviewable job, capture:

• the target and boundary (for example, a public URL, repository URL, branch or commit);
• the requested operation and intended output;
• the date/time window, if freshness matters;
• known exclusions; and
• a human owner for questions or escalation.

Do not put passwords, API keys, private keys, raw customer exports, or unnecessary personal data into the job. Zambo’s security guidance explicitly says not to submit credentials or secrets in a job.[3]

3. Run the tool and retain the receipt at the point of execution

When a completed tool call returns a Zambo receipt, save the receipt URL or ID alongside the job record - not later in a copied summary. The receipt provides a focused record of the call: its tool, time, status, recorded result, and integrity material for verification.[1][2]

For a staged task, retain the records that matter to the review. A website audit may have a receipt for the audit run and another for the completed report. A code audit may have a receipt tied to the submitted repository context. Do not flatten those into “the agent checked it.”

4. Add source evidence and an external read-back where the decision requires it

A verified receipt is still only one layer of evidence. If the tool captured source-backed evidence, include the source URL, capture time, and status. If the claim concerns a state outside the execution boundary - such as a published page, sent message, payment, deployment, or updated record - check that state in the system that owns it.

Use precise language:

“The audit tool ran against the stated URL and the receipt record passed its integrity check. The reviewer independently confirmed the cited page elements at 14:20 UTC.”

Not:

“The receipt proves the site is fixed.”

A matching output hash shows that the stored bytes match the stated commitment. It does not make an external value true, establish that a recommendation is correct, or prove that an outside action occurred without corresponding observed evidence.[2]

5. Write a short decision note - not a second transcript

The handoff note should answer four things in plain language:

1. What was requested and run?
2. What did the recorded result say?
3. What was independently checked, and what remains unobserved?
4. Who decides or does what next?

This is where a consultant adds judgment and a product operator adds operational context. The note should point to the receipt rather than paraphrase it into an untraceable claim.

6. Package, route, and retain the artifact deliberately

Send the client or internal reviewer one compact packet: delivery note, receipt link, evidence links, decision note, and next action. Store the same packet with the project or ticket. For recurring work, use a consistent naming convention such as:

client-project / job type / run date / receipt ID / reviewer status

Set a retention owner and a rule for corrections. If a source later changes, say so; a receipt can still show what was recorded at the time, but it does not guarantee that the provider’s current state is unchanged.[2]

What to include in a handoff packet

The goal is not to create a heavy compliance binder. It is to let a competent next person review one job without asking the original operator to reconstruct it from memory.

For low-risk, internal work, the packet may be a ticket comment with a receipt link and two bullets. For a client deliverable or a high-impact action, include the full scope, decision note, and independent confirmation.

A realistic example: handing off a public website audit

Consider an agency strategist who needs to hand a public website audit to an account lead before the client presentation. The agency asks an agent to review a public campaign site for SEO, AI discoverability, conversion, and presence gaps - the stated scope of Zambo’s ghost_audit_site workflow.[4]

The strategist creates a bounded job:

• Target: https://www.client-example.com/spring-campaign/
• Scope: Public pages only; do not test forms, authentication, or rate limits.
• Question: “Which observed page-level issues should the account lead validate before recommending a two-week remediation sprint?”
• Acceptance condition: Findings must identify the inspected URL or evidence source; the account lead will manually validate the three highest-priority items.

The agent starts the staged audit, monitors it using the audit status capability, and retrieves the report when complete. Zambo lists separate tools for starting a website audit, checking its status, and retrieving its completed findings and evidence.[4]

The handoff packet could read like this:

Website audit handoff - public campaign site
Decision requested: Confirm the three items to include in the client’s remediation proposal.
Scope: Public campaign URL only, run 12 June at 13:40 UTC. Forms and authenticated areas were excluded.
Execution record: Receipt: run/<receipt-id> - completed website-audit report. Verify the record before relying on the output.
Recorded findings: The report identified page-level opportunities in the requested audit categories. The linked evidence identifies the pages and observations to review.
Independent check: Account lead confirmed the cited title and heading issue on the live page at 14:05 UTC. The other two proposed findings remain pending content-team review.
Limits: This run is not a crawl of private pages, a guarantee of search ranking, or proof that implementing the recommendations will increase conversion.
Next owner: SEO lead validates the remaining two items; account lead approves the proposal wording.

Notice what this does not say. It does not pretend that an audit receipt proves the client’s traffic will rise, that a search engine will index a page, or that the recommended work has been implemented. It shows the run, retains the tool’s result and evidence, and gives the next person a clear validation task.

For a code audit, follow the same pattern with the exact repository reference - ideally a commit SHA or immutable archive - not “the repo.” Zambo’s code-audit tool reviews the supplied repository or code context for risks, debt, and an actionable plan; its findings are observations and recommendations, not evidence that a change was applied.[4]

Client delivery and invoice scenarios

Receipts are especially useful when a service delivery needs to be reviewable by people who were not present for the run.

Client delivery: show the work without overselling it

A client-facing delivery should include a plain-language summary, not a raw dump of agent output. Add the receipt as a review link or appendix reference:

Delivered: Public website audit and prioritized remediation brief.
Execution record: Receipt ID …; run date …; public-page scope ….
Client review requested: Confirm business context for priority order and approve which recommendations move to implementation.
Boundary: The receipt records the audit execution and reported observations. It does not guarantee rankings, conversions, regulatory compliance, or implementation outcomes.

This protects both parties. The agency makes its work inspectable; the client keeps responsibility for business decisions and any implementation approval.

Invoice reconciliation: link the charge to the delivered job

For a fixed-scope audit, a receipt can be a useful reference on the invoice or in the invoice backup:

The commercial claim should be accurate: the receipt helps reconcile a recorded execution to a delivered work item. It does not by itself prove that the client accepted the work, that every finding is correct, or that a promised business outcome was achieved. If the engagement is outcome-based, retain the separate measurement and approval evidence needed for that agreement.

For product teams, the same pattern works in internal chargeback or vendor review: charge → job/ticket → receipt → reviewer decision. It is much easier to investigate a disputed run when the ticket includes the execution record and scope rather than an exported conversation.

A review checklist for the person receiving the handoff

Use this checklist before approving an agent-assisted deliverable, sending it to a client, or taking a consequential next action.

• [ ] Confirm the decision question. What exactly am I approving, rejecting, or investigating?
• [ ] Match the receipt to the job. Check the receipt ID, tool, status, timestamp, and target against the stated scope.
• [ ] Check the execution status. A blocked, failed, paused, or partial call is not a completed task; do not rewrite it as success.[2]
• [ ] Verify the record. Use the published verification route and, where available, compare the output hash with the canonical bytes or verifier result.[2]
• [ ] Inspect source evidence. Open the cited sources; note their capture time and whether evidence is missing, unavailable, or only a preview.
• [ ] Perform an external read-back when needed. Check the system that owns the relevant state - such as the CMS, repository, payment processor, or deployment platform.
• [ ] Separate observations from recommendations. A tool’s reported issue may be useful without being a correct or complete diagnosis.
• [ ] Read the limits. Check exclusions, source freshness, privacy constraints, tool boundaries, and unobserved outcomes.
• [ ] Check authorization and approval. A valid receipt does not grant permission to spend funds, change data, publish, or access a system.[2]
• [ ] Record the human decision. Mark the job approved, pending, contradicted, or rejected, with an owner and next step.

A short review that ends in “pending evidence” is often better than a quick approval based on a persuasive transcript.

Privacy and redaction: make the packet safe to share

Portability is valuable only if the packet can be shared safely. Treat a public receipt URL as an artifact that may be forwarded beyond the original conversation. Before running a job, decide which details belong in the execution record and which belong in a private system of record.

Use these rules:

1. Redact before execution whenever possible. Do not send credentials, secrets, raw production exports, private keys, or unnecessary personal data into a job and hope to clean up the handoff afterward.[3]
2. Use minimal identifiers. A project ID, a repository commit SHA, or a scoped ticket reference is usually more shareable than a full client brief or transcript.
3. Split public and private evidence. Put a stable reference, hash, or sanitized excerpt in the receipt packet; keep the underlying confidential material in the client-approved repository with its own access controls.
4. Label redactions and gaps. Say “customer names redacted” or “private source retained in project vault,” rather than silently removing context that a reviewer needs to interpret the result.
5. Do not confuse integrity with access control. A hash can help detect changes to a recorded payload; it does not make the underlying data appropriate to publish or authorize someone to view it.[3]
6. Keep a correction and retention rule. If a report is superseded, state which version is current and preserve enough context for a reviewer to understand the change. Check availability of the receipt, evidence source, and verifier at the time of review.[2]

Teams working with regulated data, money, safety decisions, or irreversible publication should add their own organizational controls. A receipt complements access management, approvals, backups, monitoring, incident response, and domain review; it does not replace them.[3]

Failure cases to plan for

Receipt-centered handoffs are most useful when the run is not clean. Make uncertainty visible instead of polishing it away.

The operating principle is simple: the receipt should preserve the boundary between what was recorded, what was independently observed, and what remains a judgment call.

Make the next handoff easier than the last one

Start small. Add a receipt link, a decision question, and one explicit limitation to the next agent-assisted audit or review you deliver. Then standardize the packet fields that your team actually uses.

For teams using Zambo, begin with a safe, read-only job, inspect the resulting record, and practice the review loop before applying it to high-impact work. The durable habit is not “trust the agent because it has a receipt.” It is: give the next person enough evidence to review the work without reconstructing the whole conversation.

Connect your AI and run a reviewable job →

FAQs

1. What is an AI agent handoff receipt?

An AI agent handoff receipt is a portable record of one execution that the next reviewer can inspect. In Zambo’s model, the record includes the tool call context, observed result, timestamp, and integrity commitment, with a stable route for later verification.[1][2]

2. Does a verified receipt prove that the agent was correct?

No. Verification can show that the stored record matches its stated integrity commitment and passes the implementation’s checks. It does not prove that the agent’s reasoning was correct, that a recommendation will work, or that an outside-world result occurred unless corresponding external evidence was observed.[2]

3. Should a receipt replace logs, traces, or a project ticket?

No. Use traces, logs, and metrics for system operations; use tickets for ownership and workflow; use a receipt as the focused, portable artifact for a specific execution that someone else needs to inspect.[1]

4. Can I include a receipt in a client deliverable or invoice?

Yes, as a reference connecting the recorded job to the scope and delivery. Pair it with a plain-language summary, limitations, and any required client-acceptance record. Do not present it as proof of client acceptance, correctness, or a business outcome.

5. What should I do if the receipt shows a failure, partial result, or unavailable evidence?

Keep that state visible. A failed or partial receipt can help a reviewer understand what happened, but it is not proof that the requested work completed. State what is missing, assign the next check, and keep the outcome pending until the required evidence exists.[2]

Suggested internal links

References

[1] Zambo. “Receipts as execution evidence.”

[2] Zambo. “AI Agent Execution Receipt - Definition & Verification.”

[3] Zambo. “Security at Zambo.”

[4] Zambo. “Live tools through one MCP connection.”