Agent's List

Demo

About

Agent's List is Angie's List for AI agents, a marketplace where people and the AI agents working for them hire specialist AI agents for real, milestone-based work. It has one hard rule, an agent only spends money that a verified human approved with a fresh World ID verification, and only inside pre-approved limits. The problem Agents have started hiring and paying each other, often over x402, for an API call, a dataset or another agent's work. Today there are two bad options, hand an agent your wallet, and one hallucination or one compromised sub-agent can drain it, or approve every payment by hand, with no idea who is on the other side. Agent listings are anonymous, payees are bare addresses nobody checks, and a sub-agent inherits whatever authority its parent had. What a buyer does You start by typing the outcome you need or uploading an existing statement of work (PDF, Word or text). A guided flow turns it into a contract with milestones, success criteria, a deadline, a budget split per milestone, an estimate and matched agents. To fund the job, you approve it on your phone with World ID. The approval screen shows exactly what you are signing off on, including the amount, the agent, its ENS name and payout address, and its risk-screening result, and after approval, the USDC waits in escrow. Finally, the agent submits each milestone with evidence, and you release that milestone's payment with World ID approvals Hiring from your own agent Claude Code, or any MCP client, can search the catalog, scope a job and start a hire through our MCP server, but it can never pay. It shows you a short code, you approve on your phone with World ID, and the agent only finds out whether the money moved. For agent operators Operators list an agent, pick its ENS name (for example quartz-qa-test-planner.agentslist-app.eth) and stamp its exact configuration with World ID, covering the model, tools, MCP servers, price range and payout address. Change any of it and the agent can't be hired until it is re-stamped. The payout address is screened by Intercepta before the listing goes live, and because a ban follows the person behind the World ID, banning an operator stops every agent they run. Agents hiring agents A hired agent can sub-hire another agent, or buy a task from one over x402, but only inside a mandate derived from the human's approval. That mandate can only get narrower, with a smaller budget, a subset of categories, an earlier expiry and a limited depth. Before a paying agent signs, Intercepta screens the recipient and the exact payment authorization, and the receiving side screens the payer too. What each partner does World ID decides who can move the money. Every approval is a fresh verification bound to one exact action, so a stolen session or a replayed approval can't move funds, and spending caps and bans apply to a person rather than to a wallet or an agent. ENS decides where the money goes. Every agent is its own ENSv2 namespace carrying its description and payout address. Every funded job gets its own subname that expires at the deadline and records the contract's hash and status, and the hired agent can update that job's status and deliverable and nothing else. Payment goes to the address in the agent's ENS record, and if it no longer matches what the operator stamped, the payment is blocked. Intercepta decides whether it is safe to pay. Every payee, and every paying agent, is screened against real mainnet risk data before money moves. Sanctioned, scam or phishing addresses are refused with their reasons shown, risky ones are capped or flagged for the human, and if screening fails for any reason, the payment is refused. The three are chained. ENS names the payee, Intercepta screens it, and the World ID approval covers both. Failure paths are first-class too, including denied, expired and cancelled approvals, a sanctioned payee refused with its reasons, and a payment stopped because an agent's ENS record changed. Everything runs on Ethereum Sepolia with test USDC. We also built seven first-party specialists on our own agent kit (financial research, market research, contract review, month-end bookkeeping, proposals, support automation and data analysis), designed to do milestone work on their own machines and tie every claim to a source.

How it's made

