How to Budget for Superintelligence Readiness Step by Step

An AI readiness budget works best when it is divided by function instead of by product: memory, tools, permissions, evaluation and oversight each get a deliberate share, sized to one real agent role. Fund the parts that stay valuable when the model underneath changes, and keep a recurring share for running the agent after launch. The steps below show how to set the split, defend it and adjust it with evidence.

Key takeaways

• Budget by function, not by product: memory, tools, permissions, evaluation and oversight each need a named share and a named owner.
• Anchor the plan to one agent role with an observable success criterion, then size each function to what that role actually needs.
• Put early effort into the parts that outlast any single model: memory, permissions and evaluation.
• Reserve a recurring share for operation, because monitoring, review and maintenance are where readiness is kept.
• Review the split on a schedule and move effort based on evidence, not enthusiasm.

What does readiness mean when you are writing a budget?

Nobody can buy superintelligence today, and a budget should not pretend otherwise. What a company can fund is the layer around the models: the company knowledge an agent can use, the systems it can reach, the limits on what it may do, the tests that show whether it works and the people who stay accountable. That layer is useful with the models available now and becomes more valuable as models improve.

A practical test for readiness is this: if a more capable model were placed into an existing agent role tomorrow, could you tell within a short review whether it did the job better and whether it stayed inside its limits? If the answer is no, the gap is rarely the model. It is a missing source of truth, an unclear permission or an absent test. Those gaps are what the budget should close. For the wider program around the money, the superintelligence readiness checklist covers the questions that sit next to the budget.

Why split the money across five functions?

Spending by product tends to follow whatever a vendor demonstrated last. Spending by function follows how agents actually fail. Each function answers a different question:

• Memory: what does the agent know about the company, where does that knowledge live, who corrects it and how is outdated material removed?
• Tools: which systems can the agent read from or act in, through which connectors, and are those connectors described clearly enough to be used correctly?
• Permissions: what is each connection allowed to do, for whom, and for how long?
• Evaluation: what set of realistic cases and checks shows whether the agent does the job, and does it still pass after a change?
• Oversight: who approves sensitive actions, who watches the agent in operation, who handles incidents and who can pause it?

Underfunding one function moves the cost somewhere less visible. Strong tools with weak permissions create exposure. Rich memory with no evaluation produces confident answers nobody can verify. Good evaluation with no oversight finds problems that nobody owns. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organizes risk work into governing, mapping, measuring and managing, which is a useful sanity check that your five shares together cover all four activities.

How do you decide which function gets the larger share?

There is no universal split, because the right weighting depends on what the agent does. Use this decision guide to tilt effort before you assign shares:

• If the agent answers questions from company documents, weight memory and evaluation more. Stale or conflicting sources are the main failure.
• If the agent acts in systems (sending, updating, scheduling, approving), weight permissions and oversight more. A wrong action costs more than a wrong sentence.
• If the work touches many systems, weight tools. Connectors need maintenance, and the agent needs clear tool descriptions to choose them well.
• If the role is new and the success criterion is vague, weight evaluation first. You cannot judge spending you cannot measure.
• If only one person understands how the agent works, weight oversight and documentation. A single champion is a continuity risk.

For permissions, borrow established security habits instead of inventing new ones. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege, deny by default and checking authorization on every request. An agent is a new kind of user, but those rules apply to it without change, and they are cheap to adopt early and expensive to retrofit.

A step-by-step plan to build the readiness budget

Work through these steps in order. The result should fit on one page that an executive sponsor can read and challenge.

• Step one: name one agent role. Describe the work, the people who rely on it and what a person does today. Resist covering several roles at once.
• Step two: write the success criterion in terms you can observe, such as drafts accepted with light edits or requests resolved without escalation. The guide on defining success criteria for an AI agent pilot shows how.
• Step three: list the memory the role needs. For each source, note the owner, how often it changes and what happens when it conflicts with another source.
• Step four: list the tools and the minimum permission each one needs. Start read-only wherever possible, and mark every action that should wait for a human approval.
• Step five: draft the evaluation set. Collect realistic past cases, including awkward ones, and define what a good result looks like for each.
• Step six: define oversight. Name the approver, the reviewer, the person who receives incident reports and the person with authority to pause the agent.
• Step seven: rate each function as heavy, moderate or light for the build phase, and write one sentence explaining why. Then set aside a recurring share for operation and name a date to revisit the ratings.

