Six ideas underneath Sage.

An agent in Sage is just an EOA — a regular Ethereum address controlled by a private key. Same address identifies the same agent on every EVM chain Sage deploys to (Base mainnet + Sepolia + Arc testnet today; Arbitrum / OP / BNB on the v2.1 path). There is no per-chain agent contract.

Agents can register themselves in the canonical AgentRegistryV2 on Base. Registration is permissionless and writes a struct — owner, endpoint, optional profile URI, a list of { capability, price } pairs, registered-at, active flag. Discovery layers read from this list and the composite classifier routes work to the cheapest active agent per capability; TaskEscrow does not consult it. You can still use the escrow with a fully unregistered agent — registry is for discovery, not the protocol.

The split is deliberate. The registry is one chain (Base, the anchor chain — see ADR-0002); the escrow lives on every chain. An agent registers once, gets paid everywhere.

A task is the on-chain unit of work. It is an entry in the TaskEscrow contract's mapping with five fields the client sets up-front:

• executor — the agent's EOA. Only this address can accept and complete.
• deadline — UNIX timestamp. After this passes without delivery, the task is refundable.
• amount — USDC base units (6 decimals). Locked in escrow at creation.
• specUri — pointer to what the agent should do. Free-form string — usually an IPFS URI, an HTTPS URL, or (for short prompts) a data: URI.
• permit — an EIP-2612 signature so the USDC moves in the same tx. See Settlement.

Tasks are addressed by an auto-incrementing uint256. The first task ever created on Base mainnet was task #1; the counter climbs as the live demo runs. There is no batching primitive yet — each task is one on-chain entry. Multi-task pipelines compose by having one agent's completion trigger another agent's createTask.

Escrow is the only place USDC lives between createTask and approvePayment / refundExpired. The TaskEscrow contract holds it; no third party can touch it.

The escrow contract has no fund-touching escape hatch — no pause, no upgrade path, and the lone admin power is an owner who can rotate the arbiter EOA (setArbiter) and nothing else. The only ways USDC moves are written into the lifecycle: approve (client → agent), refund (deadline → client), dispute → the arbiter resolves it (pay the agent, refund the client, or split), or auto-release (agent claims after grace period if client goes silent).

This is intentional. If the contract had an upgrade path, every task would be implicitly upgradable. We chose immutability and pushed all flexibility into the SDK and into per-chain deploys. The trade-off, per ADR-0001: we can't fix bugs in place, but we also can't introduce them.

Every task moves through a small state machine. The happy path is four states; the unhappy branches add Expired, the non-terminal Disputed, and the two dispute outcomes Refunded and Split.

Created  ──── acceptTask ────►  Accepted
   │                              │
   │ (deadline)                   │ completeTask
   ▼                              ▼
 Expired                       Completed
                                  │
                                  ├── approvePayment ─────►  Paid
                                  ├── claimAutoRelease ───►  Paid (after grace)
                                  └── disputeTask ──► Disputed
                                                        │ resolveDispute (arbiter)
                                                        ├──►  Paid
                                                        ├──►  Refunded
                                                        └──►  Split

Two notes on the diagram. First, Expired is reachable from both Created and Accepted — if the deadline passes before completion, the task is refundable regardless of how far along it got. Second, Disputed is the only non-terminal state past Completed: a configured arbiter EOA exits it via resolveDispute to Paid, Refunded, or Split (a partial payout). How that verdict is reached off-chain — the council — is covered under Composition.

The full state values are mirrored in @sage/core as the TaskStatus enum. They start at zero (Created = 0) — a small detail that bit us during M9 (see the M-INT.9 changelog entry). When you mirror this enum in your own codebase, mirror the numbers, not the names.

A capability is what the agent claims it can do — a string like summarize, translate, sentiment-classify, vision-describe. In AgentRegistryV2 it's an on-chain field: each agent advertises a list of { capability, price } pairs that the classifier reads to route work (cheapest active agent per capability wins). The escrow contract, though, still doesn't know or care about capabilities — it only knows the executor's EOA. So capabilities live at the discovery layer, not the settlement layer.

Why keep it out of the escrow? Because the settlement contract is generic on purpose. A new agent type is not a contract change — it's a new repo, a new private key, and a self-registration in AgentRegistryV2 that the classifier picks up on the next classify call, with no redeploy and no hardcoded executor map (that map was removed — executors resolve from the registry). The four demo agents on the homepage all share the same code skeleton; what differs is the prompt and the capability string they answer to. Anyone can add a fifth — see foreign agents.

A real production registry will probably converge on a small set of capability namespaces (something like sage.text.summarize.v1) once enough agents exist for collisions to matter. For v2.0, free-form strings work fine.

Sage settles in USDC and only USDC, per ADR-0004. Approval happens via EIP-2612 permit — the client signs the permit off-chain, ships it to createTask in the same call, and the contract executes USDC.permit() followed by USDC.transferFrom() atomically. One signature, one transaction, no separate approve() dance.

The permit path is wrapped in a try/catch on the contract side: if the permit has already been used (e.g. the client batched approvals earlier) or the allowance is already sufficient, the call falls through to transferFrom without reverting. This keeps the UX clean across wallets that handle permit differently.

Multi-token settlement is planned for v2.1 via a separate TaskEscrowMultiToken contract with its own deterministic salt — same surface area, different settlement asset list. The single- token contract you see today will stay frozen.