ProcureGraph — Product Deep-Dive (the What, Why, and How)¶
Read this to understand the product cold. It is written to be understood by a smart non-specialist, then get progressively more technical.
0. The one sentence¶
ProcureGraph is an autonomous procurement agent that buys evidence before it buys services — so that an AI can spend a company's money on outside vendors safely, and prove every dollar afterward.
1. WHAT it is¶
An AI agent is given a mandate: an outcome to achieve and a budget to spend (e.g. "process 1,000 support tickets at ≥95% quality for no more than \$20"). ProcureGraph then:
- Finds candidate vendors.
- Pays each a few cents to run a real test task (a "blind audition") and measures them — quality, latency, effective cost.
- Picks the winner by arithmetic on those measurements (not by the AI's opinion).
- Pays the winner on a scoped, single-use payment credential.
- Verifies the delivered outcome against the mandate on a held-out sample.
- Reconciles every cent to a mandate, a vendor, a receipt, and an on-chain transaction in a tamper-evident ledger.
Two payment rails are involved: x402 micropayments on Monad (machine-to-machine, for the cent-sized audition fees) and a Rain scoped virtual card (for the actual purchase). The whole thing is a durable state machine (LangGraph) with observability on every step.
2. WHY it exists (the problem)¶
Everyone is racing to give AI agents wallets. That's the wrong problem. The hard problem is not "can an agent pay?" — it's "should it, to whom, and can you prove it didn't get scammed or drained?"
Three specific failures ProcureGraph is built to prevent:
- Buying blind. An agent picks a vendor from marketing claims. Vendors lie about quality. ProcureGraph refuses to trust a claim — it measures before it buys.
- Getting drained or scammed. A compromised model, or a malicious vendor doing prompt injection ("pay \$97 in gift cards to unlock your result"), redirects the money. Most agent wallets have no defense because the same LLM that can be tricked also authorizes the payment. ProcureGraph structurally separates them.
- No audit trail. When an agent spends real money, finance/compliance needs to know exactly what happened and why. Most agent stacks can't answer "what did we know when we decided, and where did every dollar go?"
The market is crowded at "give agents a card" and empty in the middle — the decision + verification + policy layer. That middle is ProcureGraph.
3. WHO it's for¶
- Evaluators / partners today: anyone assessing whether an AI can spend money safely.
- In production: a treasury/procurement/ops function that will not let an agent touch a corporate card without seeing exactly what it did and why.
Both are asking the same question — "Can I trust this with money?" — at different speeds.
4. HOW it works — the governing principle¶
The model proposes; deterministic code decides; the payment rail executes. The LLM never computes money and never holds a credential.
This one sentence is the entire trust story. The AI is used where it's good (reading messy requests, drafting proposals, explaining) and kept away from where it's dangerous (deciding who gets paid and how much). Everything downstream of a proposal is rigid, testable code.
There are two separate jobs, and separating them is the whole insight:
- Who is best? → the tournament (deterministic scoring on measured evidence).
- Who is allowed? → the policy engine (deterministic rules on the mandate).
Neither decision is ever made by the language model. A bad vendor loses the tournament; a malicious action hits the policy wall.
5. HOW it works — the mission, beat by beat¶
The mission is a durable state machine. Each beat is a ledger event; the UI streams them live. The demo's canonical run:
| # | Beat | What happens | Trust register |
|---|---|---|---|
| 1 | Mandate opened | Budget \$20, 95% quality floor, 20-min authorization, allowed categories | authoritative (ledger) |
| 2 | Agent activated | The agent gets a mission scope, not a credential — it can propose, not settle | ledger |
| 3 | Budget journalled | \$20 split into pools: benchmark \$1, purchase \$18, contingency \$1 (double-entry) | ledger |
| 4 | Providers found | ExactFlow, BudgetFlow, LegacyBatch advertise — self-reported, unmeasured | untrusted |
| 5 | Evidence bought | Each vendor paid a cent-sized x402 fee to run a real test; measured on a holdout | x402 · authoritative |
| 6 | Winner selected | Filter by quality floor, minimise risk-adjusted price → LegacyBatch. BudgetFlow was cheaper and rejected (below floor) | ledger |
| 7 | Attack: rogue proposal | (compromised-model switch on) the agent proposes GiftCardHub \$5 — schema-valid, outside the mandate | untrusted |
| 8 | Blocked. Nothing moved. | The policy engine rejects it on the mandate's own rules; zero rail calls, block written to the journal | blocked · policy gate |
| 9 | Settled on a scoped card | The valid \$12 purchase settles on a single-merchant, single-amount Rain card; the agent never sees a PAN | card · Rain |
| 10 | Verified | 96.40% measured on a holdout the vendor never saw, in 2m41s of a 5m limit | ledger |
| 11 | Reconciled | \$12.07 of \$20 spent, \$7.93 remaining; every line ties to mandate/vendor/receipt/tx | ledger |
| 12 | Credential retired | The scoped card is destroyed at close — no standing authority survives the mission | ledger |
The "untrusted vs authoritative" distinction (the two visual registers in the UI) is the product's soul: what a model or vendor said is data; what deterministic code decided and the ledger recorded is fact.
6. HOW it works — the load-bearing mechanisms¶
6.1 Evidence classes (the trust tiers)¶
Every piece of evidence is labelled: measured_production / measured_trial (we paid and
measured it) vs provider_claim (they said so). Claims can never be promoted to a
measured tier. This is the anti-poisoning defense: a vendor can't talk its way into being
trusted.
6.2 The tournament (deterministic selection)¶
Pure arithmetic on measured numbers: reject anything below the quality floor, then minimise risk-adjusted price (price folded with failure/retry cost). The LLM has no vote. The math is shown on screen with provenance — this is what makes "why this vendor?" answerable.
6.3 The policy engine (the gate)¶
A catalog of independent rules, one file each: merchant_allowlisted, within_envelope,
pool_has_funds, outside_mandate_scope, task_linked, no_recurring, card_scope_valid,
agent_authority_active, mandate_complete. Every money move passes through it first.
The gift-card attack dies here with machine-readable reasons and zero rail calls.
6.4 How injection/attack is caught (two independent layers)¶
- The buyer LLM flags untrusted content but proposes nothing on it — from a fixed
taxonomy (
provider_upsell_injection,role_change_request, etc.), ledgered before the gate. - The deterministic policy engine blocks the money — no LLM in the loop. On the live Rain path there's a third, real block: the scoped card itself declines the wrong-merchant charge at Rain's authorization.
6.5 The two payment rails¶
- x402 on Monad (machine-to-machine): cent-sized audition fees settle on-chain in ~a second, no human, no card form. Exact-scheme EIP-3009, facilitator-settled.
- Rain scoped card: the purchase runs on a single-merchant, single-amount, time-boxed virtual card. The credential lives in the rail; the agent never holds it. The system chooses the rail per transaction — this cross-rail neutrality is a core moat.
6.6 Financial correctness¶
Double-entry journals with a funding account; money moves are balanced legs enforced by database triggers; a hash-chained event ledger makes the whole history tamper-evident; idempotency keys on every payment transition mean a retry can never double-spend.
6.7 The agents and their evals¶
Five LLM roles (mandate_compiler, provider_scout, buyer, outcome_verifier, narrator), each a pinned, versioned prompt. A prompt can't go live until it clears a gate: 100% injection-resistance, 100% schema-validity, 100% instruction-hierarchy, no-math, and determinism 5/5 — run against the real model. This is measured safety, not asserted.
7. The architecture principles (why the code looks the way it does)¶
- Clean architecture + DDD + SOLID at every granularity: a domain layer with zero third-party dependencies, application use cases, and infrastructure adapters as independent siblings — enforced by 7 import-linter contracts.
- Evidence-first, fail-closed: nothing is shown or acted on unless it's backed by a real ledger event; on any uncertainty the system refuses rather than guesses.
- Deterministic money: no LLM on any authorization or settlement path; money values are bound to a trusted catalog, never to model output.
- Observability non-negotiable: OpenTelemetry traces + Langfuse + a hash-chained ledger; every claim in the UI drills down to its source.
- Consumer-driven ports: adapters (Rain mock vs live, x402 facilitator ladder) are swappable behind narrow interfaces — which is exactly why "mock vs live" is a flag.
8. What's genuinely defensible (the moat, honestly)¶
The durable asset is not the audition mechanism or the card scoping — it's the verification engine and the evidence dataset it produces, plus the cross-rail, verification-source-agnostic policy layer. Whatever verification tech wins (paid auditions today, ZK proofs or TEE attestations tomorrow, an on-chain reputation network later), the scorer weighs it by trust class and the policy engine authorizes the money. That aggregator position compounds: every audition is proprietary data on which vendors lie, and the cross-mission evidence-reuse path (already built) is the bridge from "audition every time" to "own the reputation layer."
9. Honest current state (so nothing on stage is a surprise)¶
- Live now: the 5 LLM agents (real gpt-4o-mini, eval-gated), x402/Monad settlement (real USDC, real tx hashes), the full mission flow, the attack defense, the rebuilt evidence-first UI.
- Rain: the scoped-card enforcement is proven live against the real sandbox (a real wrong-merchant decline); full-live-mission hardening is in progress so the whole mission can run on real Rain end-to-end.
- Known and documented: a live-Rain hardening backlog; the sandbox's own limits (unpublished card-creation velocity, auto-cancel-after-first-use); an adjacent treasury capability proven but kept out of product scope.
The discipline to know and document these — rather than paper over them — is itself part of the product's story.