Section navigation

Trace Custody

Agent traces are quickly becoming the raw material for debugging, evaluation, and optimization across the AI agent ecosystem. Vendor traces, OpenTelemetry spans, framework runtime logs, and observability dashboards capture what an agent read, requested, returned, retried, and recovered from. The category is converging fast on a useful claim: traces are valuable because they create evaluations.

ARCS starts one architectural layer earlier.

A trace is an interaction record before it is an evaluation artifact.

Trace material may contain prompts, system instructions, retrieved documents, tool arguments and results, intermediate reasoning summaries, agent-session continuity, delegation evidence, error recovery behavior, model output, timing, span identifiers, and observability metadata. Some of that material is operational telemetry. Some is deliberative content. Some is security-sensitive. Some may be private, privileged, regulated, or discovery-relevant.

That mixture is the problem.

ARCS defines how trace material is classified, separated, retained, disclosed, and governed before it becomes evaluation fuel, training data, public material, or admitted record. Trace-to-evaluation pipelines are downstream of trace custody. Skipping the custody layer is how systems accumulate parallel record surfaces that no governance regime authorized.

The custody question

The market is asking: how do we use traces to improve agents?

ARCS asks the prior question: who owns the trace, what does it contain, when does it become a record, what must be redacted, what can be replayed, what can be used for evaluation, and what happens when it crosses a publication or production boundary?

A vendor trace shows that something happened. A custody decision determines what is allowed to count as the institutional record of what happened.

What ARCS contributes

Trace custody sits across five ARCS control families.

ARCS-AGT (Agent Runtime). Distinguishes planning traces from execution traces. Planning traces are deliberative and ephemeral by default. Execution traces require content-telemetry separation. Tool call artifacts, intermediate results, error recovery artifacts, session state artifacts, and security-sensitive tool outputs each have distinct treatment.

ARCS-TAX (Taxonomy). Classifies trace artifacts as interaction record classes, not as general observability data. The same byte sequence reaches a different governance posture depending on whether it is taxonomized as a transcript, an intermediate result, a tool result, or an operational log.

ARCS-CUS (Custody). Names the custodian of trace material and the custody surface on which it lives. Vendor observability stacks, framework dashboards, and APM systems are custody surfaces in the ARCS sense, even when they are marketed only as debugging infrastructure.

ARCS-LIF (Lifecycle). Defines retention, expiration, and legal-hold posture by trace artifact class. Retention by system name is insufficient because a single system may produce multiple artifact classes with different lifecycle requirements.

ARCS-VER (Verification). Provides integrity attestation for trace material that is retained as record. Hash chains and receipt structures distinguish a trace from a claim about what the trace contained.

What trace material is not

Trace custody requires care about what trace material does and does not establish. A trace can support reconstruction, evaluation, replay, audit, and dispute review, but only after custody classification and substrate admission boundaries are applied.

A trace, by itself, does not prove:

  • Correctness. That an agent did the right thing.
  • Source support. That a generated claim was warranted by retrieved material.
  • Record admission. That trace contents have been admitted as institutional records.
  • Authorization. That the operator, agent, or action was permitted under firm policy.
  • Completeness. That every relevant action or artifact has been captured.

Trace-to-evaluation pipelines that conflate these properties — treating a trace as proof of correctness, support, admission, authorization, or completeness — produce false confidence and accumulate audit liability.

The custody pipeline

A complete trace custody pipeline distinguishes the following layers, in order:

  1. The raw trace exists as a vendor, framework, runtime, or observability artifact.
  2. ARCS classifies the artifact class and lifecycle boundary.
  3. Content and telemetry are separated at the custody boundary.
  4. Raw payloads are excluded, redacted, retained, or preserved per policy.
  5. Trace context may be represented by opaque references rather than full payload retention.
  6. Selected trace context may be proposed as substrate input.
  7. Admission decisions determine whether any candidate becomes a governed record.
  8. Bounded admitted material defines what an operation may use.
  9. Operation behavior over admitted material is recorded as governed operation artifacts.
  10. Inspection projections render reviewable posture.
  11. Evaluation traces and fixtures may be derived from governed material.
  12. Receipts attest to handling, rendering, export, custody, or sovereignty conditions.
  13. Public projections disclose only admitted, safe, and intentionally published material.

Each layer answers a different question. Conflating them is the most common source of trace governance failure.

Why this matters for the agent ecosystem

Agent traces are becoming structurally important the same way email and instant messages did a decade ago. Both started as informal communication channels and ended as production discovery surfaces under retention, supervisory, and disclosure regimes.

The agent ecosystem is moving along the same trajectory faster. Traces contain regulated material because agents read regulated material. They contain privileged material because agents work alongside privileged communications. They contain discovery-relevant material because agents act on behalf of the firm. Treating these surfaces as observability exhaust is a transient framing; treating them as records is the durable one.

The work of trace custody is not preventing trace use — traces are genuinely valuable for evaluation, debugging, replay, and improvement. The work is making the reuse defensible by applying custody classification before the reuse begins.

Related ARCS material

Control families:

  • ARCS-AGT (§14 Agent Runtime) — planning and execution trace requirements
  • ARCS-TAX (§7 Taxonomy) — interaction record classes including trace artifacts
  • ARCS-CUS (§5 Custody) — custodian and custody surface definitions
  • ARCS-LIF (§3 Lifecycle) — retention, expiration, legal-hold
  • ARCS-VER (§13 Verification) — integrity attestation and hash-chain receipts

Related context documents:

For the substrate implementation pattern, see ARCS-conformant systems that provide refs-only trace bridges, bounded admission contexts, governed operation logs, inspection projections, and receipt-bearing custody trails.

This document is informative. It is not part of the normative ARCS standard.