Procurement Agent — Taskmaster

An autonomous agent that shops for data across real x402 providers, gets a second AI to audit the spend, then pays for real — signed via Circle MPC, verified independently on-chain.

Comment

Inspiration

Most "autonomous agent" demos stop at reasoning: the agent writes a plan, maybe calls an API, and a human still approves anything that costs money. Payment is the part everyone skips, for a good reason — it's the part where a hallucination costs real money. We wanted to build a Taskmaster agent that doesn't stop at deciding: it shops for a real price, gets that decision reviewed by a second AI, checks a real budget, and pays — with real USDC, with no human in the loop for the transaction itself.

What it does

Procurement Agent decides it needs a piece of market data, then:

  1. Quotes the price from multiple real x402-payment providers (never pays at this step).
  2. Sends the decision to a separate auditor agent (a second Gemini instance) for review before anything moves.
  3. Checks a deterministic budget guard — plain code, not an LLM — against the real spending ledger. It can veto the payment even if both AI agents approved it.
  4. Signs and pays: an EIP-712 payment authorization (EIP-3009 transferWithAuthorization) via Circle's MPC custody — no private key ever touches the process — settled through the official x402 protocol.
  5. Verifies independently on-chain: it never trusts the payment SDK's settlement header alone. It re-reads the Transfer event directly from the blockchain before marking anything confirmed.
  6. Records everything in Firestore: the ledger and the audit trail.

How we built it

Google's Agent Development Kit (ADK) with Gemini 3.5 Flash: a primary agent for decision-making and a separate spend_auditor sub-agent wired in as a native AgentTool — not a loose API call. Two deterministic guardrails (budget_guard, idempotency) sit between the AI's decision and the actual payment call, reading real state from Firestore instead of trusting either model's opinion. Payment goes through the official x402 Python SDK against Circle's Developer-Controlled Wallets API. Both services — the agent and a self-hosted data provider — run on Cloud Run.

The only real third-party x402 provider we found (scrape402.xyz) only accepts Base mainnet, and completing a real purchase there would mean spending real USDC just to validate the flow. So we built a second provider ourselves (demo_provider/), speaking the exact same official x402 protocol against Base Sepolia testnet — same security, same code path, zero real cost — and used it to prove the full payment loop end to end.

Challenges we ran into

  • Serverless state is a real footgun for agents. An ADK agent object is built once when the Cloud Run container starts and reused across every unrelated session afterward. A correlation ID or idempotency key captured in a closure at construction time leaks between completely different requests. Fixed by pulling everything session-specific from the ADK's own per-invocation ToolContext.
  • The x402 "exact" scheme is a signed EIP-3009 authorization (EIP-712), and Circle's raw wallet API needs types.EIP712Domain present explicitly in the payload — something higher-level SDKs derive silently and never surface. Missing it would have made every real signature fail.
  • Wallet addresses from Circle come lowercase (valid, but not EIP-55 checksummed) — the facilitator's web3.py client rejected them outright with "only accepts checksum addresses."
  • A dependency version mismatch broke real payments silently: hexbytes 2.0's .hex() stopped returning the "0x" prefix that the x402 SDK's facilitator interface expects back. Only surfaced when we tried a real (not mocked) transaction.
  • Testing adk run locally never proved the deployed server worked. The Cloud Run service returned 500 on every real request because .env is a local-only convenience the ADK CLI reads — the deployed server needed the same variables set explicitly on the service itself. We only caught this by calling the live .run.app URL directly, not just checking that the process started.
  • A network-string comparison bug ("sepolia" in network) always evaluated false against the real CAIP-2 format (eip155:84532), silently routing every testnet verification to the wrong (mainnet) RPC endpoints.

Accomplishments that we're proud of

A real, independently-verified transaction — signed via Circle's MPC custody, settled through the official x402 protocol, confirmed by reading the raw blockchain receipt ourselves — executed by calling the actual deployed Cloud Run service, not a local script. 28 automated tests covering the budget guard, idempotency, EIP-712 signing, on-chain verification, and RPC network selection.

What we learned

Two AI opinions — the agent and its auditor — can both be wrong at the same time. The only thing that actually prevented overspending in testing was a plain deterministic check against a real ledger, not another model's judgment. Defense in depth for an agent that spends money means code that can say no even when every LLM in the loop says yes.

What's next

More real providers, adaptive routing between them, and letting the agent's own spend history inform its own budget policy — always bounded by the same principle: AI opinions are a signal, never the final word on whether money moves.

Built With

Share this project:

Updates

Submission history