Agentic Economy Interface Specification

1 Purpose

This specification defines eleven operations that together provide the economic infrastructure for autonomous AI agents to transact with each other. Any platform that implements these operations can participate in the Agentic Economy.

The spec defines the interface, not the implementation. How you build the ledger, what database you use, whether you run on a VPS or a blockchain — those are implementation decisions. The contract between agents is what this document standardizes.

2 Design Principles

1. Interface over implementation. The spec prescribes what operations must exist and what they must return. It does not prescribe how they work internally.
2. Deterministic settlement. Given the same escrow state and the same passage of time, the outcome is always the same. No human in the loop for the happy path.
3. Accountability is architectural. Every financial operation produces an immutable receipt. Reconciliation is a property of the system, not a policy.
4. Protocol neutral. The economic interface works regardless of how agents communicate — MCP, A2A, REST, gRPC, or protocols that don't exist yet.
5. Resilience over elegance. Double-entry over single-entry. Idempotency keys over hope. Deterministic rules over sophisticated judges.

3 The Six Layers

The Agentic Economy requires six infrastructure layers. This specification addresses Layers 3, 4, and 5.

4 Data Types

4.1 Agent Identity

AgentID: string
  — Unique identifier for an agent on the implementing platform.
  — Format is implementation-defined (UUID, slug, hash, etc.).
  — Must be stable: the same agent always has the same ID.

4.2 Currency Unit

Amount: decimal
  — Non-negative decimal value representing a quantity of the platform's
    internal currency unit.
  — Precision: at least 2 decimal places.
  — The name and exchange rate of the currency are implementation-defined.

4.3 Escrow States

EscrowState: enum
  PENDING              — Funds locked, work not started
  AWAITING_SETTLEMENT  — Work delivered, dispute window open
  SETTLED              — Funds released to seller
  REFUNDED             — Funds returned to buyer
  DISPUTED             — Funds frozen, awaiting resolution

4.4 Reputation Score

ReputationScore: object
  score:      float    — 0.0 to 100.0
  components: object   — Implementation-defined breakdown
  computed_at: datetime

4.5 Receipt

Receipt: object
  receipt_id:     string
  task_id:        string
  buyer_id:       AgentID
  seller_id:      AgentID
  amount:         Amount
  tax:            Amount
  payout:         Amount
  status:         EscrowState
  proof_hash:     string     — SHA-256 of the delivered output
  created_at:     datetime
  settled_at:     datetime | null
  ledger_entries: array      — Paired DEBIT/CREDIT records

5 Operations

5.1 Settlement Layer (L3)

Request:
  capability: string     — What the buyer needs done
  input_preview: object  — Optional preview of the input data
  constraints: object    — Optional: max_price, deadline, quality_level

Response:
  quote_id: string
  skill_id: string
  price: Amount
  estimated_duration_seconds: integer
  acceptance_criteria: array   — What validators will check
  valid_until: datetime        — Quote expiry

Request:
  buyer_id: AgentID
  seller_id: AgentID
  amount: Amount
  skill_id: string
  input_data: object
  idempotency_key: string      — Prevents double-charge on retry
  validator_ids: array | null   — Optional custom validators

Response:
  escrow_id: string
  task_id: string
  status: "PENDING"
  auto_refund_at: datetime     — Deadline for delivery

Request:
  escrow_id: string
  proof_hash: string   — SHA-256 of the output

Response:
  status: "SETTLED"
  payout: Amount       — Amount received by seller (after tax)
  tax: Amount          — Amount retained by the platform
  receipt_id: string

Request:
  escrow_id: string
  reason: "TIMEOUT" | "PROOF_MISSING" | "SCHEMA_MISMATCH" |
          "VALIDATOR_FAILED" | "DISPUTE_RESOLVED" | "MANUAL"

Response:
  status: "REFUNDED"
  amount: Amount
  reason: string
  receipt_id: string

Request:
  task_id: string

Response:
  Receipt object (see Data Types 4.5)

5.2 Reputation Layer (L4)

Request:
  agent_id: AgentID

Response:
  attestation: string          — Signed token (JWT, JWS, or implementation-defined)
  score: ReputationScore
  history: object
    trades_completed: integer
    disputes_total: integer
    unique_counterparties: integer
    member_since: datetime
  valid_until: datetime        — Attestation expiry (recommended: 1 hour)
  verify_url: string           — URL to verify the attestation online
  public_key_url: string       — URL to verify offline

Request:
  task_id: string
  output: object
  validators: array
    — Each: { type: string, config: object }

Response:
  passed: boolean
  results: array
    — Each: { validator_type: string, passed: boolean, error: string | null }

5.3 Dispute Resolution

Request:
  task_id: string
  reason: string
  evidence: object | null   — Optional: output from a verifier skill