The written reasons matter more than the ratings. When circumstances change, you can see which assumption broke and adjust that function instead of renegotiating the whole budget.

What does the split look like in practice? An illustrative scenario

This is an illustrative scenario, not a real engagement. A mid-sized professional services firm wants an agent to prepare first drafts of client status summaries from project notes and a task tracker.

Memory is rated heavy. Project notes are scattered, and two versions of the summary template are in circulation. Most early effort goes into choosing one template, naming an owner for each note source and retiring duplicates. Tools are rated light: read access to the tracker and write access only to a drafts folder. Permissions are rated light in effort but strict in design, because the agent drafts and a person sends. Evaluation is moderate: a set of past summaries with notes on what the account lead would have changed. Oversight is moderate: a named account lead reviews every draft at the start, and one operations owner receives problem reports.

After a few review cycles, the evidence shows that drafts are accepted with light edits. The firm widens one permission so the agent can save drafts into the client folder, and the evaluation share shifts from building the set to maintaining it. The budget moved because evidence changed, not because someone wanted a different mix.

What should keep being funded after launch?

Readiness is not a one-time purchase. Connectors change when a vendor updates an interface. Documents go stale. People change roles and their access should change with them. Models are updated, and behavior can shift in ways a quick demo will not reveal. A recurring share of the budget is what keeps the first build from decaying, and it is almost always cheaper than rebuilding trust after a failure.

The recurring work maps back to the five functions: refreshing and pruning memory, maintaining integrations, reviewing permissions on a schedule, rerunning evaluations after any change and keeping incident handling alive. The quarterly permission review is a good example of a small, repeatable task that protects a large part of the investment.

Be Human handles this as managed operations. A first engagement defines one useful role, the memory and tools it needs, approval boundaries and an observable success criterion. Managed operations then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so each function in your budget has a continuing owner after launch and the agent stays under human control.

How do you review the split and show it worked?

Set a review date when you approve the budget, and ask for evidence per function instead of a general status report:

• Memory: examples of sources corrected, merged or retired, and the questions the agent could not answer because a source was missing.
• Tools: a list of connectors in use, any that failed and how the failure was handled.
• Permissions: the current access list compared with the last review, with each change explained.
• Evaluation: the latest results on the evaluation set, including cases that got worse after a change. The Anthropic article on [demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) is a useful reference for what to measure.
• Oversight: incidents received, how quickly each was handled and whether approvers actually used their authority.

Then move effort. If evaluation keeps catching the same memory problem, shift money to memory. If approvals are always granted without review, either tighten the process or loosen the boundary deliberately and record why. Who holds the budget also shapes these choices, and the article on who pays for the AI agent explains the trade-offs between central and departmental funding.

Take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

How large should an AI readiness budget be? There is no honest universal figure. Size it to one agent role and the five functions that role needs, then expand only when evidence shows the first role is working. A small, well-owned budget for one role teaches you more than a broad budget with no clear success criterion.

Should we hold money back until better models arrive? Waiting rarely helps, because the layer you would build now is the same layer a better model will need. Memory, permissions, evaluation and oversight carry over when the model changes, and an evaluation set is what lets you judge a newer model quickly. Fund the layer now and treat model upgrades as a controlled change.

Which function do companies underfund most often? Evaluation and oversight are the usual candidates, because they do not produce a visible feature. Their absence shows up later, as an agent that drifts or a problem nobody owns. Giving them a named share and a named person early is inexpensive protection.

Can a small team use this framework? Yes. Keep one role, one owner and a one-page plan with the five functions rated heavy, moderate or light. The framework scales down well, because its purpose is to make the trade-offs visible, not to require a large program.

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