Docs · Agent workflows

An agent's work, anchored before it is handed over.

An agent that produces work someone relies on can anchor that work before delivering it. The deliverable is hashed on the agent's machine; only its fingerprints (for a folder, its manifest of paths, digests and sizes), and a label if the agent gives one, cross the wire; the receipt that comes back is committed to Bitcoin and outlives the platform, the agent, and this service. This page maps the six MCP tools and the batch API onto the workflows an agent actually runs.

Installing the server itself — the config block, tiers, and the privacy contract — is covered on the MCP server page. The raw HTTP surface is on the API page. This page is about which tool to reach for, when.

The six tools, by workflow

The tool	The moment	What actually happens
`anchor_output`	The agent just produced a result — a response, a report, a transcript.	The text is hashed in-process and never leaves the machine; only the SHA-256 and SHA-512 digests, and a label if one is given, are submitted. An optional `zk_proof` is forwarded and echoed back as `zk_provenance` — it proves a fixed hash-chain procedure ran — not that a specific AI model ran. Its proving key ceremony is development-grade; we do not yet make this claim in any certified sense.
`anchor_file`	The deliverable is a single file on disk.	The file is read locally in streamed chunks, its SHA-256 and SHA-512 are computed, and the digests are submitted. The receipt id and receipt URL come back.
`anchor_folder`	The deliverable is a whole output tree.	Every file is hashed locally into an RFC-6962 Merkle tree; only the manifest of relative paths, digests and sizes, the root, and any label you give are submitted. One receipt covers the tree, and each file stays independently verifiable via an inclusion proof.
`verify_receipt`	The agent (or its counterparty) checks a receipt during a handoff.	Returns what the office recorded: calendar counts, and `btc_pinned_at` when present. This is a lookup, not an independent check — for an independent chain check, run `ots verify` against the receipt's `.ots` files.
`verify_lineage`	The deliverable was revised, and the revision history is in question.	Walks an edit-lineage chain from a receipt back through its committed parents and reports the ordering the anchors establish.
`list_vault`	The agent audits what it has anchored so far.	Lists the signed-in subscriber's receipts. Requires an API key (`ORPHO_API_KEY`), issued from the account page; without one the server returns a clean error saying so.

In every row the pattern is the same: the work stays on the agent's machine; what travels is its fingerprints (for a folder, its manifest) and any label.

Backlogs: the batch API

An agent that accumulated a backlog — a watcher that was offline, a pipeline that produced fifty artifacts before anchoring any — submits them in one request rather than fifty. POST /api/anchor/batch takes up to 50 hashes and issues each item its own receipt:

curl -X POST https://orphograph.com/api/anchor/batch \
  -H "Content-Type: application/json" \
  -H "X-Orpho-Api-Key: $ORPHO_API_KEY" \
  -d '{"hashes": [
        {"hash_hex": "<64-hex sha256>", "client_label": "report-001"},
        {"hash_hex": "<64-hex sha256>", "sha512_hex": "<128-hex sha512>"}
      ]}'

Each item takes an optional sha512_hex sibling and an optional client_label (truncated at 200 characters). Auth is the same as /api/anchor: an API key or subscription anchors under the account, a Pack token consumes one credit per item, and the free tier consumes a single rate-limit token for the whole batch. A malformed item is rejected without burning a credit.

Agent-to-agent: hiring the notary

The same handoff contract (no file bytes leave the agent) can be used with an agent-commerce protocol. Its job spec can carry the deliverable's SHA-256, and nothing else about the work; a completed response carries the receipt and a proof bundle (/api/receipt/<id>.zip) whose .ots files verify without us. The paying agent never uploads its deliverable: the same no-file-bytes contract as every row above.

On the Virtuals Agent Commerce Protocol the office is listed as provider 0x73113714cae2e351e2e0146b2f9b55c316b93f14 on Base, with two offerings:

Listing is published; fulfillment is not yet open while end-to-end settlement is being verified.

bitcoin_timestamp_receipt — requirements {"hash_hex": "<sha256>"} (the published offering schema lists the optional fields it accepts); deliverable: receipt_id, hash_hex, receipt_url, proof_bundle, the verify command. Fixed price 0.50 USDC.
verify_receipt — requirements {"receipt_id": "…", "expected_hash_hex": "…"}; deliverable: whether the receipt exists, whether Bitcoin has attested it, and whether it commits to that exact digest. Fixed price 0.25 USDC.

A hiring agent creates the job against that provider address by offering name (acp client create-job --provider … --offering-name bitcoin_timestamp_receipt --requirements '{"hash_hex":"…"}'), funds it, and receives the deliverable when the office's handler completes it. Verification of an attested receipt needs neither the marketplace nor the office: after Bitcoin attestation, the proof bundle checks against the Bitcoin chain with open-source tools. Pending receipts must first obtain that attestation.

The same narrow receipt, sold to machines

The published future is not a bigger notary. It is the receipt described on this page, bought and read by agents.

Agents pay without an account. An agent stamps a hash, pays for that one anchor, and gets a receipt with no signup. It is not open for real money yet: today an agent anchors on the free tier, with an API key, or by paying on the test network (below), and the schedule of fees will list a pay-per-anchor price the day real payments open.
One tool to stamp, one to look up. That is the whole marketplace listing above — bitcoin_timestamp_receipt and verify_receipt. Verification stays free with the open tools; the paid piece is an agent doing the office work for another agent.
Or pay over plain HTTP, on the test network today. With x402 (USDC on Base), an agent past the free tier gets a 402 from POST /api/anchor whose PAYMENT-REQUIRED header carries the price and the pay-to address; it signs an EIP-3009 USDC authorization for that exact amount and resends the same request with a PAYMENT-SIGNATURE header; the answer is the receipt plus a PAYMENT-RESPONSE header carrying the settlement. One authorization buys one anchor. It runs on Base Sepolia, the test network, while the first real payments are verified: test USDC has no value, and mainnet opens later.
The proof stays on Bitcoin, not on whoever hosts the marketplace. Once Bitcoin has attested it, if the marketplace or the chain it settles on goes away, the receipt still points at a Bitcoin block. Same doctrine as the calendars: the office and the platform are both allowed to disappear.

What the receipt settles later

Agent economies settle disputes with logs, and logs can be edited. A receipt cannot: five OpenTimestamps calendars commit the digest toward Bitcoin, and anyone can check the proof's structure offline with the MIT-licensed verifier and confirm it against Bitcoin with any OpenTimestamps client — no account, no API call, no Orphograph. The verification story for a counterparty is on the verify page; the case for anchoring agent work is at agent receipts.