A demo can finish a task and still leave the work untrustworthy.
Picture an agent that opens a pull request, updates a CRM record, or prepares a publish-ready draft. The task may be technically complete. The question is whether anyone can reconstruct who approved the action, what state the agent inherited, what changed, and how to recover if the output is wrong.
That sounds harsh until you ask the next question: after the agent says it is done, can the system prove what actually happened?
Not in a vague observability sense. Not as a pile of logs nobody can interpret. Not as a confident summary written by the same agent that performed the work.
I mean custody of the work.
Who authorized the action? What state did the agent rely on? What changed? What evidence proves completion? If something went wrong, where can the system stop, roll back, retry, or escalate without making the mess worse?
This is the part of agent work that gets under-discussed because it is less exciting than capability. It does not look like a benchmark jump. It does not demo well. It is the difference between a workflow that can perform a sequence and a workflow that can be trusted after the sequence crosses multiple tools, agents, files, and human review points.
Modern agent stacks are starting to expose pieces of this layer. OpenAI's Agents SDK tracing docs describe traces that record LLM generations, tool calls, handoffs, guardrails, and custom events during an agent run. A2A's public specification describes task state, artifacts, optional history, and enterprise concerns like authentication, authorization, tracing, and monitoring. OWASP's agentic AI guidance goes even closer to the operating risk: memory, tool misuse, authorization boundaries, logging, tracing, rollback, and accountability all show up as practical failure surfaces.
Those are useful ingredients. They are not the acceptance test.
The acceptance test is simpler and harder:
Can the system preserve chain-of-custody for the work?
Custody is not logging
Logging tells you something was recorded.
Custody tells you whether the record is enough to trust, review, and recover the work.
That distinction matters because agent work is not a single function call. It is usually a chain: a user request becomes a plan, the plan becomes tool calls, tool calls mutate state, another agent or process inherits the result, and a human or downstream system receives a conclusion. Every handoff is an opportunity for authority to blur, state to drift, evidence to thin out, or recovery to become guesswork.
NIST's AI Risk Management Framework frames trustworthy AI around qualities like validity, reliability, safety, resilience, accountability, transparency, explainability, and privacy. That is the right altitude for risk management. But operators still need a lower-level question they can ask before giving an agent workflow more consequential work.
Here is the one I would use:
Before trusting an agent team, ask whether it can answer four custody questions:
- Who authorized this action?
- What state crossed the handoff?
- What evidence proves completion?
- What recovery path exists if a link fails?
If those questions are fuzzy, the system may still be impressive. It is just not ready to be trusted with work where provenance matters.
1. Authority: who allowed this?
The first custody question is not "Can the agent call the tool?"
It is "Was this agent authorized to take this action for this user, in this context, at this point in the workflow?"
Those are different questions.
Tool access is easy to grant too broadly. A capable agent with a powerful connector can start to behave like ambient authority: if it can see the tool and construct the request, it acts. That is not a custody model. That is power with a chat interface.
OWASP's agentic AI guidance calls out this class of risk directly. Tool use affects identity and authorization. Agents can become confused deputies when they have higher privileges than the user or are tricked into taking actions the user should not be able to perform. The recommended direction is least privilege, scoped entitlements, and explicit validation that the user is allowed to perform the requested action.
For agent work, authority needs to travel with the job.
A useful system should be able to show:
- the original user or process that requested the work
- the scope of what was approved
- which agent or component acted under that approval
- which actions required additional review
- which actions were denied, paused, or escalated
Without that, you cannot distinguish delegated work from accidental permission leakage.
This is where a lot of agent designs get too casual. They treat authorization as something that happens before the run starts. In real workflows, authority has to survive delegation. The first agent may be allowed to draft. The second may be allowed to inspect. A third may be allowed to recommend a change but not execute it. A human may need to approve the final mutation.
If the workflow cannot prove those boundaries after the fact, it did not keep custody. It just completed a path.
2. State lineage: what did the agent inherit?
The second custody question is about state.
Not "Does the agent have memory?" Not "Is the context window large enough?" Those are implementation details.
The real question is: what facts, assumptions, files, tool results, instructions, and constraints crossed the handoff?
Agent failures often look like reasoning failures when they are actually state failures. The agent acted on stale context. It inherited an assumption that was never checked. It summarized a prior step too aggressively. It dropped a constraint during a handoff. It mixed a retrieved fact with a generated guess. It treated a partial result as complete.
OWASP's agentic AI work describes memory and statefulness as information from previous runs or previous steps in the current run, including reasoning, tool calls, and retrieved information. That is exactly why state lineage matters. The state is not just text in a prompt. It is the operating surface of the workflow.
A2A's framing is useful here too because it explicitly treats agents as entities that can collaborate without needing access to each other's internal state, memory, or tools. That separation is good. But it also raises the custody bar: if the next agent does not get raw internal state, the handoff artifact has to be good enough to preserve what matters.
A custody-aware handoff should make lineage visible:
- which source facts were used
- which assumptions were accepted
- which files, records, or tool outputs were touched
- which constraints remained active
- which parts of the prior state were intentionally excluded
- which uncertainties were carried forward
This does not mean dumping every token into a transcript. More data is not the same as better custody. The goal is a handoff artifact that lets the next actor understand what it is inheriting and lets a reviewer reconstruct why a decision was made.
If an agent team cannot answer "What did the next agent believe when it acted?" then the work has weak custody.
3. Completion evidence: what proves it finished?
The third custody question is where a lot of workflows fake reliability.
The agent says it finished. The orchestration layer marks the step complete. The dashboard turns green. A summary appears.
None of that is proof by itself.
Completion evidence should be independently checkable. A human or downstream system should be able to verify the result without trusting the same agent that produced the claim.
That evidence can take different forms depending on the work:
- a file diff plus tests for code changes
- a created record plus a readback query for database work
- a published URL plus a fetch of the live page for content work
- a trace showing the relevant tool calls, handoffs, and guardrails
- an artifact with enough metadata to prove what changed and why
This is where tracing, task artifacts, and history become useful. OpenAI's tracing documentation shows the shape of one evidence layer: events for model calls, tool calls, handoffs, guardrails, and custom events. A2A's task model includes status, artifacts, and optional history. OWASP recommends execution logs that track AI tool calls for anomaly detection and post-incident review.
But the point is not "add tracing and you're done."
Tracing is an input to custody. Logs are inputs. Artifacts are inputs. The acceptance test is whether those inputs prove the right thing.
A trace that shows a tool call happened is useful. A custody record that shows the tool call was authorized, used the right state, produced the expected change, and was verified by an independent check is better.
The difference is subtle until something breaks. Then it is everything.
When a workflow fails, "the agent said it worked" is useless. "Here is the authorization, inherited state, mutation, verification artifact, and failing recovery point" is operational.
4. Recovery: what happens when a link fails?
The fourth custody question is recovery.
Every serious agent workflow needs to assume that some link in the chain will fail. The agent may act on stale state. A tool may return partial data. A handoff may compress away the wrong detail. A memory entry may be poisoned. A reviewer may reject the output. A downstream system may receive a malformed artifact.
The question is not whether the system can prevent every failure.
It cannot.
The question is whether it preserves enough custody to recover without guessing.
OWASP's agentic AI guidance recommends practices like memory snapshots for forensic analysis and rollback when anomalies are detected, along with logging and tracing for post-incident review. NIST also emphasizes that AI systems can be complex, that failures may be difficult to detect and respond to, and that resilience is part of trustworthy AI.
For operators, that translates into a practical standard:
- Can the workflow stop safely?
- Can it identify the last known-good state?
- Can it replay or retry from the right point?
- Can it escalate with enough context for a human to decide?
- Can it avoid repeating the same bad action with the same bad state?
Recovery is not an afterthought. It is part of custody.
A workflow that cannot recover from a bad handoff did not preserve the work. It preserved the happy path.
What this is not
Chain-of-custody is not a new name for logging.
It is not evals. Evals can tell you how a system performs against a test set. They do not automatically prove what happened in a live multi-step job.
It is not memory. Memory can help preserve context, but it can also preserve stale assumptions, poisoned state, or irrelevant residue.
It is not orchestration. A graph can route work across agents and tools while still losing authority, state, evidence, or recovery detail.
It is not protocols. Protocols can make agents easier to connect and can expose task state, artifacts, history, authentication, and monitoring hooks. That is valuable infrastructure. It still needs an operating standard above it.
Custody is the standard for whether the work can be trusted after it moves.
That framing is intentionally narrower than a grand theory of agent reliability. It does not solve reasoning quality, product judgment, data quality, UI trust, or business process design. It gives operators a concrete gate before they let agents handle work that matters.
The four-question acceptance test
Before you trust an agent team with consequential work, ask four questions.
Who authorized this?
Not just which API key was available. Which user, policy, approval, or review gate allowed this action in this context?
What state crossed the handoff?
Not just what prompt was sent. Which facts, assumptions, files, retrieved results, constraints, and uncertainties did the next actor inherit?
What evidence proves completion?
Not just what the agent claimed. Which artifact, readback, trace, diff, test, URL, or record lets someone verify the result independently?
What recovery path exists?
Not just whether the happy path works. Where can the system stop, roll back, retry, or escalate if a link fails?
That is custody of the work.
The agent can be capable and still fail this test. The workflow can be sophisticated and still fail this test. The platform can have traces, memory, tool calls, and handoffs and still fail this test if those pieces do not answer the custody questions.
The next useful frontier for agent work is not only making agents do more.
It is making the work they do provable enough to trust.