You ran a successful AI-agent pilot. The workflow got faster, the sponsor wants three more departments, and finance is asking for next year’s number. Annualizing the pilot bill feels defensible, but it gives you a weak forecast precisely when the pilot succeeds.

An enterprise agent does not scale like a fixed number of software seats. Its consumption follows the work it performs, while its value can expose more work worth automating. You need a budget that can expand without becoming an open-ended commitment.

Key takeaways

• Treat the pilot budget as the cost of proving a use case, not as the baseline for an annual forecast.
• Forecast from eligible work volume, adoption, agent attempts, and cost per accepted result. Employee count alone will miss recurring processes and product-embedded usage.
• Separate committed funding from an expansion envelope, then release that envelope when each workflow meets predefined value, reliability, and control gates.
• Track cost per accepted unit of work. Raw token consumption, model calls, and time saved are incomplete measures of economic value.
• Increase autonomy and spending authority together. The agent should earn broader permissions through observed performance, not receive them merely because adoption is growing.

Your pilot budget answers the wrong long-term question

A sensible pilot deliberately limits uncertainty. It usually covers a narrow workflow, selected users, constrained permissions, close human review, and a manageable volume of work. Those conditions help you learn safely. They do not represent the operating state you are likely to fund after the pilot.

Enterprise purchasing patterns already show how much room can remain after an initial deployment. As of September 30, Anthropic counted more than 11,900 customers generating at least $100,000 in trailing annual revenue, more than 1,900 at $1 million, and approximately 250 at $10 million. More than half of the Fortune 500 had crossed the $100,000 level, yet average spending among the publicly traded companies in that qualifying group remained below one dollar for every thousand dollars of total expenses.

Broad adoption and low relative penetration can coexist. That matters because an apparently meaningful first contract may still cover one team, one workflow, or one product feature inside a very large company.

Anthropic also reported roughly 900% net revenue retention: its existing customers collectively generated about nine times as much revenue in the September quarter as they had a year earlier. Do not turn that cohort-level result into a nine-times multiplier for your forecast. It does not mean every account grew equally, and it says nothing by itself about your use case’s economics. It does show why a first-year pilot is a poor ceiling for a category whose usage expands with useful work.

When an agent works, demand can expand along several independent paths:

• More users: the same capability moves from a pilot group to the rest of a function.
• More work per user: employees delegate additional steps once they trust the initial result.
• More agent effort per task: harder assignments require retrieval, tool calls, retries, verification, or coordination with other agents.
• More workflows: the organization applies a proven pattern to adjacent processes.
• More external demand: an agent embedded in a customer-facing product consumes resources as that product grows, even if employee headcount does not.

Build three scenarios instead of one annualized number. The committed case covers the production workload you can already justify. The expansion case adds named workflows with credible owners and baselines. The constrained case shows what you will pause, route to a cheaper model, or return to human handling if unit economics or reliability deteriorate.

The governing principle is simple: approve a path to more spending, not an entitlement to it.

Forecast agent spending from work, not employee seats

Seat count can help forecast access to a chat application. It does not capture an agent that monitors a queue, processes documents overnight, runs inside a product, or takes several actions for one employee request.

For each workflow, start with this operating equation:

Expected run cost = eligible work units x adoption rate x agent attempts per work unit x average cost per attempt.

Define every term using the workflow itself:

• Eligible work unit: a support case, report section, invoice, code change, research task, campaign, or other business object the agent can actually process.
• Adoption rate: the share of eligible units routed to the agent, not the share of employees who have logged in.
• Agent attempts: the initial run plus retrieval, model calls, tool use, retries, validation, and any handoff to another agent.
• Average cost per attempt: model consumption and metered tool costs under the routing policy you plan to use in production.

Then reconcile the estimate to an accepted business result. If the agent completes 1,000 attempts but only 600 results are accepted without material rework, 1,000 is a misleading denominator. The metric finance and product should share is cost per accepted work unit.

Consumption will also follow the operating rhythm of the business. About 80% of Anthropic’s first-half 2026 revenue was consumption-based, and total customer spending fell approximately 20% in the two weeks ending January 2 compared with the two weeks ending December 19. Anthropic associated the decline with reduced holiday activity, including code freezes. In other words, the bill moved with the work.

Your model should therefore include seasonality, launch periods, month-end processing, code freezes, and other workload changes. A flat monthly average hides both capacity risk during peaks and false savings during quiet periods.

Run cost is only one budget lane. A production forecast should also make these costs visible:

• Platform licenses, minimum commitments, and fixed infrastructure.
• Workflow integration, data preparation, and ongoing maintenance.
• Evaluation suites, observability, security review, and audit retention.
• Human review, exception handling, and escalation.
• Training, process redesign, and support for affected teams.
• Model or vendor changes required when quality, latency, availability, or price no longer meets the workflow’s needs.

Use the same discipline on the value side. Separate cashable savings from capacity and from revenue or risk effects. An hour saved is not automatically an hour removed from payroll. It may instead create capacity for more cases, faster cycle time, better review, or work that was previously uneconomic. Count the same benefit in only one bucket.

