A practical guide to AI agent budget limits

Budget limits on AI agents are not one setting. They are five, and they stack. This guide walks through each level of granularity, when to use it, and how to compose them into a single policy your agent can't talk its way around.

What are AI agent budget limits?

AI agent budget limits are numeric caps that constrain how much an agent can spend, enforced before a payment tool executes. A well-designed limit answers four questions: how much per call, how much per thing, how much per time window, and how much ever. Miss any of those dimensions and the agent finds the gap.

The five levels below map to those dimensions. Most production agents need at least three of them active at once.

Why do single-number budgets fail?

A daily cap alone is the most common mistake. The reasoning goes: "The agent can spend $1,000/day, so worst case we lose $1,000." That's wrong for three reasons.

First, a single call can blow the whole budget in one transaction if no per-transaction limit exists. Second, $1,000/day across the wrong category — say, wire transfers instead of ad spend — is a different risk profile than $1,000/day across approved vendors. Third, a daily cap doesn't prevent a compromised agent from spending $1,000/day for 30 days straight before anyone notices.

Budgets need granularity. Here are the five levels.

The five levels of budget granularity

Per-tool limits

Scope a cap to a specific tool. book_flight might allow $2,000; buy_software_license might allow $200. The limit lives on the tool, not the agent, because different tools have different blast radiuses.

Use per-tool limits when an agent has access to multiple payment tools with different risk profiles. A send_wire_transfer tool should almost always carry a tight per-tool cap regardless of the agent's overall budget.

Per-transaction limits

A ceiling on any single payment, across all tools. This is the fast-stop for runaway calls. If your agent's largest legitimate action is $500, a per-transaction cap of $500 prevents the prompt-injected $50,000 transfer.

Use per-transaction limits on every agent, every time. There is no scenario where an uncapped single transaction is the right default.

Per-category limits

Caps scoped to a spending category: ads, SaaS, travel, contractors. Categories usually come from MCC codes (for card rails) or your internal taxonomy (for invoice APIs).

Use per-category limits when the same agent legitimately spends across different categories with different risk tolerances. An agent that manages both ad budgets and contractor payments should have a higher ad cap and a lower contractor cap, because contractor fraud is higher-impact.

Per-day and per-window limits

Rolling caps across a time window: per hour, per day, per week. These catch loops and slow drains. If a single transaction is $50 but the agent calls the tool 200 times in an hour, a daily cap is what stops the bleed.

Use per-window limits on every agent. Prefer at least two windows — a short one (hour) and a long one (week). The short window catches loops; the long window catches slow drains that stay under the daily number.

Per-agent lifetime limits

A hard ceiling on what an agent instance can ever spend. Useful for agents with defined scope: "This procurement agent handles the Q2 budget of $25,000."

Use per-agent lifetime caps when the agent has a finite mission. Skip them for long-running operational agents where the cap would just be an arbitrary large number.

How do you layer the five levels in code?

Layering is additive. Every transaction passes through every active level; the strictest one wins. Here is a PayGraph policy that stacks all five:

from paygraph import PolicyEngine, Policy, ToolLimit
 
policy = Policy(
    # Per-transaction: hard ceiling on any single call
    max_per_transaction_usd=500,
 
    # Per-tool: tighter caps for higher-risk tools
    tool_limits={
        "send_wire_transfer": ToolLimit(max_per_transaction_usd=100),
        "buy_ads": ToolLimit(max_per_transaction_usd=500),
        "pay_invoice": ToolLimit(max_per_transaction_usd=250),
    },
 
    # Per-category: different risk tolerances
    category_limits={
        "ads": 2000,
        "software": 500,
        "contractors": 300,
    },
 
    # Per-window: catch loops and slow drains
    hourly_cap_usd=400,
    daily_cap_usd=2000,
    weekly_cap_usd=8000,
 
    # Per-agent lifetime: finite mission scope
    lifetime_cap_usd=25000,
 
    # Everything above $250 needs a human
    require_approval_above_usd=250,
)
 
engine = PolicyEngine(policy)
 
@engine.guarded_tool(category="ads")
def buy_ads(amount_usd: float, platform: str):
    ...

When buy_ads(amount_usd=600) is called, the engine checks: per-transaction ($500 cap → reject), per-tool ($500 cap → reject), per-category (would bring daily ad spend over $2,000 → maybe reject), per-window (would push hourly over $400 → maybe reject), lifetime (fine). The first failure stops the call and writes to the audit log with the triggering rule.

Which limits should you turn on first?

If you're shipping an agent this week and can only configure two limits, pick these:

Per-transaction plus daily is the floor. Everything else is added as the agent's scope expands. For more on where these limits fit in the broader enforcement stack, see our blog index for related pieces on policy architecture.

Where to start

• GitHub: github.com/paygraph-ai/paygraph — MIT licensed, policy engine with all five limit levels built in.
• Docs: docs.paygraph.dev — full policy reference, tool-scoped limits, window configuration, and audit log schema.
• Discord: discord.gg/PPVZWSMdEm — ask the team how to tune limits for your specific agent workload.

Pick the two limits from the table above, ship them this week, and add the rest as your agent's scope grows. The worst budget policy is the one you're still planning to write.