AI Cafe Napkin Orders and What Runtime Limits Can Do

A purchasing agent deployed at a cafe in Sweden accumulated 6,000 napkins, while bread deliveries sometimes lapsed when the system missed daily bakery deadlines. On May 11, 2026, the Associated Press reported on the experimental cafe, where an AI manager oversaw inventory and placed supplier orders.

Here is how runtime guards contain subsequent calls, where per-order overshoot can still occur, and what runtime budget checks do not solve.

Open full-size image (opens in new tab)

What happened in the ordering loop

Autonomous purchasing workflows highlight the practical need for proposed safeguards, including category boundaries, daily spend limits, quantity checks, and manual review thresholds.

In reporting from the Associated Press, Andon Labs staff member Hanna Petersson described the ordering issues as likely caused by a limited context window forgetting prior orders. The account noted that much of the cafe's depleted cash went toward one-time setup costs rather than napkins alone. The dispatch summarized basic operational instructions in paraphrase, but did not disclose a verbatim prompt, unit-cost incentives, or upstream warning errors.

Proposed checks for autonomous loops

• Cumulative spend ceilings that inspect recorded usage on the agent process, recognizing that an incurred order can cross a ceiling before consumption is recorded and the application must honor raised exceptions.
• Category boundaries to restrict repetitive item purchases.
• Anomaly triggers for repeated orders within the same time window.
• Spend velocity checks and manual review thresholds before order execution.

Runtime guards can halt future calls once recorded usage exceeds configured ceilings, but they do not alter prior decisions or undo placed orders.

Containing future calls at runtime

This is AgentGuard, the runtime budget library I maintain. The shape is the point, not the brand. Any equivalent works.

from agentguard import BudgetGuard, RateLimitGuard

daily = BudgetGuard(max_cost_usd=200.00, warn_at_pct=0.8, on_warning=alert_slack)
by_category = {
    "napkins": BudgetGuard(max_cost_usd=20.00),
    "paper_goods": BudgetGuard(max_cost_usd=40.00),
}
rate = RateLimitGuard(max_calls_per_minute=10)

def place_order(category, sku, usd):
    daily.check()
    by_category[category].check()
    rate.check()
    supplier.order(sku)
    daily.consume(calls=1, cost_usd=usd)
    by_category[category].consume(calls=1, cost_usd=usd)

Here is how each component behaves:

• daily = BudgetGuard(...) uses daily.check() to inspect cumulative recorded usage before the loop executes another call. If an order cost is unknown before dispatch, that call can overrun the remaining allocation before logging occurs. Once recorded usage reaches or exceeds the ceiling, check() raises BudgetExceeded.
• by_category["napkins"] provides later-order containment rather than a pre-authorized purchase amount gate. Calling consume after an order completes records the cost and raises BudgetExceeded if the limit has been breached. Because the purchase executes before consume runs, a single order can overshoot the allocation. Blocking that overshoot requires a separate pre-authorization gate, which this code does not implement.
• RateLimitGuard(max_calls_per_minute=10) limits call frequency to mitigate rapid retries.
• The guards raise exceptions that the application must honor. Catching BudgetExceeded and continuing leaves the loop uncontained.
• on_warning=alert_slack triggers a callback only if recorded usage crosses the warning threshold without breaching a limit. A single call that breaches the budget raises before warning checks run, so there is no guaranteed callback or early notice.

The guards track state in memory for the life of the process. For limits that persist across restarts, BudgetGuard accepts external storage and time windows.

What this does not solve

Runtime budget rails operate at the application layer. Several boundaries remain outside their scope:

• Selection and ordering logic. The wrapper does not fix model reasoning or item selection. Budget caps halt future recorded calls, but they do not correct flawed decisions.
• Irreversible external actions. Supplier orders cannot be recalled once dispatched. The wrapper halts future calls after costs are recorded, but cannot undo placed orders. Human review on orders above a set threshold requires a separate pre-authorization workflow.
• Security and environment boundaries. These guards are not compromised-code containment, sandboxing, credential protection, or hard invoice caps. Timeouts are cooperative, and the library does not perform Copilot, Claude Code, or Cursor subscription interception.
• Cost estimation limits. Unknown model estimates return zero with a warning, not free usage.

Structuring external action loops

When an agent loop interacts with APIs that incur financial charges or mutate external state, apply defensive limits directly to the dispatch path. Define category ceilings, track cumulative spend, and require human review for orders above defined thresholds.

Instrument and test call paths with guards before deploying loops to production environments.

Incident tracking

The agent47 repository maintains an incident log for autonomous workflows. The Sweden cafe incident highlights operational risks when autonomous loops run without proposed safeguards like category limits, recorded spend checks, or tracking recent order history.

AgentGuard provides a runtime spend tracking layer. It will not rewrite prompt logic, but it halts subsequent calls once recorded usage meets your configured ceiling.

Related: Meta token usage and agent budget control | OpenAI's guardrails don't control costs

Accompanying prompt

What the prompt does: Audits an agent ordering loop to propose multi-tiered budget guards and rate limits across spending categories. Copy/paste this prompt:

Copy-ready prompt

Paste the exact block into your coding agent.

No article chrome, no footnotes, no formatting drift.

Copy promptSelect text

Role: Systems Architect specializing in autonomous agent guardrails. Context: An automated purchasing agent executes API orders with no spend envelope, category limits, or loop throttling. Task: 1. Review the supplied agent order loop to locate external purchase dispatch points and parameter inputs. 2. Propose code changes to insert BudgetGuard checks for daily spend and individual item categories before each order call. 3. Attach RateLimitGuard to throttle call frequency and record actual incurred costs in consume calls immediately after each order. 4. Design tests verifying that exceptions halt execution when caps are reached. Output: Review notes, proposed modifications for tiered budget and rate guards, and test design verifying that exceptions halt execution when caps are reached. Constraints: Use supplied material only. No execution, credentials, spend or network.

17 lines/886 chars

Ready

This prompt and every other one we publish live in the free prompt library.

Copy the block above.

Get AgentGuard