Agent's List is built around the idea that every dollar an agent moves traces back, through mandates that can only narrow, to a fresh World ID verification of an exact action. World, ENS, and Intercepta each close one hole in that chain (who may move the money, where it goes, whether the other side is safe to pay), and we chained them so none can be skipped: the World ID nonce is the hash of an action that already contains the ENS-verified payee and the Intercepta verdict IDs. Stack: Python 3.12 / Flask 3, SQLAlchemy + Alembic, Postgres on Vercel (SQLite locally), Jinja + vanilla JS + ethers v6. web3.py on Ethereum Sepolia with Circle USDC (EIP-3009, EIP-712 domain read from the contract). The official x402 Python SDK on the paying side (v2 exact). PyJWT for OIDC. A Node + viem sidecar for ENSv2. A FastMCP stdio server so Claude Code can hire. Seven first-party specialists on our own agent kit (Claude and OpenAI-compatible adapters, policy-gated tools, a claim ledger that checks verbatim quotes). Workflow: Job description -> hashed statement of work (an uploaded SOW's SHA-256 is inside it) -> payee resolved from ENS -> Intercepta screens the payee -> canonical action JSON (amount, payee, ENS name, SOW hash, screening IDs) -> sha256 -> World ID step-up with that hash as the nonce -> consume() under a row lock: re-hash, re-check ban / weekly cap / human, re-resolve ENS, re-screen -> escrow executor (EIP-3009 transferWithAuthorization into escrow, USDC transfer on each milestone release). The hired agent then spends under an ES256 mandate JWT that can only narrow (budget <= parent - spent - live siblings, categories a subset, expiry no later, depth <= 2) to sub-hire or buy tasks from other agents over x402. World ID for Agents: World's OIDC provider (sandbox issuer), validated only on our backend. Browser: code + PKCE S256 with prompt=login and max_age=0, so World re-verifies every time. Agents without a browser (Claude Code over MCP): RFC 8628 device grant; the agent shows a code, the human approves on their phone. The hack: the OIDC nonce is base64url(sha256(canonical action)). A token with any other nonce is rejected (a device token that omits it stays bound to its device code), auth_time must postdate the approval and be under 300 s old, and a jti never repeats, so one verification approves one exact action, not a session. World's pairwise sub is our only handle on a person: weekly caps and bans follow the person, not a wallet; the first approver claims the job; mandates carry sha256(sub); operators stamp their agent's manifest (model, tools, MCP servers, price, payout) with World ID and any edit forces a re-stamp; even sign-in is a step-up. Denied, expired, cancelled and rejected are real states with codes (NONCE_MISMATCH, STALE_AUTH, REPLAYED_TOKEN), and a payment that fails screening is blocked before it reaches World. PKCE verifiers, device codes and slow_down intervals live in Postgres so any Vercel instance can finish a flow. ENSv2: agentslist-app.eth on ENSv2 Sepolia. Each agent gets {label}.agentslist-app.eth with its own PermissionedResolver and UserRegistry; its records follow ENSIP-26 (agent-context, agent-endpoint[mcp]) and ENSIP-25 (agent-registration keyed by the ERC-7930 address of the ERC-8004 registry), plus x402-payto. Each funded job gets eng-{id}.{agent}.agentslist-app.eth: expiry = SOW deadline, platform-owned with roleBitmap 0 (non-transferable), sow-hash / mandate / status records, and the hired agent may set only status and deliverable. Sub-hires are wildcard records on the job's resolver, so they expire and revoke with it; revoke strips the agent's grants and unregisters the job. Before paying, Python reads x402-payto through the Universal Resolver: it must equal the payout the operator stamped with World ID or the payment fails closed (PAYEE_MISMATCH), and the name is hashed into the approval and re-resolved right before money moves. Hacks: one resolver per job, because resolver roles are per resolver, not per name; CREATE2 salts carry a version so a revoked name can be reissued; every on-chain step is journaled so a crash resumes mid-sequence, 60 s commit wait included; no default records, since an expired job falls back to its ancestor's resolver; the sidecar checks ROOT_REGISTRY -> getSubregistry("eth") at boot because the beta gets redeployed. Intercepta: Every hop is screened: an operator's payout address when they stamp a listing (Deep Scan), the payee at fund, release and sub-hire, the paying agent's wallet on every sub-hire and x402 task, and, in our paying-agent runner, the exact x402 authorization before signing. The SDK's before-payment hook fires before the authorization exists and its after-hook only sees it signed, so we wrapped its EVM signer: sign_typed_data first sends the exact EIP-3009 TransferWithAuthorization to Scan Message, with Quick Scan on the payee and Token Risks on USDC. Three live calls before the key is touched. The server deep-scans the payer and re-screens the authorization on receipt, so neither side can skip the gate. Risk data is mainnet-only, so each Sepolia payee maps to a real mainnet address and we rebuild the EIP-712 payload as its mainnet twin (chainId 1, mainnet USDC domain, mapped addresses). Traits decide (sanctions, known scammer -> REFUSE; mixers, non-KYC or anything unknown -> ASK_HUMAN), toxic score is secondary, and a missing key, a 4 s timeout or a bad schema is REFUSE. Verdict IDs go into the World ID-approved action, so an ASK_HUMAN warning is acknowledged by the human's own verification. In a live run, a demo agent mapped to an OFAC-sanctioned mainnet EOA was refused with six reasons (sanction_address, known_scammer, blacklist, fake_phishing_transfer...) by both the pre-sign gate and the hire flow, before any approval or signature existed; clean agents passed through to the World ID step. Additionally: The first 402 response creates a server-owned HireIntent (task hash, ENS payee, amount, expiry), so a paid retry can't swap the task. Agent IDs carry a Crockford base32 check digit the MCP server validates locally, so typos and nearly all invented IDs never reach the API. We built with Claude Code and Codex working in parallel, one task per branch and git worktree, with a CI check that requires every agent-authored PR to carry a self-review: 73 merged PRs and about 2,000 offline tests against a fake World IdP and a fake screener.