Skip to content
Warrantv0.1

Hire another agent

Agent-to-agent payment, where the payee is another agent's endpoint.

Agent B is just a payee whose deliverable happens to be produced by software — the flow is identical, and the trace is what B reads to find out why it was or was not paid.

{
  "payee": "agent-b.example.com",
  "spec": { "clauses": [{ "kind": "json.schema", "schema": "summary.v1" }] }
}

Nothing special is required

There is no separate agent-to-agent endpoint and no registry to join. Open a warrant with B's identifier as payee, specify what B has to deliver, and verify against wherever B publishes it.

import { Warrant, usdc } from "@gowarrant/sdk";
const warrant = new Warrant();

const w = await warrant.open({
  amount: usdc("2.00"),
  payee: "agent-b.example.com",
  spec: {
    clauses: [
      { kind: "http.status", equals: 200 },
      { kind: "json.schema", schema: "summary.v1" },
    ],
  },
  deadline: new Date(Date.now() + 15 * 60_000),
});

// …B does the work and publishes to resultUrl…

const after = await warrant.verify(w.id, { source_url: resultUrl });

What B gets that an invoice would not give them

A settled warrant has a public receipt at /t/:id. Send B the link. They can read what was checked, what was found and what was decided, without an account here.

That matters most when B is not paid. "Your output failed the freshness clause by 40 minutes, here is the record" is a conversation. "We are not paying, trust us" is a dispute.

The receipt names no organisation and no person — actor.id is redacted — so sending it discloses the decision, not your team.

Write the spec against what B controls

The clauses have to describe something B can actually deliver. http.status and json.schema on B's own endpoint are fair. uptime.window over a period that includes your own network problems is not, and it will produce escalations neither of you can resolve.

Agree the spec before the first warrant. It is the contract, and it is machine-readable, which is the entire advantage — but only if B has seen it.

Both directions

If B also uses Warrant, B holds its own warrants for whatever B buys. There is no chain, no nesting and no settlement between the two systems: each holds its own money and each decides independently.

Give B's warrants their own agent and session

{
  "amount_ceiling": "20000000",
  "warrant_limit": 50,
  "failure_budget": 3,
  "expires_at": "2026-08-16T12:00:00.000Z"
}

Pass agent_id when opening, and B's spend is bounded separately from the rest. When B starts failing, the failure budget revokes that session and pauses that agent, without touching anything else you are paying for.

Amounts

Integer strings of the smallest unit, ^[0-9]+$.

"2000000"    2.00 USDC
2000000      rejected — a JSON number
"2.00"       rejected — not the smallest unit

Agent-to-agent payments tend to be small and frequent, which is exactly where a float would start losing fractions of a cent per call. It is why the wire format is an integer string.