AnchorGate

A locked gate between AI agents and your money: the agent proposes, your rules decide, and nothing pays without your rules or your yes.

Comment

What it does

Your AI agent proposes purchases. AnchorGate checks every one against rules that only you can change. Anything else waits for your yes.

AnchorGate is a locked gate between AI agents and your money. The agent can knock all it likes. Your rules open the gate, or your yes opens it. Nothing else does. It is live end to end on PayPal sandbox money: practice money, never real money, enforced in code.

Try it live (two minutes)

  1. Open https://anchorgate-five.vercel.app and sign in with the judge account: [email protected] / AnchorGate!Judge2026.
  2. Type this into the ask box on the Gate: A $10 Notion Team workspace for my notes. Within seconds the assistant files a proposal card, and the gate decides it asks you.
  3. Press Approve and pay. Seconds later the record shows the verified capture: PayPal's reference, and PayPal's signed notification stored on the record.
  4. Now type $10 ham sandwich. There is no seller in that sentence. The box names exactly what is missing, and files nothing. Every no in this app speaks in plain words.
  5. The gate comes pre-stocked with a curated history: one purchase paid, one refused, and cards waiting for your yes, so all three verdicts are on screen before you type anything. Approving them is encouraged.
  6. Visit Rules to see the monthly wall: your limit as a hard line, with what is spent, what is set aside, and what is left. Visit Record for every check that ran on every decision, the version of the rules that made it, and the PayPal proof.

Inspiration

Agentic commerce is arriving faster than trust. Agents can browse, compare, and check out, but nobody sane hands an agent their card and says "be sensible about it." The missing piece is not a smarter model. It is a doorman that cannot be talked into anything: plain code that reads your rules fresh at every check, counts money exactly once, and turns every refusal into a sentence you can understand. An anchor holds fast. A gate opens two ways only. That is the whole product.

What it does

  • The agent proposes. It cannot pay. The built-in demo agent offers items one at a time from a fixed catalog of fourteen, and you can type any purchase into the ask box in your own words. The model behind the box has exactly two tools: file a proposal, or report which of the three facts (who gets paid, the price, what it is for) is missing. No model is ever asked whether its own request should pass.
  • The gate decides with six checks in order: valid request, positive amount, right currency, allowed kind, room under your monthly limit, your approval. Three verdicts, and only three: refused (naming the rule in plain words), asks you, or paid by your rules.
  • Your rules are yours alone. Monthly limit, allowed kinds, currency. Until you set them, nothing can be approved at all: the gate fails safe. Every decision on record names the version of your rules that made it.
  • AI authorization is opt-in and boxed in. Exact items at exact prices, each auto-paid at most once a month, inside a separate auto budget that always sits under your limit. Printer paper at $22.00 pays itself; at $22.01 it comes to you showing both numbers. One switch turns everything back to asking you.
  • Money counts once, and only when PayPal says so. A capture still pending is watched until it settles or lets go. Every capture's signed webhook is verified against PayPal's certificate and stored on the record. One real October run: an $18 coffee subscription asked in the morning, approved the next day, capture verified seven seconds after the approval.

How I built it

Next.js 16, React 19, TypeScript. Postgres with Drizzle ORM on Supabase, and Supabase Auth for sign-in. Vercel AI SDK pointed at any OpenAI-compatible model for the ask box. PayPal Server SDK for orders and captures, plus webhook verification for signed proof. Vitest for 335 automated checks covering the decision engine, the money math, and the whole lifecycle. Deployed on Vercel. The PayPal adapter refuses to start against any environment that is not sandbox, so the app cannot move real money, even by accident.

The architecture rule that held everything together: model prose never touches money and never reaches the screen. The ask agent reports outcomes as fixed enum codes, and the gate composes sentences from those codes. Because the model is confined to a vocabulary, the money path is fully deterministic and fully testable, and the model's creativity stays where it belongs: in understanding what you typed.

I also kept a written canon: a constraints file where every design and product decision is logged with its date and, wherever possible, live evidence. Motion is 120, 220, or 420 milliseconds and moves only position and opacity. No reason codes on screen, only sentences. Rules fail safe. Building solo, that file was the difference between a product and a pile of features.

Challenges

The silent ask box. Early on, a missing fact or a hung model could leave the ask box saying nothing, forever. Silence is the worst failure mode a money interface has. The fix came in three parts: a hard 45-second clock on every model run, a second tool that lets the agent name which facts are missing from a fixed list, and gate-composed sentences for every outcome, including "could not reach the model." The live receipt: a $10 ham sandwich ask answered in 19 seconds, naming both missing facts, filing nothing. A later run of the same ask reported only the payee missing, and the sentence adapted word for word. The naming is computed, never canned.

The minutes-late answer. A live replay exposed an ugly wrinkle: the server answered an ask in about twenty seconds, but the sentence could take minutes to appear on screen. The cause was two innocent background timers meeting. The suggestions feed polls the server every 30 seconds, and a poll colliding with the ask's redirect navigation aborted it, again and again. The fix is coordination, not speed: while an ask is in flight, the submit button raises a flag the feed's heartbeat checks, and the heartbeat stays quiet. The receipt after the fix: submit to sentence in 7.3 seconds, with the network log showing the heartbeat silent for the whole ask. One sub-second tail window remains in theory, logged in the canon as a deliberate decision with its one-line remedy on record.

Counting money exactly once. Captures can be pending, complete, or denied, and webhooks can arrive twice. The ledger counts only verified captures as spending, derives each event's idempotency key from PayPal's own capture reference, and reconciles pending captures until they settle or let go.

Making every no speak. No codes, no shrugs, anywhere. Every refusal, every ask-you, every blocked auto-pay names its reason in plain words. That constraint is what forced the enum-outcome design above, and it is why the product reads like a person, not a log file.

What I learned

  • A persuasive narrator must never also be the cashier. Give the model a vocabulary, not authority.
  • Silence is a bug class. Every asynchronous path now ends in a sentence, and the tests pin that down.
  • In a live interface the race is rarely where you look. Two correct components, a poller and a redirect, broke a moment together; the fix was one flag.
  • A written canon with dated decisions and live receipts keeps a solo build honest. It also writes your Devpost submission for you.

What this is not

Sandbox only, enforced in code, permanently. A hackathon build that proves a pattern, not audited software. One owner per gate, one owner's rules, one owner's wall. And it is not tied to the demo agent: any agent, real or simulated, meets the same gate and the same rules. The gate does not care who knocks.

Built With

Share this project:

Updates

Submission history