The Custody Chain Pattern for Agentic AI Systems

Agentic AI systems fail in a specific, predictable way. Not because the models are wrong. Because nobody agreed on who owns the state between steps. One agent transforms a record, passes it forward, and the next agent operates on an assumption that was never verified. By the time something breaks, the trace is gone. That is the problem the Custody Chain pattern solves.

I started thinking about this pattern while building systems where a wrong answer had real consequences, a tax return filed with a bad figure, a visa eligibility assessment that sent someone down the wrong route. In both cases, the constraint was not model accuracy. It was auditability. A regulator does not want to know that the model was probably right. They want a signed record of every state transition, who or what produced it, and what it was based on.

What the Custody Chain mental model actually is

The Custody Chain is a design principle, not a library. The idea is borrowed from forensic evidence handling. Every piece of evidence in a criminal case has a documented chain of custody: who collected it, when, how it was stored, who transferred it, and who received it. If that chain breaks, the evidence is inadmissible.

Applied to agentic AI, the rule is the same. Every state object that passes between agents must carry a sealed record of where it came from, what transformation was applied, and what the inputs were at the moment of transformation. No agent consumes a payload it cannot verify. No agent produces an output without signing it. The chain is never broken.

This is different from logging. Logging is append-only and external. The Custody Chain is embedded in the payload itself. The state object is its own audit trail.

Why most agentic architectures skip this

The fast path is easier. You define a task graph, wire the agents together, and pass plain data objects between them. It works in development. It works in demos. It breaks in production when an upstream agent returns a partial result under load, or when a retry produces a different output than the original run, and the downstream agent has no way to know.

Most frameworks treat state as a shared resource. One agent writes to it, another reads from it, and the coordination is handled by the orchestrator. That model is fine for simple pipelines. For anything with branching logic, human-in-the-loop steps, or regulatory requirements, it creates a class of bugs that are almost impossible to reproduce, because the bug is in the sequence, not in any single agent.

The JAKARTA Agentic AI approach, which I have been applying in 2026 builds, addresses this directly. Jakarta EE 11 gives you the transaction and context propagation primitives you need to make custody handoffs explicit at the framework level. You are not bolting auditability on after the fact. You are building it into the agent contract from the start. The same mental model applies if you are working in a different stack. The primitives differ, but the principle holds.

How to implement it in practice

The implementation has three rules.

• —Immutable payloads. Each agent receives a payload and produces a new payload. It never mutates the input. The original record is preserved at every step.
• —Signed handoffs. Before passing a payload to the next agent, the current agent attaches a custody record: agent identifier, timestamp, input hash, output hash, and a brief statement of the transformation applied. This is not a log entry. It is part of the payload.
• —Verification at entry. Each agent, before doing any work, verifies the custody record of the incoming payload. If the hash does not match, the agent rejects the payload and raises a custody fault, not a generic error.

The custody fault is important. It is a named, specific failure mode. When a custody fault fires, you know exactly where the chain broke and what the last verified state was. That is the difference between a system that fails loudly and one that fails silently and wrong.

In a Jakarta EE context, you implement this using CDI interceptors on your agent beans. The interceptor handles verification on entry and signing on exit. The agent code itself never touches the custody record. It only sees the verified payload. This separation keeps the business logic clean and makes the custody behaviour testable in isolation.

Where this gets hard

The hard part is human-in-the-loop steps. When a human reviews and approves a state transition, they are acting as an agent in the chain. The custody record needs to capture that. Who approved it, at what time, based on which version of the payload.

I ran into this directly on the OptimalTax build, where tax calculation results had to pass through a human review step before filing. The temptation was to treat the human approval as a side-channel event and just record a boolean flag. That does not hold up under audit. The custody record for the human step needs the same structure as any other step: input state, reviewer identity, timestamp, and output state. When the system achieved 99% tax calculation accuracy, part of what made that number meaningful was that every step in the chain, including the human ones, was fully traceable.

The same principle applied on the Financial Services Platform, where payment state transitions had to be auditable across multiple services. State handoffs between services are custody handoffs. Treating them that way from the start was what allowed the team to diagnose and eliminate latency without losing the audit trail.

The boundary between agents is the contract

A lot of agentic AI design focuses on what each agent does. The Custody Chain pattern forces you to focus on what happens between agents. That boundary is the contract. It is where correctness is either guaranteed or lost.

If you are building an agentic system and you cannot answer these questions for every handoff, the system is not production-ready: what is the schema of the payload, what does a valid custody record look like, what happens when verification fails, and who is notified. These are engineering questions, not AI questions. The model is the least interesting part of the problem.

Agentic AI built without this discipline tends to work well until it does not, and when it fails, it fails in ways that are expensive to diagnose and difficult to explain to a client or a regulator. The Custody Chain pattern does not make the system smarter. It makes the system honest about what it knows and when it knew it.

If you are a founder or product owner working through how to structure an agentic build, the Fursa visa eligibility system is a concrete example of this kind of reasoning applied to a real product with real stakes. And if you want to work through the architecture of your own system, start a conversation with Kadon or reach out directly.