Superintelligence Budget Categories for CFOs: What to Plan For

A superintelligence budget is best planned as a set of recurring cost categories, not as one number. For a company, the categories cover the models an agent calls, the memory that holds company knowledge, the integrations and permissions that let it act, the evaluation and oversight that show it still works, and the staff time that approves and reviews changes. A CFO can map these five categories now and ask every provider to quote in the same units, without relying on any vendor's published price claims.

Key takeaways

• Plan the budget in five categories: models, memory and retrieval, integrations and permissions, evaluation and oversight, and staff time.
• The costs most often missed are recurring: connector upkeep, evaluation runs, permission reviews and incident response.
• Track cost per completed task, not only cost per token or per seat, so growth in use stays readable.
• Give each category an owner and a success criterion before any money is committed.
• Request every quote in the same units and assumptions, so no provider's claims set your plan.

Why a company intelligence layer needs its own budget categories

A company intelligence layer is the working set of models, memory, tools, permissions and monitoring that lets AI agents act on real company work. Its cost does not behave like a software licence. It moves with task volume, with the number of connected systems, with how often policies and documents change, and with how much human review the business requires. A single annual figure hides those movements and makes it hard to see which decision caused a change in spend.

Categories help in two ways. Finance can see the cost drivers, and operations can see who controls each driver. If you have not yet drawn the layers of your stack, a one-page architecture map is a practical starting point, because each budget category corresponds to one layer. Once the layers are named, the budget becomes a conversation about specific decisions rather than a general worry about AI spending.

What to plan for in the model category

Model cost is usage cost. It depends on how much text the agent reads and writes, how many tasks it runs, and how often it retries or escalates to a larger model. Three design choices shape it: which tasks go to which model, how much context is sent with each call, and whether simple requests are routed to smaller models. Some providers offer prompt caching that can reduce repeated context costs, but availability and terms differ, so build the estimate from your own traffic rather than from a generic example.

Before approving this category, confirm the following:

• Expected task volume for each workflow, sized from current work rather than from ambition.
• Average context size per task, and how that size grows as the memory store grows.
• Retry and fallback rates measured during a pilot, not assumed in the plan.
• Routing rules that state which tasks may use a smaller model and who approves a change.
• Contract terms covering model deprecations, pricing changes you cannot control, and where processing takes place.

Memory and retrieval: the cost of keeping knowledge usable

Memory is what lets an agent use company knowledge without retraining a model for every new policy. In practice it includes document storage, indexing, embedding generation, scheduled refresh jobs, and retention rules that decide what is kept and for how long. AWS's prescriptive guidance on comparing retrieval with fine-tuning is a useful reference, because it frames the trade-off between keeping knowledge outside the model and adjusting the model itself. Many companies find that the recurring work of maintaining retrieved knowledge is larger than any one-time model adjustment.

The recurring lines to budget are refresh cycles, deletion requests, and the time someone spends confirming that retrieved sources are still current. Ask who decides when a document is retired, how quickly the memory store reflects that decision, and what evidence shows it happened. Those answers determine both cost and risk.

Integrations and permissions: the costs that follow each connected system

Every connected system, whether a CRM, a shared drive, a ticketing tool or a payments provider, carries a build cost and a maintenance cost. APIs change, tokens expire, webhooks fail and vendors retire endpoints. Permissions must be scoped by tool and by action, with explicit approval for anything that writes records, sends external messages or moves money. OWASP's authorization guidance is a useful reference when you decide what an agent may do without a person in the loop.

Budget lines to request:

• Initial connector build, including scoped credentials and a test environment.
• Connector upkeep: version changes, credential rotation and handling of failed deliveries.
• Permission review on a fixed cadence, with evidence kept for each tool.
• Approval workflow: who approves external messages, refunds or record changes, and within what time.

Evaluation and oversight: the category most budgets miss

Evaluation is the set of repeatable tests that show whether the agent still does its job after a model update, a new document or a new tool. Oversight is the monitoring, logging, incident response and human sampling that makes failures visible when they happen. Both are recurring, and both are often left out of first estimates because they feel like quality work rather than cost. They are cost. Build the test set, run it after every change, review a sample of outputs each period and respond to incidents within an agreed window.

Traceability is what makes this category affordable to operate. OpenTelemetry's semantic conventions for generative AI describe how spans and usage attributes can be recorded, which lets a team connect one task to its model calls, tool calls and cost. The FinOps Foundation's guidance on unit economics suggests tying spend to a business output, such as a closed case or a completed order, so that growth in usage can be judged against what the company gained.

A step-by-step plan for your budget map

Illustrative scenario: a regional distributor wants an agent that answers internal questions about delivery terms and drafts replies for the sales team. Before any build, the finance lead asks for a budget. The operations lead names an owner for each category, and the pilot is limited to read access to two systems. At the end of the pilot, the team compares the cost of each answered request with the time it saved and decides whether write access is worth the added oversight.

Use the same sequence for your own map:

• Map each layer of your stack to one of the five categories and name one owner for each.
• List the drivers in each category: task volume, connected systems, how often data changes and which actions need approval.
• Mark each cost as one-time (setup) or recurring (usage, upkeep, reviews and evaluations).
• Define one success criterion per workflow and the unit of output it is measured against.
• Ask every vendor and partner to quote in the same units and state the same volume and review assumptions.
• Set a budget review date and a trigger for reopening it, such as a new model, a new connected system or a change in data rules.

The funding decision itself, including the order in which steps should be approved, is laid out in a step-by-step readiness budget framework.

How Be Human handles these categories

Be Human designs, implements and operates the intelligence layer for a company, so these categories are not left for the client to assemble from separate parts. A first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion, which gives each category a concrete scope from the start. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so each category appears as a named line of work rather than a surprise. Before committing to a longer scope, check that the written agreement names these categories and their owners, and use a quarterly permission review as the reference for the evidence that should exist each period.

If you are not yet sure which of these categories will matter most in your company, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

How do I explain the budget to a board that expects one number? Present the five categories with the pilot's measured drivers and a clear trigger for reopening the plan. Board members usually need to know what changes the spend and who controls it, not every line item. Show which costs are one-time and which recur, and name the owner of each category.

Which category should I measure first? Start with model usage and evaluation time during the pilot, because they show how the agent behaves under real work. Track cost per completed task from the first day, using the same unit each time. Memory and integration costs become clearer once the agent has a defined scope and a stable set of connected systems.

Does choosing a cheaper model solve the budget? Not by itself. Routing easier tasks to smaller models can lower usage cost, but it can also increase evaluation and review work if quality drops. Keep prompts, memory and tool definitions portable so a model change does not force a rebuild, and check every change against the same tests.

Who should own the budget? Finance should own the categories and the reporting, while each operational owner controls the drivers in their area. Clear ownership prevents a single team from silently absorbing oversight cost. The guide on who pays for an AI agent covers the central versus departmental question in more depth.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.