Novo Nordisk, for example, reports a 90% reduction in clinical study report writing time from a system that retrieves approved material, drafts report sections, maintains connections to the underlying evidence, and keeps people responsible for review and approval. The team then extended the approach to device protocols and patient materials. Treat the 90% figure as a documented company result, not a universal benchmark. The transferable lesson is the shape of the expansion: establish value in a defined process, preserve human accountability, and then apply the reusable capability to adjacent work.

For every workflow, put six measures on the budget review: eligible volume, accepted volume, cost per accepted unit, cycle time, exception or rework rate, and the business outcome the workflow is meant to change. If you cannot connect consumption to those measures, you cannot tell productive expansion from expensive activity.

Release the budget in stages the agent must earn

A rigid annual cap can starve a successful program halfway through the year. An unrestricted consumption budget creates the opposite problem. The practical middle ground is a committed floor plus a conditional expansion envelope.

1. Prove the problem and baseline. Define the work unit, current volume, cycle time, quality level, operating cost, and accountable owner. Fund a constrained test that can show whether the agent improves that baseline.
2. Prove the production control. Run the workflow with real permissions, audit logs, exception paths, human review, and spend limits appropriate to its consequences. Release funding only if failures are detectable and recoverable.
3. Prove repeatable economics. Measure cost per accepted unit across representative workloads, including peaks and difficult cases. Do not graduate a workflow on a polished demonstration or average model response alone.
4. Fund named expansion. Move into another team or adjacent workflow only when it has its own owner, eligible-volume estimate, baseline, risk classification, and adoption plan. Similar-looking work can have different data, controls, and failure costs.

These are evidence gates, not calendar milestones. A workflow should not receive more money merely because a quarter ended. Before the first production run, set the numerical release and stop thresholds from your own baseline. At minimum, define the maximum cost per accepted unit, minimum quality or acceptance level, allowable exception rate, spend variance, and any control failure that triggers an immediate pause.

Give finance one record for each funded workflow. It should contain:

• The business owner and technical owner.
• The baseline process and the accepted unit of work.
• Expected volume, adoption, agent attempts, and seasonality.
• Fixed cost, variable run cost, human review cost, and change cost.
• The value bucket: cash, capacity, revenue, quality, or risk.
• The permission level, failure consequences, and required controls.
• The release threshold, stop threshold, and next budget decision.

This record prevents two common distortions. Product cannot describe every saved minute as financial return, and finance cannot treat every additional model call as waste. Both sides can see whether higher consumption reflects more accepted work, harder work, avoidable retries, or deteriorating performance.

Expand autonomy and spending authority together

An agent becomes more valuable as it moves from answering questions to completing work. It also becomes more consequential. Budget growth and permission growth therefore belong in the same operating review.

Use a permission ladder rather than a binary choice between a passive assistant and full autonomy:

1. Observe: the agent reads approved information and identifies or classifies work.
2. Draft: it prepares a recommendation, response, document, or action plan for a person to assess.
3. Act with approval: it prepares a specific action and executes only after an authorized person approves it.
4. Act within bounds: it executes reversible actions inside explicit data, tool, amount, audience, and frequency limits.
5. Operate by exception: it handles routine cases and escalates ambiguous, high-impact, or policy-sensitive situations.

Town began rolling back some guardrails after its users approved 95% of proposed agent actions. That is a useful signal, but not a universal autonomy threshold. The rejected 5% could contain the highest-consequence mistakes. Approval rate must be read alongside severity, reversibility, false approvals, and the reviewer’s ability to notice a subtle error.

Human approval is also not free. It adds labor cost and delay, and repetitive approvals can become ceremonial. Include that burden in cost per accepted unit. When approval adds little protection, replace it selectively with stronger preconditions, narrower permissions, automated checks, sampling, and exception review. Keep explicit approval for irreversible or high-consequence actions.

Pair every permission level with operating limits:

• Scope limits: which workflows, records, tools, audiences, and action types are allowed.
• Consumption limits: workflow-level budgets, retry limits, model-routing rules, and alerts for abnormal usage.
• Consequence limits: which financial, customer-facing, legal, security, or data-changing actions always require a person.
• Recovery controls: audit logs, reversible actions where possible, a tested pause mechanism, and a named incident owner.
• Information boundaries: what one employee’s agent may retrieve, infer, retain, or share with another employee or agent.

That last boundary becomes critical in a multiplayer agent environment. Useful collaboration requires context to move across people and systems, but convenience is not permission. Budget for identity, authorization, data lineage, logging, and policy enforcement as part of the agent product. If those capabilities arrive after adoption, the remediation cost and organizational resistance will arrive after it too.

During rollout, review the portfolio frequently enough to catch changes in adoption, retries, quality, and spend before they compound. Once a workflow is stable, shift from launch monitoring to a regular operating review. Each meeting should end with one of four explicit decisions: hold, optimize, expand, or stop.

Your next planning discussion should begin with one funded workflow, its accepted unit of work, and the evidence required to unlock the next tranche. If you cannot name those three things, keep the budget constrained. If you can, give the program room to grow when useful work – not enthusiasm – earns it.

References

• First Round – Competing with OpenAI and Meta for your inbox | Jean-Denis Greze (Town Co-founder & CEO)
• Nate Jones’s Substack – Anthropic’s existing customers collectively spent about 9x as much as a year earlier. Why your first AI pilot is a poor guide to your next budget.

---