Skip to main content

Agent Operating Model

What must be true before an agent becomes an accountable actor instead of a loose tool?

The Agent Operating Model says an agent is trusted through a loop: intent, language, capability, action, receipt, and consequence. Each step must be readable before execution and auditable after execution.

Operating Loop

Intent:

  • the human or agent names the desired state and boundary.
  • proof: the scope can be quoted.

Language:

  • the agent uses shared terms, symbols, and decision labels.
  • proof: the term resolves to the agent source contract.

Capability:

  • the agent calls only declared work.
  • proof: the capability has status, input, output, cost signal, and receipt rule.

Action:

  • the agent acts inside authority.
  • proof: delegation and tool scope agree.

Receipt:

  • the action emits a trail.
  • proof: the trail names scope, action, cost, and outcome.

Consequence:

  • the result feeds the next loop.
  • proof: the next agent can learn from the outcome.

Capability Status

  • REALITY — built, callable, and proven.
  • DREAM — desired demand, not yet callable.
  • CONSUMED — provider-owned capability the platform uses but does not own.

No page should let a planned capability read as live proof.

Checks

  • Identity is visible.
  • Capability status is visible.
  • Authority is visible.
  • Human override is visible.
  • Receipt expectation is visible.
  • Consequence feeds the next decision.

Failure Modes

  • Tool thinking — the agent is treated as a button, so accountability disappears.
  • Capability theatre — planned work reads like shipped work.
  • Authority blur — spend, identity, or write access lacks a boundary.
  • Receipt gap — action happens but the next agent cannot audit it.

Context

  • depends-on DDL Nomenclature — language must be shared before action can be trusted.
  • depends-on Dreamineering Symbols — compressed messages still need a decoder.
  • risk-governed-by Delegation — authority boundaries decide whether an agent acts.
  • proved-by Performance — trust needs proof, not posture.

Questions

Which part of the loop is weakest?

  • Is the intent explicit?
  • Is the language shared?
  • Is the capability real?
  • Is authority scoped?
  • Is the receipt useful?