A budget policy for AI agents serves one purpose: when a configured limit is reached, the system stops new work from starting — not just records that the limit was crossed. A policy defines a spending cap for a scope (an agent, workflow, team, or the whole organization), a time period, and a set of threshold actions that trigger automatically when that cap is approached or breached.

Without this infrastructure, cost overruns follow a familiar pattern: someone sets up monitoring, gets alerted, then scrambles to manually intervene. By that point, another thousand tokens have been consumed. A real budget enforcement system reserves cost before a task runs, not after.

This post is a feature walkthrough of how budget policies work in Praesidia specifically — scopes, periods, threshold actions, and how caps are enforced when work is dispatched. Budget policies, on the Team and Enterprise plans, can pause or block new agent tasks once spend reaches a threshold you set, and refuse a model call through the gateway that would exceed an agent's or the organization's budget; no budget is checked on an MCP tool call, and the Developer plan has none. For the complete vendor-neutral guide to setting agent budgets, see How to Set Budgets for AI Agents; for the broader discipline, see the AI FinOps guide.

Why AI Agents Need Different Budget Controls

Traditional SaaS billing controls are reactive. A spend cap in a cloud console typically means you get a notification at 80%, and then you get an invoice for whatever ran in the meantime. That model worked when compute costs were predictable and humans initiated every action.

Agentic systems break that model. An autonomous agent can initiate thousands of LLM calls in the time it takes a human to respond to an alert. A misconfigured loop, an unexpectedly large context window, or a prompt that triggers an expensive reasoning path can turn a minor configuration error into a significant cost event before any human has a chance to intervene. Threat Model: Runaway Agent Spend walks through the specific failure modes in detail.

The control you need is proactive, not reactive: reserve the estimated cost before the task starts, and block the task if that reservation would breach a configured threshold.

The Scope and Period Model

A useful budget policy has two dimensions: what it covers (scope) and the time window it resets over (period).

Scope lets you apply caps at different levels of granularity:

  • Organization: a ceiling on total spend across everything the org runs
  • Team: useful when different departments have separate AI budgets and you need to honor those boundaries without constant manual audits
  • Workflow: cap the total spend a single workflow definition is allowed to consume, preventing one automated pipeline from monopolizing the budget
  • Agent: fine-grained control for individual agents, which matters most for high-cost research or code-generation agents

Period defines when the counter resets. Daily periods work well for rate-limiting high-frequency workflows. Monthly periods map to billing cycles and team budget allocations. Total (non-resetting) caps are useful for project-scoped deployments where you have a fixed budget for a defined piece of work and do not want it exceeded under any circumstance.

Threshold Actions: Alert, Throttle, Pause, Block

The power of a budget policy comes from the actions that trigger when thresholds are crossed. Configuring a single threshold at 100% that blocks all further spend is blunt. The more useful pattern is a graduated response with multiple thresholds.

Alert sends a notification to the configured recipients (email, Slack, or in-app) when spend reaches a percentage of the cap. This is the warning shot — the budget is not yet exhausted but the current trajectory will exhaust it before the period ends.

Throttle slows dispatch rather than stopping it entirely. This is appropriate when you want to continue running tasks but reduce the rate at which they consume budget. It buys time for a human to review without a hard cutoff.

Pause refuses new task dispatch that the policy covers once its threshold is crossed, the same way Block does. When the cap is later raised or the period resets, the pause lifts and workflow runs that paused on the budget can resume automatically.

Block is the hard cap. Once a Block threshold is crossed, any new task dispatch that would be covered by this policy is refused. The task does not run. This is the enforcement primitive that separates a real budget cap from an advisory limit. Neither Pause nor Block stops a task that is already running.

Dispatch is not the only check. A model call through Praesidia's gateway is refused when it would exceed an agent's or the organization's budget. No budget is checked on an MCP tool call; an agent's connection to an MCP server has its own per-hour caps on a tool's calls.

A well-designed policy might set Alert at 70%, Throttle at 85%, and Block at 100%. That graduated response gives operators time to react before the hard stop, without requiring constant manual babysitting.

Reservation Accounting: Why It Matters

The mechanism that makes hard caps reliable is pre-task reservation. Before a task is dispatched, the enforcement layer estimates the cost that task is likely to incur and reserves that amount against every applicable policy. If the reservation would cause any policy to breach its threshold, the task is blocked before it starts.

This is meaningfully different from post-hoc accounting. If you only count spend after completion, a burst of parallel tasks can all start within the same accounting window, each individually appearing within budget, before collectively exceeding it. Reservation closes that race condition by treating the estimated cost as committed at dispatch time.

On task completion, the reserved amount is released and replaced by the actual spend. If the actual spend was lower than the estimate, the surplus is returned to available budget. If it was higher, the overage is recorded against the policy.

Managing the Policy Lifecycle

Budgets need to be adjustable. When business circumstances change — a campaign runs longer than expected, a new product line launches, quarterly allocations arrive — operators need to raise caps and resume blocked or paused work without rebuilding from scratch.

Raising a budget cap is an intentional action that clears the armed enforcement state. Workflows that were auto-paused because a threshold was crossed can resume automatically once the cap is raised. This makes budget management a controlled conversation between operators and the system rather than a one-way door.

Period resets work similarly. At the end of a daily or monthly period, spend counters reset and enforcement state is cleared. Explicit manual resets are also available when you need to clear a period mid-cycle — for example, after an anomalous task run that you do not want to count against the team's normal allocation.

Common questions

Does blocking a task affect tasks already running?

No. Pause and Block both prevent new tasks from being dispatched, and neither terminates tasks that are already executing. To stop an agent from taking on more work regardless of budget, use the agent suspension controls separately.

What happens when multiple policies apply to the same task?

A task can be subject to multiple policies simultaneously — for example, an agent-level policy and an organization-level policy. The enforcement layer evaluates all applicable policies, and the most restrictive outcome wins. If any policy would block dispatch, the task is blocked. This means you can set a conservative org-wide cap as a backstop while giving individual agents or teams more granular, higher limits that stay within the org ceiling.

How accurate are cost reservations?

Reservations are based on estimated cost at dispatch time, which depends on the information available before the task runs — the model configuration, the expected input size, and any known parameters. Actual costs may differ from estimates, particularly for tasks with variable output lengths or tool calls that trigger secondary model interactions. The reconciliation process updates committed spend after each task completes, keeping policy counters accurate over time even when individual reservations are imprecise.

Connecting Budget Control to the Broader FinOps Loop

Budget policies work best as part of a broader visibility and attribution practice. You need to know what is being spent before you can set sensible caps, and you need attribution data — by agent, by workflow, by team — to set caps at the right scope rather than relying solely on a blunt org-wide ceiling.

Praesidia pairs budget policy enforcement with its credit ledger and cost attribution, so the same system that records spend also enforces the caps. That linkage means the data you use to understand costs and the mechanism that controls them are consistent with each other.

For teams moving from ad-hoc cost monitoring to a more structured FinOps practice for AI, spend limits are usually the first concrete control to put in place. Budget policies limit the new work agents can start and the model calls they make through the gateway, which in turn allows teams to deploy agents more freely knowing there is a real limit in place. For a complementary view on how rate limits work alongside spend caps, see Budgets vs Rate Limits: Controlling Agent Consumption. For understanding cost attribution before you set caps, see Credits and Cost Monitoring for Agent Spend.