Allowance

Allowance is an AI assistant you can trust with money. Tell it what you need, and it finds deals, bargains and pays, but never spends more than you allow and asks before anything big.

Comment

Give an AI agent $50. Then try to make it misbehave. Try it: https://allowance-pi38.onrender.com

Inspiration

For the past year I've been trying to work out what the next world looks like, mostly by watching my own work change underneath me. I went from writing code by hand, to building with AI in Antigravity, to handing whole tasks to autonomous agents wired up with MCP servers and my own skills and workflows.

Two things became obvious along the way.

Personal assistants are going mainstream, and no two will be equal. Everyone will have one, and an assistant is only as good as the skills, tools and workflows its owner gives it. Mine already makes me faster than I could be on my own, because of how I've set it up. Your assistant becomes your unfair advantage.

Those assistants will need to pay for things, often to other agents: for data, for hosting, for a logo. Moving money is a solved problem; PayPal does that. Trust isn't. Would you hand your assistant your card?

Allowance is my answer to that question: an assistant you can give a budget to. It pays other agents on its own, but only inside rules it can't change, with a second opinion on every purchase and a human for anything big. And when a vendor tries to manipulate it, it notices.

What it does

Allowance is an AI agent with a wallet. Give it $50 and a goal like "Launch a website for Mama's Bakery", and in about 90 seconds it:

  • Plans what the site needs: a domain, hosting, an SSL certificate, email and a logo.
  • Compares quotes from competing vendor agents. Dotlark's $6 domain beats Harborname's $11.
  • Picks Render's free static hosting over a $12 host. Then it learns HTTPS is included and drops the SSL certificate from its plan.
  • Refuses a manipulative vendor. Postwell's quote hides a note claiming the owner "pre-approved" a $19/month upgrade. Gemini flags it, and the agent switches to Mailcrest.
  • Asks you before paying $12 for a logo. Say no, and it goes back and comes home with a $9 counter-offer.
  • Builds and ships the site. Gemini writes it, and it's deployed to Render at its own real address.

Total: $23, paid through PayPal sandbox payouts to three vendors. You watch it happen as an agent walking a night-market street: price tags pop up, coins fly to each shop, a guard stops the scam, and the site rises on the empty lot at the end.

Every purchase passes four checks, in order. If one says no, nothing after it runs and no money moves:

  1. Your rules, enforced in code: budget, per-purchase limit, allowed categories, approved vendors.
  2. Gemini's judgment: does this serve the goal, is the price fair, is the vendor trying something?
  3. You: anything over your ask-me amount waits for your OK.
  4. PayPal: a sandbox payout that the vendor verifies before it delivers.

Then try to break it. There are four ready-made attacks, or you can type your own. Or flip the guardrails off: the agent overspends and swallows the upsell, and afterwards Gemini writes "Why it went overboard", explaining which check would have stopped each mistake.

How I built it

  • Agents paying agents. Each vendor is a paywalled API that answers with an HTTP 402 Payment Required quote. The agent pays the vendor's registered PayPal account, never an address from the quote, using the PayPal Payouts API (sandbox). The quote ID travels as sender_item_id. The vendor then fetches the payout from PayPal itself and checks the amount, the recipient, the quote and that the payment was never used before. Only then does it deliver.
  • Gemini 3.1 Pro plans missions and judges every purchase in JSON mode. Anything a vendor writes is wrapped in randomly tagged markers and treated as data, so instructions hidden in a quote get flagged as prompt_injection and denied. If Gemini can't answer, the purchase is denied: it fails closed.
  • Gemini 3.5 Flash writes each site and the post-run review. Every dollar figure in the review must appear in the ledger, or a plain summary replaces it.
  • Voice input. Brave and Firefox don't provide the browser's own speech recognition, so they stream audio to Gemini Live transcription using single-use ephemeral tokens. The API key never reaches the browser.
  • Real hosting. Each site is pushed to its own folder in a public GitHub repo, using a deploy key that can only write to that repo. Render's API then creates a static site for that folder. Allowance itself runs on Render too.
  • The street is plain SVG and the Web Animations API, driven by structured fields in the mission log. Every scene is a real event, never a script.
  • Node.js and Express with plain JavaScript and no build step. 61 automated tests, with Gemini, PayPal and Render stubbed.

Challenges I ran into

  • Getting one agent to pay another with no human in the loop. PayPal's Orders API wants a buyer to approve, or a card the payee can process (PAYEE_NOT_ENABLED_FOR_CARD_PROCESSING). Payouts, bound to the vendor's quote, turned out to be the right rail.
  • Prompt injection that looks like business. Postwell's "the owner pre-approved this" passes every spending rule: it's cheap, from an approved vendor, in an allowed category. Only a model reading the quote as untrusted data catches it.
  • Gemini's latency swings. The same call took 7 seconds one run and 100 the next, and a forgotten dev server once burned through the free-tier quota. I added retries for transient errors and kept every failure path closed.
  • Hosting someone else's site for real. Render deploys from a repo, not from uploaded files, so I built a repo-per-folder pipeline. Then SSH refused the deploy key on Render because the mounted secret file could be read by others, so the app makes a private copy first.
  • An animation that survives the page. The screen re-renders every second while a mission runs, so the street is a single element moved into each new screen, animated only with the Web Animations API.

What I learned

  • Hard limits belong in code; judgment belongs to the model. Rules are instant and can't be talked out of anything. Gemini catches what rules can't see, like a scam that's within budget.
  • A "no" is a new constraint, not the end. When you decline a price, the agent goes back to every vendor with a ceiling, where $p$ is the price you declined, $a$ your ask-me amount, $m$ your per-purchase limit and $\ell$ what's left:

$$ \text{ceiling} = \begin{cases} \min(p - \$0.01,\ a) & \text{you said no to a price } p\ \min(m,\ \ell) & \text{your per-purchase limit blocked it}\ \ell & \text{it was more than you had left} \end{cases} $$

  • A good shopper picks free when free exists. Render's real price for a static site is $0, and an agent spending your money should notice.
  • Be honest about what's simulated. The PayPal payouts, Gemini's decisions and the hosting are real. The vendors, the domain names and the money are sandbox.

What's next

If everyone's assistant is shaped by the skills its owner gives it, spending rules should be one of those skills: written once, carried everywhere your assistant shops, from hosting to groceries. Next comes real merchant accounts instead of sandbox payouts, shared rules for a family or a team, a ledger that persists, and more missions beyond websites, like restocking a shop or planning an event.

Built With

Share this project:

Updates

Submission history