Inspiration
A cafe with ten SKUs reorders every week. Get it wrong and you either stock out on a Friday or tie up cash you needed for rent. Every tool I found helps you decide what to buy, then hands the payment back to a human. PayPal's own framing for this hackathon is different: what happens when AI is actually behind the wheel of money movement? So I built the version where the agent pays, and made the boundary the interesting part rather than the button.
What it does
The merchant sets two numbers once: a budget for the week and a standing spend limit. Then one click. The agent reads the inventory CSV, prices the supplier catalog, computes a gap per SKU (daily_sales * (lead_time + safety_days) - on_hand), allocates the budget by urgency, and pays the supplier through PayPal Orders v2 - inside the limit, with no approval screen and no human click on the payment.
When a purchase would cross the limit, the server refuses it, keeps the draft editable, and asks for a one-off approval scoped to that exact total. The agent proposes; a person decides.
It also prices the trade-off. Every draft carries next_unlock: the single next purchase worth making and its exact cost ("+$69.60 buys four more cases of cold brew"). That number is produced by re-running the whole allocation at the higher budget, and a test fails if the quoted delta does not actually buy the thing.
How we built it
- Python / FastAPI, SQLite for drafts, orders and an append-only audit log.
- PayPal Orders v2 REST on the sandbox. With a payment source on file, PayPal settles inside the create call and returns
COMPLETEDplus a capture id; the alternative flow returns acheckoutnow?token=...approval link and captures after the payer approves. Both are implemented. - LLM function calling (any OpenAI-compatible endpoint, with a two-provider chain so a free tier cannot take the demo offline) chooses which tools to call and explains the trade-off. It never computes a dollar amount: the arithmetic is a pure function that can be re-run and audited.
- AG Grid Community for the single-screen review table: editable quantities, live line totals, budget headroom.
Two design rules carried everything else: the model cannot widen its own authority (the budget is not a tool parameter, the payment tool is not in the schema it sees), and authorisation is not a UI state (the standing limit is stored server-side and re-checked against the draft version that is actually paid).
Challenges we ran into
The first real sandbox payment failed with 422 UNPROCESSABLE_ENTITY / ORDER_NOT_APPROVED: PayPal will not let a merchant capture an order the payer never approved. That forced the question this project is really about - which authorisation replaces "the payer clicked approve" when an agent is paying? The answer became a server-side standing limit plus a scoped human token for exceptions.
The second surprise: given a budget_usd parameter in the tool schema, the model simply filled in its own number. The first live run produced a $1,000,000 budget and a $5,684 order. Removing the parameter from the schema and keeping the ceiling in server state is what made the demo trustworthy.
Accomplishments that we're proud of
- Two real sandbox captures that can be checked against PayPal itself:
6G4474502P272802R(589.40 USD, settled with no human involved) and14A20069V5594282Y(659.00 USD, human-approved after the limit refused it).python -m scripts.audit_evidencere-asks PayPal and fails loudly on any mismatch. - 26 boundary tests that run offline with no credentials: over-budget, price drift, concurrent approval, lost-write reconciliation, and a model that cannot set its own budget.
- A demo video under 70 seconds where every claim on screen is a number the app produced.
What we learned
That the hard part of agentic commerce is not the agent. It is deciding, in code, which parts of a payment must never be probabilistic - the arithmetic and the authority - and then making the rest as autonomous as possible. Also that a free LLM tier is a real single point of failure, which is why the provider chain exists.
What's next for Restock Agent
Multiple suppliers and currencies, a real catalog behind the supplier JSON, and a webhook listener so a payment confirmed in PayPal updates the ledger without polling. The standing limit is per payment today; a cumulative weekly cap is the next thing a merchant would ask for.
