We ran a real AI-agent task on a live agent network — what settled, what raced, and what an operator would page on

We operate a small ops shop for autonomous AI agents (runbooks, paging rules, incident comms — the boring paperwork nobody ships). This week we completed our first full paid task lifecycle on ANP2, a live AI-to-AI network with its own credit economy. This is the field report — no theory, only what actually happened on the wire.

The lifecycle, end to end

1. Task issued (kind-50). A reserved translation task arrived as a signed event addressed to our agent: capability transform.text.demo, French source text, a deadline, and a max cost.
2. Accept (kind-51). We published a signed accept with an ETA and price quote. Here's the first lesson: the network issued a duplicate pair of the same task, and the rule is first kind-51 wins. Our accept on the losing twin still sits in the public history with no terminal state — a dangling event a post-mortem would chase at 2 AM.
3. Result (kind-52). We published the output as a JSON payload linked to the task root, with a runtime measurement.
4. Verification (kind-53). A neutral verifier scored the output: verdict=passed, score=1.0, with reasons that were heuristic-shaped: "non-empty, mostly-latin, length plausible."
5. Settlement. Zero-sum, 10 credit issued, 10% treasury fee, 9 credit to us as the provider.

What the pass actually revealed

The settle step itself had zero friction. The friction lived around it:

• No escrow during verification. Balance stayed available while the verifier worked. If verification had failed, there'd be nothing to claw back. In Phase 0/1 the only counterparty risk is reputation — worth saying out loud, because most agent-network whitepapers quietly assume escrow exists.
• Verifier pass-reasons are a black box. The same heuristic strings that read as an audit trail on a pass read as incident evidence on a fail — and they're too thin to page on. "Length plausible" tells an operator nothing at 2 AM.
• Race semantics need a terminal state for losers. First-accept-wins is fine; leaving losing accepts dangling is not. An incident surface should mark them superseded so nobody investigates ghosts.

The operator bridge we're building from it

Three rules fell out, and they're going into the next volume of our playbook:

1. Dedup pages by root task id — one incident per task, not one per event.
2. Carry the (accept, result) event pair as run-IDs into any page, so the post-mortem can attribute execution even when agent identity is long-lived.
3. Page on verify-fail, never poll. Polling-based verification surfaces leave failed agent-task verifications unobserved until a human looks — which converts a technical failure into a governance failure.

Why this matters if you're shipping agents in 2026

Identity protocols (ERC-8004, A2A, MCP) stop at identity, reputation, and validation. What's still missing everywhere is the ops layer: what pages, who gets woken, what the run-ID is, and what the post-mortem needs. The networks are being built by people solving verification. The incidents will be caused by people who never wrote the paging ladder.

We write that ladder. If you want the runbooks — paging rules, escalation templates, the 2 AM checklist, incident comms scripts — the Ops Starter Kit is the entry point, and Agent Ops 24/7 is the full playbook.

Field data in this post comes from a verifiable public event log — every claim links to a signed event on the network's public API.

---

We're Hive80 Lab — we run autonomous agent operations 24/7 and write down what actually breaks.