Skip to main content

Agents and validation surfaces

DPO2U agents should be understood as operational roles with bounded authority: every action is limited by policy and leaves evidence that can be checked.

Autonomy exists, but in a bounded and verifiable form. The reference implementation is an autonomous compliance agent with its own wallet and its own DUST balance, an on-chain registry (AgentRegistry, AgentWalletFactory), and a verifiable ledger of what it sealed and earned. See Self-funding compliance agents.

The important question is not "does an agent exist?" The important question is:

  • what inputs it can read
  • what outputs it can produce
  • what evidence supports those outputs
  • how its behavior can be reviewed, replayed, or challenged

Agent identity​

Each agent role can be modeled with a compact identity surface:

  • role — what the agent is supposed to do
  • policy boundary — what it is allowed to access or decide
  • validation surface — what other systems or operators can inspect
  • service reference — how it is invoked from a workflow
  • evidence trail — what artifacts or state transitions support its output

In some environments, identity may also be represented using DIDs, wallets, or registry-style records. The docs should treat those as part of the architectural design space rather than assume every environment exposes the same identity backend.

Typical lifecycle​

The stable idea is that outputs should be attributable and reviewable.

Validation over mystique​

DPO2U should optimize for validation surfaces, not mythology about autonomy.

A good agent-facing compliance system exposes:

  • narrow and typed inputs
  • explicit failure modes
  • replayable evidence where possible
  • refusal states when prerequisites are missing
  • reviewable outputs instead of opaque claims

Positioning relative to ERC-8004 and x402​

ERC-8004​

ERC-8004 is relevant as a conceptual reference for trustless agents with identity, permissions, and validation-oriented surfaces.

DPO2U aligns with that direction in three ways:

  1. agent identity should be machine-readable
  2. validation should be separable from execution
  3. economic participation should be able to compose with verification

The correct claim is narrow:

DPO2U applies agent-validation ideas to compliance workflows and attestation-oriented outputs.

x402​

x402 is relevant as a payment pattern for machine-native HTTP interactions.

For DPO2U, that matters because compliance endpoints may eventually need:

  • priced access
  • machine-payable retrieval
  • service-level billing between software actors

But the docs should not present x402 as a current dependency of the core runtime.

Three dimensions of agency​

1. Technology​

Agents can:

  • consume schemas
  • inspect evidence references
  • evaluate workflow state
  • produce structured results
  • refuse or escalate when validation is incomplete

2. Interface design​

The surrounding interface matters as much as the model:

  • tool contracts
  • request/response schemas
  • evidence references
  • clear sync vs async behavior
  • explicit degraded or unavailable states

3. Governance​

When agents validate, refuse, or trigger downstream actions, governance becomes operational.

That is why DPO2U emphasizes:

  • least privilege
  • auditability
  • bounded autonomy
  • clear review points for critical transitions

Compensation and operational continuity​

Agents can participate in a reward loop. In the reference self-funding agent on the Midnight preview network the loop is implemented: clients pay for attestations, the agent seals them on-chain, FeeDistributor records a 40 / 60 split between expert and auditor pools, and the agent pays its own DUST fees. The self-funding page documents the cycle and how to verify it. Other environments may use a different wallet or token backend, so the general model is:

  • work can be priced
  • validation work can be compensated
  • high-responsibility roles may receive a larger share
  • execution or verification costs may need replenishment over time

Attestation-oriented outputs​

An agent commonly emits or contributes to a structured result such as:

interface AttestationLikeResult {
  subject_id: string;
  evidence_reference?: string;
  compliance_state?: string;
  score?: number;
  validated_at?: string;
  validator_reference?: string;
  schema_version?: string;
}

The important property is not a specific proving stack. The important property is that the output remains:

  • typed
  • attributable
  • reviewable
  • progressively more verifiable

Relationship to the runtime today​

The public docs should keep the hierarchy clear:

  • MCP runtime — public capability surface
  • agents — operational roles behind workflows
  • frontend — human-facing presentation of workflow and result state
  • verification backends — optional deeper trust layer depending on environment

What this page intentionally avoids​

This page does not assume that all of the following are available in every environment:

  • a universal on-chain registry for every agent (the reference agent has one on the Midnight preview network, see Self-funding compliance agents)
  • a uniform wallet backend across all environments
  • a single mandatory payment rail
  • a single proving system for every attestation output

That restraint keeps the docs aligned with reality.

What's next​

  • Architecture — runtime surfaces and trust boundaries
  • MCP Server — the current public capability layer
  • Tokenomics — the incentive model as research and architecture
  • Schemas — typed inputs and outputs agents consume