If the agent wrote it, put a ticket id on the write
The CRM row changed at 1:12 a.m. The agent log says it meant to help. Support cannot find which conversation authorized the edit.
Every agent write into a system of record should carry a durable ticket or case id you can open later. Without that join, night-time edits become folklore—and rollback becomes guesswork.
The 1:12 a.m. edit
Something updated a shipping address, a discount code, or a deal stage while everyone slept. The agent framework shows a successful tool call. The business system shows a new value. Support has a frustrated customer and no bridge between the two screens. An agent write without a ticket id is an unsigned change.
You do not need a novel observability stack to fix the first version of this. You need a rule: no write tool may fire without a ticket (or case, order, or change-request) id that already exists, and that id must be stored on the audit row the system of record already keeps—or in a side table you actually query.
How the work moves
Write path with a ticket spine
- Resolve
Find or create a ticket/case before any write tool.
- Authorize
Check permission + preview rules for that tool.
- Write
Include ticket id in retained metadata.
- Confirm
Tool result and business state both reference the id.
- Recover
On-call opens one ticket for rollback or explain.
What to require
Before the tool call. The agent must resolve a ticket id from the conversation, the webhook, or a human-created stub. If none exists, create a minimal ticket first ("agent-proposed address change") and use that id. Do not invent silent writes "for speed."
On the write. Pass the ticket id as metadata the target system retains (note field, custom property, change reason, idempotency key prefix—whatever it supports). If the target cannot store it, write your own append-only log keyed by ticket id in the same transaction story as the tool success.
After failure. Partial success (CRM updated, email not sent) still leaves the ticket as the spine for recovery. The night on-call opens one id, not three dashboards.
What this is not. This is not "log everything the model thought." Prompt dumps are bulky and often sensitive. The ticket id is the join key for who asked, what changed, and who may roll it back. Pair it with the permission and preview rules you already use for risky tools; do not replace those with logging theater.
Shadow mode still gets ticket ids. If the agent only proposed, file the proposal on the ticket. Promotion later should show the same id lineage.
Decision guide
Silent success vs ticketed write
| Consideration | Tool success only | Ticket id on the write |
|---|---|---|
| Morning question | Which chat authorized this? | Open T-… and read the trail. |
| Rollback | Guess from logs and screenshots. | Act from the same id the agent used. |
| Compliance | Unsigned night edits. | Change reason tied to a case. |
| Speed myth | Skipping the ticket saves seconds. | Creating a stub still beats forensic week. |
An agent write without a ticket id is an unsigned change.
Make the ticket visible in human tools
Support and ops will not query your agent vendor's trace UI at 1:12 a.m. Put the ticket id where they already work: CRM timeline, order admin, or the case system. If the only copy of the id lives in an LLM gateway log, you built a museum, not a control.
When agents batch writes (hundreds of requalifications), either attach one parent ticket with child rows or require a batch change-request id. "The nightly agent did it" is not an audit trail.
Deny the silent path in code
Policy docs that say "always open a ticket" fail when a tool schema makes the field optional. Make the ticket id required in the tool definition. Reject the call in your gateway if it is missing. Soft guidelines do not survive a model that is optimizing for task completion.
Pair this with preview-and-approve for high-impact fields (price, entitlement, address, bank details). The ticket id explains the write; preview still prevents the bad write.
Review the overnight board
Each morning, skim agent writes grouped by ticket id—not by model name. Humans spot bad patterns faster when the unit of review is the case. If a single ticket spawned fifty address changes, that is either a brilliant batch or a bug; either way it deserves eyes.
For customer-facing explanations ("why did my discount change"), support should be able to paste the ticket id into a view that shows the agent action in plain language. Hiding behind "our AI updated your account" without a handle erodes trust faster than the bad discount did.
Keep PII out of ticket titles when agents auto-create stubs. "Address change proposed" plus a link is enough; do not put the full street line in the subject where it leaks into email notifications.
Idempotency keys should incorporate the ticket id so retries do not create duplicate side effects under a new random key. When the agent retries a failed tool call, the business system should see the same intent.
For read-only agents, tickets are optional. The moment a tool can mutate money, inventory, PII, or entitlements, the ticket rule is mandatory. Draw that line in the tool registry, not in a wiki nobody reads during an incident.
Connect ticket ids to your existing change-management language so auditors recognize them. If you already use CAB numbers for human releases, agent writes that change entitlements may need the same class of id—or an explicit waiver class. Do not invent a shadow process only agents use.
When vendors market "autonomous CRM updates," ask where the ticket id lands before you enable write skills. If the answer is only their trace UI, budget engineering time to bridge into your case system—or keep the agent recommend-only.
Ship a tiny admin view before you ship more agent skills: last 50 agent writes with ticket id, tool name, target record, and timestamp. If that view is empty or ticketless, stop enabling writes. Visibility is the control's proof, not a slide about governance.
Refuse to demo write skills to executives without showing the ticket join on screen. If the demo cannot open a human-readable case for the change it just made, the demo failed—even if the CRM row looks right.
If a write tool cannot accept a ticket id parameter today, wrap it. Do not wait for the vendor's roadmap to grow an audit spine you need tonight.
Put this into practice
List the write tools your agents may call this week. For each, name the field where the ticket id lands and the UI where a human opens it. If you cannot point to that UI in one click, the control does not exist yet—build the join before the next overnight edit.
We build AI applications and agents that leave an auditable spine on every write. If your night changes cannot be opened as a ticket—talk to us.
Related work: Spin:Market.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.