How do you trace a task across several AI agents?

Give the task one identifier when it is created and carry it through every handoff, tool call and human approval. File each verdict against that identifier with the acting agent, its certificate, the sources it used and the bound that decided. Reconstructing the task then becomes a query over one record, rather than a hunt through several systems' logs.

Why is tracing harder with several agents?

Each agent, tool and system keeps its own logs, with its own identifiers and clocks. A complaint that leads to a refund may touch a complaints agent, a refund agent, the payments system, the ledger and a person who approved one step. Without a shared thread, connecting those entries means matching timestamps and guessing.

Tracing also needs more than events. Logs show that a refund was issued. A regulator, auditor or complaints handler wants to know why it was allowed, on what facts, under which authority and who approved it.

What are the steps?

1. Create the task id at intake. Whatever starts the work, an email, a queue item, a schedule, gets an id before any agent touches it.
2. Propagate it on every handoff. When one agent passes work to another, the child task records its parent. The chain becomes a tree you can walk.
3. File every verdict against it. Allowed, held, refused or withheld, each with the agent identity, certificate version, the sources with their provenance, the bounds evaluated and which one decided.
4. Record people in the same thread. Approvals of held actions, and edits made before approving, go into the same record, not a separate approval tool.
5. Tag external calls. When an agent calls a system, pass the task id where the system allows, so the system's own log can be joined.
6. Use one clock. Record times from a single source so the order of events is unambiguous.
7. Build the reconstruction view. A view that lays out the task tree, the verdicts and the facts each relied on, in order.

What does a trace need to contain?

What does this look like in practice?

Take a bank investigating why a customer received two fee refunds. The complaints team pulls the task by its id. The trace shows a complaints agent triaged the complaint and delegated a refund to the refund agent. The refund agent issued one refund within its limit, with the verdict naming its certificate and the account data it read. Separately, the customer called; a person opened a second case, which was not linked to the first, and approved a refund drafted by the same agent.

The cause is clear in minutes: two task ids for one complaint. The fix is at intake, linking cases by customer and subject before delegation. Without the trace, the team would have compared ledger entries and call notes by hand. The same approach supports work such as tracing missing incoming payments, where the agent's own investigation needs its own trail.

Which controls keep traces trustworthy?

• The record is append-only, so a trace cannot be edited after the fact.
• No agent action reaches a system without a filed verdict.
• Task ids are created by the platform, not the agent, so they cannot be invented or reused.
• Traces from different countries follow local rules on where records sit, a design question covered in running AI agents across several countries.
• For finance work, every figure in an agent's output links to an entry, as argued in a finance agent's figures must trace to an entry.

Orchestrators make tracing more important, not less; see how to run several AI agents under one orchestrator.

What stays with a person?

Deciding what the trace means. The record shows what happened and which bound decided each step. Whether the outcome was right, whether a customer should be compensated, and whether an agent's depth should change are judgements for named people. The governing layer that keeps the record is described in the governed agentic operating system guide.