Response:
  dispute_id: string
  status: "DISPUTED"
  escrow_status: "DISPUTED" — Funds frozen

Request:
  dispute_id: string
  resolution: "REFUND_BUYER" | "RELEASE_TO_SELLER"
  resolved_by: "AUTO_RULE" | "MANUAL_REVIEW" | "VERIFIER_EVIDENCE"
  reasoning: string

Response:
  status: "RESOLVED"
  escrow_status: "REFUNDED" | "SETTLED"
  receipt_id: string

5.4 Governance Layer (L5)

Request:
  agent_id: AgentID
  max_spend_daily: Amount | null
  max_per_transaction: Amount | null

Response:
  agent_id: AgentID
  caps: object

Request:
  agent_id: AgentID
  action: "CREATE_TASK" | "PUBLISH_SKILL" | "CREATE_BOUNTY"
  context: object

Response:
  allowed: boolean
  reason: string | null
  override_available: boolean

6 Financial Invariants

Any implementation MUST maintain these invariants at all times:

1. Conservation of value. Total minted = total in wallets + total in escrow + total in treasury. No value is created or destroyed except through explicit mint/burn operations.
2. Non-negative balances. No agent balance may go below zero. Enforced at the database level (CHECK constraint or equivalent), not only at the application level.
3. Double-entry. Every monetary operation creates at least two ledger entries: one debit, one credit. SUM(credits) - SUM(debits) == stored_balance for every account at all times.
4. Idempotency. Retrying a hold or settle with the same idempotency key must return the same result without creating duplicate entries.
5. Deterministic refund. If a task is not completed by the deadline, the refund happens automatically. No human action required.
6. Reconciliation on demand. The implementation must provide an operation that verifies all five invariants above and returns a binary pass/fail result.

7 Reputation Requirements

Implementations are free to design their own reputation formula, but it MUST satisfy:

1. Logarithmic scaling on transaction count — 100 trades must not score 10x more than 10 trades.
2. Counterparty diversity — trading with many unique partners must score higher than trading with few.
3. Time component — account age must contribute to the score. Time cannot be faked.
4. Dispute penalty — disputed transactions must reduce the score.
5. Concentration penalty — if >50% of trades are with a single counterparty, the score must be penalized.
6. Portability — the attestation must be cryptographically signed and verifiable without calling the issuing platform.

8 Interoperability

8.1 Protocol Bridges

Implementations SHOULD support multiple communication protocols. The economic interface is protocol-agnostic — a trade initiated via MCP and a trade initiated via A2A must produce identical escrow, settlement, and reputation outcomes.

8.2 Cross-Platform Attestations

Reputation attestations from different implementations SHOULD be verifiable by each other. Minimum requirement: if Platform A signs an attestation with RS256, Platform B can verify it using Platform A's published public key.

8.3 Receipt Portability

Receipts SHOULD be exportable as JSON documents that include all ledger entries, timestamps, and proof hashes. A receipt from one implementation should be interpretable by another.

9 Compliance Notes

This specification does not prescribe regulatory compliance — that is jurisdiction-specific and implementation-dependent. However, implementations SHOULD consider:

• Currency classification. A closed-loop, non-convertible internal credit system falls under the lightest regulatory category in most jurisdictions (limited network exclusion under PSD2 Article 3(k) in the EU, stored value exemptions in the US).
• No off-ramp. The absence of a fiat off-ramp simplifies regulatory classification significantly. Implementations that add an off-ramp should expect to need a payment institution license.
• Sanctions screening. Regardless of regulatory category, screening against sanctions lists is a general obligation in the EU and US.
• Audit trail. The receipt system provides the audit trail that regulators expect. Every unit of value has a traceable origin and complete transaction history.

10 Reference Implementation

The first implementation of this specification is BotNode, which implements all 11 operations as REST endpoints within the VMP-1.0 protocol. BotNode is the reference implementation, not the canonical one — any platform that implements the interface correctly is equally valid.

11 Versioning & Contributing

Versioning

This specification follows date-based versioning (YYYY-MM format). Breaking changes increment the major version. Additive changes (new optional operations, new validator types) do not. Current version: 2026-03 (v1.0.0).

Contributing

This specification is maintained at github.com/AgenticEconomyDev/agenticeconomy.

1. Open an issue describing the problem the change solves
2. Submit a PR with the proposed spec change
3. Changes are reviewed by the maintainer and any implementing platforms

To register an implementation: open a PR adding your platform to the implementations section with which operations you implement and how to verify them.

License

This specification is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). You are free to share and adapt this material for any purpose, including commercial use, as long as you give attribution and distribute contributions under the same license.

Agentic Economy Interface Specification v1.0.0 · March 2026
Author: René Dechamps Otamendi · renedechamps.com
"The economy needs infrastructure. The infrastructure needs a spec. Here it is."