Inspiration AI agents can already plan a week of work and decide who should do what. What they cannot do is pay people safely. PayPal's agent tools serve the buying side: none of the toolkit's 43 tools sends money to a person. Meanwhile a creator running a studio with an AI producer has real questions before any agent touches their money. Is it allowed to spend this, at this rate, to this person? Was the work done to spec? Is the payee cleared? If something goes wrong, who can prove what happened? We wanted the answer to be "the agent proposes and plain code decides", with proof.
What it does A creator (Maya) signs a labor mandate: a rate card, a weekly cap, a payee list and an approval threshold. From there:
An ops agent (Gemini) turns her goal into tasks for her contractors. It sees rate lines and payees, never a dollar amount. Contractors deliver, and a separate verifier agent (Gemini) checks each delivery against its spec in a fresh context with no tools. Code measures aspect ratio and duration, and a delivery passes only if the measurements and the model agree. A policy engine, plain code with no model in it, runs nine ordered checks (signed mandate, not revoked, payee on the list, sanctions screening, tax form, verifier verdict, rate card, weekly cap, approval) and fails closed. It is the only code that can call PayPal Payouts. Over the approval threshold, the creator signs that exact decision; the approval expires in 15 minutes. The engine sends a PayPal Payouts batch. Each batch id is derived from the approved decisions, so a retry can never pay anyone twice. PayPal's webhooks, verified with PayPal's own API, confirm each payout. Every step becomes a signed, hash-chained receipt, folded into Merkle checkpoints co-signed with Ed25519 and ML-DSA-65 (post-quantum). pnpm verify checks a ledger offline, and editing one payment breaks it at exactly that receipt. Every checkpoint is also copied into this public repository (anchors/, written by a scheduled GitHub Action), so rewriting history on the server shows up as a mismatch. Money in comes through PayPal Invoicing: the creator invoices a brand (the demo deal is Nova Audio, $500), PayPal holds the funds, and HandOff records what PayPal reports as a signed income receipt. Brand income and contractor payouts then sit side by side on the dashboard.
An explainer agent writes a plain-language summary of the week (who was paid, what was blocked and why, what waits for approval, and anything unusual), display-only and cached, with a plain-code fallback if the model is unavailable.
Other agents can use HandOff through a propose-only MCP server: they can read the rate card, propose work, follow tasks and verify the ledger. There is no payout tool, and no tool accepts an amount.
The /ledger page is built with AG Studio: spend against the cap, 1099 running totals per payee, a chain of receipts with a live Verify button, and a read-only AI Auditor that explains any decision.
How we built it TypeScript monorepo on Node 22: trust (receipts, chains, Merkle checkpoints, envelope encryption), policy (mandate, decide(), approvals, pay-run executor), paypal (sandbox-only client), db (Postgres with append-only triggers; embedded PGlite for tests), agents, engine, mcp, and a Next.js 16 web app. Hard boundaries enforced in code: only one file may import the Payouts client, enforced by a lint rule and an architecture test; amounts come only from the signed rate card, in integer cents; agent output is validated against strict schemas and a response containing an amount is rejected. Hosting: Render. A Blueprint creates the web service, a Postgres database and a Render Workflows service that runs planning, one verification per delivery in parallel, the policy decision and settlement as separate retried tasks. AG Studio ledger: custom widgets (a receipt chain, 1099 meters), a theme tied to the site's light and dark palettes, and an agent built on the Studio Agent Framework that delegates to Studio's built-in agents. A small server bridge answers Studio's model turns with Gemini under per-minute, per-visitor and daily caps. Challenges we ran into A verifier that was too kind. Our first verifier prompt let two bad deliveries pass: a "wrong file, please ignore" note and a watermarked draft. We rewrote it so admissions against a delivery count and claims for it never do. The current version had no false passes across three runs of a 20-case suite. Free-tier AI limits. Gemini's free quota ran out mid-demo more than once. Every agent has a fallback (a scripted plan, measurement-only verification), and the Studio assistant is paced, capped, and degrades to a clear message while the dashboards keep working. Structured output. Gemini rejected complex JSON schemas, so the limits moved from the schema into validation code that runs on the response. Proving a negative. "The agent can't pay" is only credible if it is tested. We wrote injection evals that assume a compromised model that obeys everything, and an architecture test that fails the build if anything else can reach Payouts. A leaked sandbox secret. A credential reached GitHub through an example file early on. We caught it, had the app deleted, rewrote history, added a CI check that fails on tracked secret files, and now stage files by name. Accomplishments we're proud of Real PayPal sandbox payouts and invoices, confirmed by PayPal's own signed webhooks, end to end on the live site. 10 of 10 prompt-injection attacks blocked against a model that obeys every injected instruction. A 26-payout small-business run (28 tasks, 8 payees, 10 rate lines, amounts from $15 to $210) sent as one PayPal batch in about 30 seconds, every payout confirmed, one failed delivery blocked, one approval declined, and an injected "$5,000" note ignored. 141 receipts verified offline. Verifier accuracy: all 58 completed cases correct and no bad work passed, across three runs on Gemini 3.5 Flash-Lite. Two cases hit the free quota and did not complete. 202 automated tests, a CI pipeline that also checks the demo ledger verifies and that tampering is caught, and a live MCP gate (9 of 9 checks) against the deployed site. What we learned The valuable boundary is not "smart agent versus dumb agent" but "who is allowed to move money". Giving the model no path to money, and giving the code no discretion about amounts, made the system easier to reason about than any amount of prompt care. Receipts that can be verified without trusting our server turned out to be a better answer to "can I trust this?" than a dashboard.
What's next Brand income and the weekly cap: income is recorded and shown, but it does not raise the weekly cap. The cap is the creator's signed limit, and tying it to income is a policy decision we left to the creator. Contractor-facing view of their own receipts and 1099 totals. Stronger payee identity checks, and real (not demo) screening lists. An RFC 3161 trusted timestamp on each checkpoint. Checkpoints are already copied to a public git repository on a schedule, but git commit times are set by the committer. Zero-knowledge "payee is cleared" attestations in place of the signed ones we use today.
Built With
- agstudioaggrid
- claudecode
- ed25519
- googlegemini
- mcp
- ml-dsa-65
- next.js
- node.js
- paypal
- paypaloauth2.0
- paypalpayoutapi
- paypalwebhooks
- pglite
- postgresql
- postgressql
- react
- render
- typescript
- vercelaisdk
- vitest
- zod
