An AI trading agent paused. Can you tell why?

Imagine an agent preparing an ETH to USDC swap. It cannot complete its price check, so it pauses.

Six months later, an auditor finds an empty price field. What happened?

Perhaps the agent retrieved quotes, but too few met its freshness or independence requirements. Perhaps a provider timed out and the quotes were never retrieved. Those are different events, yet a nullable field makes them look the same.

I would model the outcomes explicitly:

type PriceCheckResult =
  | {
      kind: "passed";
      policyId: string;
      evidenceDigest: string;
    }
  | {
      kind: "insufficient_evidence";
      policyId: string;
      reasonCodes: string[];
    }
  | {
      kind: "retrieval_failed";
      policyId: string;
      source: string;
      errorCode: string;
    };

The policyId matters because “insufficient” is a judgment against a particular set of requirements. The same observations might pass one policy and fail another. A reviewer needs the policy that applied at decision time, not just the agent’s final verdict.

I would keep this assessment separate from two later records: what exact action the user authorized, and what execution was observed. A valid price check does not authorize a transaction. A transaction hash alone does not explain the decision or the authorization that preceded it.

This separation guides my work on Insight for oracle evidence and PriorSeal for EVM authorization and execution evidence.

How do you preserve policy context in an audit trail: a full snapshot, an immutable reference, or both?

Comments

[Axiru]

Modeling insufficient evidence and retrieval failure as different outcomes, and keeping the policyId with the assessment, is the right pause shape. An empty price field months later cannot tell an auditor which of those happened.

A passed price check is not a spend approval. When the agent later proposes the ETH to USDC swap, do you bind the yes to amount, asset, and destination so a later re-plan cannot reuse that yes on a different payload?

[imokokok]

Yes, I would bind the approval to a specific transaction intent, not to a general “go ahead.” For an ETH → USDC swap, that intent would include the chain, assets, input amount, minimum output, recipient, approved router or spender, and an expiry. I’d hash those terms and verify the proposed execution against them. If replanning changes a material term, the agent needs a new approval. The price-check result remains separate evidence; passing it never grants permission to spend.
I’m still thinking through which execution details can vary without changing the approved intent—for example, gas settings. How would you draw that boundary?