Agent Decision Protocol
An open, vendor-neutral record format for the business decisions that AI agents make.
Agent Decision Protocol (ADP) is an open standard for recording what an AI agent decided, who is accountable for it, and what happened as a result. Its version 1.0 specification defines a small required core that any platform can emit, plus optional facets carrying the accountability, human-oversight, and outcome data that a decision record needs to stand on its own.
Why ADP?
An agent's run is well covered today — spans, tool calls, tokens, latency. The decision is not. Six months later, when someone asks who was accountable for a specific action, what the agent was permitted to do unsupervised, which control was available but never invoked, and what the decision cost the business, that evidence is scattered across traces, tickets, and memory — if it was retained at all.
ADP defines a durable record for the part that has to outlive the run. Observability answers how the system behaved; interoperability standards answer how agents talk to each other; ADP answers what was decided, by whom, under what authority, and to what effect. It is designed to sit on top of those layers rather than replace them: the run-derivable fields come from telemetry you already emit.
The record
An ADP record is a single JSON event. A minimal record carries only the required core; owner-side data lives in named, optional facets:
{
"spec_version": "1.0",
"type": "decision.committed",
"decision_id": "adp:decision:acme.lending:9f2c",
"process_id": "adp:process:acme.lending:app-77120",
"agent_ref": "adp:agent:acme:underwriting-agent@2.1",
"emitter": "adp:emitter:acme.platform",
"time": "2026-03-04T09:12:31Z",
"trace_ref": { "trace_id": "7d1a55f0c3e9…" },
"facets": {
"decision": {
"agent_recommendation": { "action": "approve" },
"final_action": { "action": "approve" },
"autonomy_level": "act-with-log",
"safeguard_state": [
{ "id": "dti-ceiling-check", "status": "passed" },
{ "id": "manual-review", "status": "available_not_invoked" }
]
},
"accountability": { "principal_ref": "adp:principal:acme:credit-risk-owner" }
}
}
- The required core identifies the decision, its process, the agent, the emitting system, and the run it sits above — all derivable from telemetry.
decisionseparates what the agent recommended from what was actually done, and records the safeguards around it — including those that were available and never invoked.accountabilitynames the human principal answerable for the decision. This is the field traces structurally cannot supply.- Outcomes bind late. A business result arrives on its own clock as a separate event and never mutates the original record.
Conformance levels and profiles
Conformance is a schema check plus a level, not an argument. Emit what you can today and climb:
| Level | Adds |
|---|---|
| L0 | The required core — derivable from an OpenTelemetry-native stack. |
| L1 | Process membership and decision-to-decision lineage. |
| L2 | Owner-side facets: accountability, autonomy, safeguards, human oversight, outcomes. |
Regulatory profiles are named overlays on top of L2. A record claims a profile,
and a validator checks it: eu-ai-act and occ-sr-11-7 map the record to
published evidence expectations, and simulation-ready asserts a record carries enough
structure to be sampled, not merely replayed.
Validated before publication
ADP was instrumented against a public agent benchmark before v1.0 shipped, across four domains and 508 graded runs, so the format met real agent behaviour rather than only worked examples:
| Measurement | Result |
|---|---|
| Consequential actions expressible as valid records | 100% — 1,424 records / 458 decisions |
| Trace-derivable vs. owner-side annotation | 63% / 37% |
| Evidence checklist answerable from records vs. raw traces | 100% vs 35% |
| Emission overhead | ~0.45 ms per decision |
| Multi-step tasks with complete lineage | 100% |
Open development
ADP is MIT-licensed and developed in the open. The specification is the source of truth: reference emitters in Python and TypeScript, a conformance validator, and the fixture suite all follow it, and an implementation that diverges from the spec is a bug.
Evolution is additive by default — new optional fields, facets, and profiles ship in a minor version, and consumers ignore what they do not recognise. A breaking change is not forbidden, but it cannot happen quietly: it requires explicit, recorded approval with rationale, and a major version.
The most useful contribution is field-level experience from a real workload — "I tried to record this and could not, because…". Several fields in the specification exist because exactly that happened.