I Mashed Up Two Side Projects — Here's the Chemical Reaction

I had two small side projects sitting on my laptop, built for completely different reasons. One is a flash-sale store that refuses to sell more items than it has in stock, even if a thousand people click "buy" at the same second. The other is an AI agent that goes shopping for you, but stops and asks "is this okay?" before it actually spends any money. Neither project needed the other to work. But I kept wondering what would happen if I forced them together — an AI that asks permission, pointed at a store where every second counts. So I tried it, and it turned into a small experiment with a surprisingly clear answer.

Project one: a store that never oversells

The first project is called DROPZERO. Think of a sneaker drop, or concert tickets going on sale — a fixed number of items, and way more people trying to buy than there are items to sell. The moment the timer hits zero, everyone hits "buy" at once. Most online stores handle this by locking the inventory row while one purchase finishes, which works, but under a real stampede that lock turns into a traffic jam. Some stores just don't lock at all and end up selling 12 pairs of a sneaker that only had 10 in stock — an "oversell."

DROPZERO is built on Amazon Aurora DSQL, a database designed for exactly this kind of pileup. Instead of locking rows and making everyone wait in line, it lets everyone try to buy at once and only checks for conflicts at the very last moment — right when a purchase is about to be finalized. If two people try to grab the last item, one wins, and the other gets told "sold out" instantly and cleanly, with no partial charges or duplicate orders. I load-tested this with 3,000 requests slamming into a stock of 100, and the result was always exactly 100 confirmed orders — never 101, never 99.

Project two: an AI agent that has to ask first

The second project is wallet-agent. It's an AI agent built to shop on your behalf — search for something, decide it's a good buy, and purchase it. The twist is that it's not allowed to just spend money on its own. Before every purchase, it has to stop, show you what it wants to buy and why, and wait for a human to say yes or no. I call this an approval gate, and it's the same idea as a manager having to sign off before an employee can place a big order.

This matters more than it sounds. An AI agent that can spend money without anyone checking is a little scary — it might buy the wrong thing, buy too much, or get tricked into buying something it shouldn't. An approval gate is the seatbelt for that. But seatbelts also slow you down a little, and that trade-off is exactly what I wanted to measure.

Putting them together

I gave the wallet-agent three new tools: one to check DROPZERO's current stock, one to ask a human for approval, and one to actually make the purchase once approved.

I ran it once end to end. The agent checked the stock, saw there was exactly one item left, printed an approval card explaining why it wanted to buy now ("last one, don't want to miss it"), and waited. I typed approve in another terminal. A few seconds later the agent called DROPZERO's purchase API, and the page flipped from "buy now" to "sold out." One agent, one human nod, one confirmed order. It worked exactly the way I hoped — which is usually the point where I stop trusting a demo and start trying to break it.

The experiment: what does "asking permission" actually cost?

Here's the question I actually cared about. DROPZERO is built for a world where every second matters. wallet-agent is built to pause and wait for a human. What happens when you put both of those in the same room?

I ran a small test using k6, a load-testing tool. I set DROPZERO's stock to 20 items, then sent two groups of 100 purchase attempts at it at the same time:

• Group A ("no approval"): buys the instant it decides to, no waiting
• Group B ("with approval"): waits a bit first, to stand in for the time a human takes to look at an approval card and tap yes — I tried delays of 0, 0.5, 1, 3, and 5 seconds

Both groups were fighting over the same 20 items at the same time. Here's what happened:

Approval delay	Group A success rate	Group B success rate
0 seconds	13%	7%
0.5 seconds	15%	5%
1 second	16%	4%
3 seconds	20%	0%
5 seconds	20%	0%

By the time the delay hit 3 seconds, the approval group didn't win a single item. Not one, out of 100 tries. Every item went to the group that didn't stop to ask.

The part that actually surprised me, though, wasn't the losing streak — it was this: in every single run, the total number of successful purchases matched the stock exactly. 20 items in stock, 20 confirmed orders, no matter how the two groups split them. Not once did the store oversell, even when I stacked 200 requests on top of only 20 items.

What that actually means

DROPZERO's database was never at risk of overselling, approval or no approval — that guarantee comes from the database itself, not from having a human in the loop. What the approval step actually costs you is speed, and in a first-come-first-served situation, speed is everything. Waiting a few seconds to ask "is this okay?" doesn't make the store safer. It just means you lose the race to whoever didn't stop to ask.

That's a genuinely useful thing to know if you're building anything where an AI agent might one day be allowed to spend money on your behalf. An approval gate is a great idea for stopping an agent from doing something dumb or unauthorized. It is not a way to prevent a database from overselling — that job belongs to the database, and DROPZERO already had it covered before wallet-agent ever showed up. Knowing which problem each piece actually solves matters, because "add a human in the loop" sounds like a safety upgrade for everything, and here it very clearly wasn't one for this particular problem.

Try it yourself

Both original projects and the mashup are open source:

• dsql-drop-app — DROPZERO, the zero-oversell flash-sale store
• wallet-agent — the AI shopping agent with an approval gate
• dropzero-wallet-agent — the mashup, plus the full experiment and results

If you've got two small projects sitting around that have nothing to do with each other, it might be worth forcing them into the same room. You might just learn something neither one could have taught you on its own.