The moment this is for
The review starts after the agent already acted. A lead got a follow-up. A support ticket moved queues. A CRM note changed the next sales step. A website preview became a published page. Nobody is confused about whether the system did something. The problem is that nobody can cleanly explain the run.
The source record is in one tab. The generated draft is in another. The reviewer remembers approving something, but not whether they approved the first version or the edited one. The tool call says success. The final state still looks wrong.
That is the moment a receipt earns its keep. A receipt is not a transcript dump. It is the smallest record that lets a teammate answer what the agent saw, what it proposed, which rule applied, who reviewed it, what changed, and how to recover if the result was wrong.
If you want the longer rationale, read why agent receipts should exist before AI touches customer work. If the action boundary is not defined yet, start with the AI approval queue guide.
What a receipt decides
An approval policy tells the workflow what may happen. A receipt proves what did happen. For implementation teams, that distinction matters because the receipt becomes the inspection point between prototype and production.
It tells the operator whether the agent used the right source, stayed inside the data boundary, showed enough evidence to the reviewer, executed the intended action, and left a recovery path. The first version should be boring on purpose. Start with one workflow and one run. Add fields only when a real failure mode asks for them.
Copy-paste template
AI agent receipt template
Copy this for one workflow. Fill it out every time the agent proposes or performs work that reaches a customer, system of record, public page, sensitive data set, or reviewer-controlled queue.
Receipt ID
Use a stable ID that can be pasted into a ticket, CRM note, deployment record, support thread, or review queue.
Workflow / lane
Name the repeatable workflow. Example: “Lead form to reviewed follow-up” or “Support ticket to priority queue.”
Trigger / input reference
Record the form ID, ticket ID, CRM record, page request, uploaded file, message, transcript, or event that started the run.
Source data used
List the exact records, fields, documents, snippets, retrieval results, pages, or approved knowledge sources the agent relied on.
Data boundary check
Note whether the run stayed inside the allowed source data. If it touched blocked or unexpected data, stop or escalate.
Proposed action
State what the agent wanted to draft, classify, route, update, send, publish, extract, sync, or change.
Policy rule / approval boundary
Name the rule that applied: draft-only, review required, auto-execute allowed, escalate, missing source, customer-visible action, public claim, sensitive data, or manual-only.
Confidence / routing signal
Capture the score, reason code, uncertainty flag, missing-field signal, queue lane, or reviewer-routing reason if the workflow uses one.
Reviewer / approval decision
Log who approved, edited, rejected, escalated, or overrode the proposed action, plus the approval timestamp.
Model / tool / version
Record the model, prompt or workflow version, tool, integration, API route, retrieval index, or automation version when it would help debug or reproduce the run.
Final output / action
Record the approved message, CRM note, routing decision, published URL, diff, extracted field set, synced update, or held/rejected result.
Destination system
Name where the final action landed: inbox, CRM, support platform, CMS, ticket queue, database, file store, or internal review queue.
Rollback link / undo owner
Link the revert commit, prior version, correction note, reopened ticket, restore record, recovery runbook, or named owner who can undo or amend the result.
Final state verification
Confirm the system ended in the intended state: sent, held, edited, rejected, escalated, synced, published, reverted, corrected, or still pending.
Follow-up needed
Note any missing source, reviewer disagreement, policy gap, customer correction, prompt/tool change, or workflow rule that needs a later fix.
| Field | What to log |
|---|---|
| Receipt ID | Use a stable ID that can be pasted into a ticket, CRM note, deployment record, support thread, or review queue. |
| Workflow / lane | Name the repeatable workflow. Example: “Lead form to reviewed follow-up” or “Support ticket to priority queue.” |
| Trigger / input reference | Record the form ID, ticket ID, CRM record, page request, uploaded file, message, transcript, or event that started the run. |
| Source data used | List the exact records, fields, documents, snippets, retrieval results, pages, or approved knowledge sources the agent relied on. |
| Data boundary check | Note whether the run stayed inside the allowed source data. If it touched blocked or unexpected data, stop or escalate. |
| Proposed action | State what the agent wanted to draft, classify, route, update, send, publish, extract, sync, or change. |
| Policy rule / approval boundary | Name the rule that applied: draft-only, review required, auto-execute allowed, escalate, missing source, customer-visible action, public claim, sensitive data, or manual-only. |
| Confidence / routing signal | Capture the score, reason code, uncertainty flag, missing-field signal, queue lane, or reviewer-routing reason if the workflow uses one. |
| Reviewer / approval decision | Log who approved, edited, rejected, escalated, or overrode the proposed action, plus the approval timestamp. |
| Model / tool / version | Record the model, prompt or workflow version, tool, integration, API route, retrieval index, or automation version when it would help debug or reproduce the run. |
| Final output / action | Record the approved message, CRM note, routing decision, published URL, diff, extracted field set, synced update, or held/rejected result. |
| Destination system | Name where the final action landed: inbox, CRM, support platform, CMS, ticket queue, database, file store, or internal review queue. |
| Rollback link / undo owner | Link the revert commit, prior version, correction note, reopened ticket, restore record, recovery runbook, or named owner who can undo or amend the result. |
| Final state verification | Confirm the system ended in the intended state: sent, held, edited, rejected, escalated, synced, published, reverted, corrected, or still pending. |
| Follow-up needed | Note any missing source, reviewer disagreement, policy gap, customer correction, prompt/tool change, or workflow rule that needs a later fix. |
Short version for the next run
If the full table feels heavy, require these eight answers before the agent changes customer work:
- What started the run?
- What source data did the agent use?
- What action did it propose?
- Which policy rule or approval boundary applied?
- Who reviewed or approved it?
- What final action happened?
- How can the team roll it back or correct it?
- What final state proves the workflow stopped in the right place?
Example: customer follow-up draft
Use this example to keep the receipt operational instead of theoretical.
Receipt ID
lead-followup-2026-06-02-0187
Workflow / lane
Draft follow-up for new website leads.
Trigger / input reference
Website form submission WF-187, created June 2 at 9:14 a.m.
Source data used
Form message, company URL, approved AI Development service copy, last CRM note for this lead account.
Data boundary check
Stayed inside allowed sources. No billing history, unrelated CRM records, or private margin notes were retrieved.
Proposed action
Draft a follow-up email and prepare an internal CRM note.
Policy rule / approval boundary
External send requires human review. Pricing, delivery-date promises, credentials, legal terms, and security commitments must escalate.
Reviewer / approval decision
Operations owner edited the second paragraph and approved the email at 10:03 a.m.
Final output / action
Edited email sent to the lead. CRM note added with source form link and missing-field request.
Rollback link / undo owner
Operations owner can send correction, amend CRM note, and attach the correction to this receipt.
Final state verification
Email sent, CRM note written, lead status still “Needs discovery” rather than “Qualified.”
| Field | Example |
|---|---|
| Receipt ID | lead-followup-2026-06-02-0187 |
| Workflow / lane | Draft follow-up for new website leads. |
| Trigger / input reference | Website form submission WF-187, created June 2 at 9:14 a.m. |
| Source data used | Form message, company URL, approved AI Development service copy, last CRM note for this lead account. |
| Data boundary check | Stayed inside allowed sources. No billing history, unrelated CRM records, or private margin notes were retrieved. |
| Proposed action | Draft a follow-up email and prepare an internal CRM note. |
| Policy rule / approval boundary | External send requires human review. Pricing, delivery-date promises, credentials, legal terms, and security commitments must escalate. |
| Reviewer / approval decision | Operations owner edited the second paragraph and approved the email at 10:03 a.m. |
| Final output / action | Edited email sent to the lead. CRM note added with source form link and missing-field request. |
| Rollback link / undo owner | Operations owner can send correction, amend CRM note, and attach the correction to this receipt. |
| Final state verification | Email sent, CRM note written, lead status still “Needs discovery” rather than “Qualified.” |
Example: website/content update
Public content needs a receipt when a generated diff can change a claim, CTA, published URL, or customer-facing promise.
Receipt ID
site-update-2026-06-02-agent-receipts-cta
Workflow / lane
Draft and review a CTA update for a published blog post.
Trigger / input reference
Content-growth task requesting a more specific template path from the agent receipts article.
Source data used
Published blog markdown, approval queue page, data security page, AI Development service page, and the approval-policy worksheet.
Proposed action
Add an in-article copyable receipt block and route the CTA to /responsible-ai/agent-receipt-template.
Policy rule / approval boundary
Public content change requires preview and human approval before merge.
Reviewer / approval decision
Pending Rachel QA and editorial approval.
Final output / action
Draft page copy, template block, internal link map, and QA ask.
Destination system
Next.js route, blog markdown, responsible AI cluster links, and sitemap through normal app routing.
Final state verification
New page renders, blog links to it, copyable block works on mobile, and CTA intent URL resolves.
| Field | Example |
|---|---|
| Receipt ID | site-update-2026-06-02-agent-receipts-cta |
| Workflow / lane | Draft and review a CTA update for a published blog post. |
| Trigger / input reference | Content-growth task requesting a more specific template path from the agent receipts article. |
| Source data used | Published blog markdown, approval queue page, data security page, AI Development service page, and the approval-policy worksheet. |
| Proposed action | Add an in-article copyable receipt block and route the CTA to /responsible-ai/agent-receipt-template. |
| Policy rule / approval boundary | Public content change requires preview and human approval before merge. |
| Reviewer / approval decision | Pending Rachel QA and editorial approval. |
| Final output / action | Draft page copy, template block, internal link map, and QA ask. |
| Destination system | Next.js route, blog markdown, responsible AI cluster links, and sitemap through normal app routing. |
| Final state verification | New page renders, blog links to it, copyable block works on mobile, and CTA intent URL resolves. |
When the full receipt is too much
Not every AI-assisted draft needs a full receipt. If the agent is summarizing internal notes, brainstorming headings, or preparing a draft that a person rewrites before it leaves the room, a lighter record may be enough. Keep the source link, draft, reviewer, and final owner.
Use the fuller receipt when the output can affect a customer, a system of record, public content, money, access, regulated data, account status, or a workflow another team will trust later. The dividing line is consequence, not model capability.
FAQ
What is an AI agent receipt?
An AI agent receipt is a short record of one workflow run. It captures the input, source data, proposed action, policy rule, reviewer decision, final output, destination system, rollback path, and final state so the team can reconstruct what happened later.
Is this the same as an audit log?
No. An audit log usually records events. A receipt explains the run well enough for an operator, reviewer, or teammate to understand why the action happened and how to correct it if needed.
Does every AI run need this receipt?
No. Use the full receipt for customer-facing, public, financial, access-related, regulated, system-of-record, or hard-to-undo actions. For low-risk internal drafts, keep a lighter record that names the source, draft, reviewer, and owner.
Should the receipt be generated automatically?
Eventually, yes. The first useful version can be a table, ticket template, or review-queue record. Once the fields are stable, the workflow should fill most of them automatically and ask the reviewer only for the decision, edits, and exceptions.
How does this connect to an approval queue?
The approval queue holds proposed actions before they execute. The receipt records what the queue showed, who decided, what changed, and what final state resulted. The queue prevents silent action; the receipt makes the action reconstructable.
Is this a compliance template?
No. This is an implementation planning tool, not legal advice or a compliance guarantee. Regulated workflows should involve the client's legal, privacy, compliance, or security stakeholders before production use.
Make one agent lane reconstructable
If you have one AI workflow close to production, fill out the receipt template for a real historical run. Bring the rough version to BaristaLabs and we can pressure-test the missing pieces: source data, approval boundary, reviewer evidence, final-state verification, and rollback.
Best fit for agents that draft customer follow-up, route support work, update CRM notes, prepare website changes, extract document fields, or sync work into systems other people trust.