Andrew Lee Miller

The check is: count today s rows for this user, and if the count is under the limit, run the call and insert a row. That works for one request at a time. If a client sends 10 requests at once, all 10 can read count = 2 before any of them insert, so all 10 pass.

On serverless, this gets worse, because an in-memory counter doesn t help. Each request may run in a different instance with its own memory.

The fixes I m weighing, all in the database:

• A unique constraint on (user, day, slot number). Each request claims the next slot, and a duplicate insert fails. It s simple, but I need to handle the retry.

• An atomic counter. One SQL statement increments a per-user-per-day counter and returns the new value, and the request is rejected if it s over the limit. There s no gap between checking and counting.

• An external store like Redis. It s fast, but it s one more service for a small stack.

We keep a human in the loop for safety. It s the standard line during demos, and on paper, it makes total sense.

But in practice, human review quickly becomes the bottleneck. If someone has to check every step or approve every small update, the speed advantage vanishes. Worse, alert fatigue sets in people stop reading traces and just start blindly clicking "Approve."

When evaluating HITL setups now, my test is simple: Can someone make a confident decision in under 3 seconds?

If reviewing takes as long as doing the task manually, the agent isn't saving time it s just turning real work into an auditing job.