Hardcoded budget check vs a real spend firewall
Every developer's first instinct: an `if amount > 500` guard. It works until the agent retries 40 times in one minute, splits a purchase across calls, or hits a vendor you didn't block. Here's what a single-line check actually misses.
What the hardcoded check catches (and what it doesn't)
A per-transaction limit — say, blocking anything over $500 — catches exactly ONE case: a single large purchase. It doesn't prevent any of the following:
| Scenario | Hardcoded `if` | sipi.bot |
|---|---|---|
| Single purchase over $500 | Caught ✓ | Caught ✓ |
| 40 small purchases ($40 each) in a retry loop | Missed — $1,600 charged | Blocked — velocity rule stops at 11th |
| Multiple agents sharing a budget, cumulative $2,100 over a day | Missed — per-tx limit sees only $250 each | Blocked — daily total rule fires at $2,000 |
| Purchase from an unknown foreign vendor ($200) | Missed — under per-tx limit | Blocked — merchant blocklist or allowlist |
| Large compute spend at 3am local time | Missed — amount is fine, time is not | Blocked or flagged — time-window rule |
| Spend of $350 — legitimate but large enough to need a second pair of eyes | Missed — goes through automatically | Flagged for human review |
The real cost: you're on call forever
A hardcoded check puts the burden on you to monitor, tune, and enforce limits across every agent, every merchant, and every time zone. sipi.bot centralizes the rules once, enforces them on every call, and gives you a tamper-evident audit log of exactly what was allowed and why. You stop being a firewall operator and start being the person who reads one approval notification in the morning.
When a hardcoded check is enough
If you have one agent, one merchant, 9-to-5 hours, and no risk of retry loops, a hardcoded check works fine. The moment you have any of: multiple agents, a vendor allowlist, cumulative caps, or 24-hour operation, you've already rebuilt sipi.bot — just without the test suite, the audit trail, and the 53-scenario eval gym.
Frequently asked
Why not just set a spending limit on the credit card?
Card limits fire after the charge and block ALL spending, including legitimate purchases. sipi.bot decides before the spend, applies rules per merchant and category, and flags (instead of blocking) transactions that only need a human look.
Can I combine a hardcoded check with sipi.bot?
Yes. Many teams use a per-tx limit in their tool code for the obvious case and sipi.bot for the compound cases — daily totals, velocity, merchant rules, time windows. They complement each other; sipi.bot catches what the hardcoded guard misses.
How fast is the sipi.bot decision?
Under 5 millseconds on the hosted endpoint. The check is a single HTTP call your agent makes before the spend; it doesn't slow down the purchase path.