Superintelligence Readiness Checklist for Company Leaders

A superintelligence readiness checklist tests five foundations in your company: whether your data can be trusted, whether agent memory is governed, whether permissions are narrow and reviewable, whether you can evaluate a stronger model against your own work, and whether named people own the outcome. If those hold, a more capable model becomes an upgrade you adopt on purpose. If they do not, more capability mostly means faster mistakes.

Key takeaways

• Readiness is a property of your company's foundations, not a prediction about when a particular model will arrive.
• Data needs owners, dates and a declared source of truth before a stronger model can use it well.
• Memory and permissions should be written down and narrow, so gains in capability do not widen access by accident.
• Keep a private evaluation set drawn from your real work, so you can test any new model before it touches production.
• Every agent needs a named owner, a budget for attention and a way to pause it.

What does superintelligence readiness actually mean for a company?

Nobody can tell you when, or in what form, AI systems will exceed skilled people across most knowledge work. Planning around a date is a poor use of leadership time. Planning around conditions is a better one: what must be true inside your company so that any much more capable system can be used safely and productively?

That reframing turns a vague worry into an operational question. A stronger model will read what you give it, act where you allow it and be judged by what you measure. Your data, memory, permissions, evaluations and ownership are the interfaces between your company and the model. If those interfaces are clean, the model underneath can change often without much drama.

If you want the conceptual background first, What Is Superintelligence? A Plain Guide for Business Leaders covers the vocabulary. This article assumes you want a working test, not a definition.

Data: can a stronger model find and trust your company's knowledge?

A more capable model does not repair unreliable inputs. It reads them more fluently. If two documents disagree about a return policy, a better model will still have to pick one, and it may pick the wrong one with great confidence. Data readiness is mostly about removing that ambiguity before the model meets it.

Run these tests on the knowledge your first agent role would rely on:

• Each source has a named owner who can say whether it is current.
• Where two sources conflict, one is declared the source of truth and the other is retired or marked.
• Documents carry a date or version, so an old policy cannot pass as a current one.
• Sensitive material (personal data, contracts, financial records) is classified, and you know where it is stored.
• The agent retrieves from approved sources instead of from whatever happens to be in a shared drive.

The last test matters most. Retrieval architectures, where the system looks up approved material at the moment of a question, keep knowledge editable and auditable in a way that baking it into a model does not. Your goal is a small, well kept body of material, not a large, unkept one.

One caution. Data that an agent reads can contain instructions written by someone else, such as a pasted email or a web page. Treat retrieved content as untrusted input. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) describes this class of risk, and a ready company has at least asked the question.

Memory: does the agent remember what it should and forget what it should not?

Memory is the layer that lets an agent carry context between conversations: preferences, past decisions, the way your team names things. It is what makes an agent feel like a colleague. It is also where quiet problems accumulate, because memory that nobody reviews drifts.

A stronger model will use memory more skillfully, which raises the stakes on what is stored. Check the following:

• You can list what the agent remembers, in plain language, on request.
• Memory is separated by purpose: company facts, team preferences and individual notes are not mixed in one pile.
• Someone can correct or delete a wrong memory, and the correction takes effect.
• Personal and confidential details are not stored unless there is a reason and a retention rule.
• Memory can be backed up and restored, so a bad change is reversible.

Context is a limited resource even for strong models. Deciding what the agent should see at each step, and what it should leave out, is a design task of its own. Anthropic's write-up on [effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) is a useful technical reference for the people building this layer.

Permissions: what can the agent do, and who approved it?

Capability and authority are different things. A model that reasons better should not automatically be able to send more email, edit more records or spend more money. Permissions are how you keep authority a human decision.

A ready company can answer these without searching:

• Each agent has its own identity and credentials, not a borrowed employee login.
• Access is granted per tool and per action, such as read, draft or send, rather than as blanket access to a system.
• Actions with external or financial effect require a human approval, and the approval is recorded.
• There is a list of everything the agent can reach, and it was reviewed recently.
• Removing access takes minutes, and someone knows how to do it.

The principle behind this is least privilege, and the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) states it well: deny by default, check on every request, grant only what the task needs. The practical habit is a recurring review. Our guide to the quarterly AI agent permission review lays out the steps and the evidence to keep.

Evaluations: how will you know a stronger model is better for you?

Public benchmarks tell you how a model performs on someone else's problems. They do not tell you whether it handles your refund exceptions, your supplier naming quirks or your tone with long standing customers. The only dependable test is your own work, replayed.

An evaluation set is a collection of real tasks with agreed definitions of a good result. It does not need to be large to be useful. It needs to be representative, kept private and reused every time something changes: a new model, a new prompt, a new tool.

Illustrative scenario: a regional distributor wants to try a newer model for its order support agent. The operations lead pulls a set of past customer requests, including the awkward ones: partial shipments, mismatched invoices, a customer who writes in two languages. For each, the team has written what a correct reply and a correct action look like. The new model runs the whole set beside the current one. It writes better replies but, in several cases, proposes an action outside the approval boundary. The team keeps the old model in production, adjusts the tool limits and reruns the set. The decision rests on evidence from their own work, not on a vendor announcement.

Tests for your company:

• You hold a set of real tasks with written definitions of success.
• The set includes failure cases and edge cases, not only the easy path.
• You can run it against a new model in a test environment before production.
• Results are compared with the current setup, and a person signs off on the switch.
• Production behavior is logged well enough to find the next failure case.

For method, Anthropic's [guide to evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) is a practical read. For a risk framing that senior leaders can use, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organizes the work into governing, mapping, measuring and managing.

Ownership: who answers when something goes wrong?

Most AI failures in companies are not exotic. An agent keeps running after a process changed, a permission outlives the project it was granted for, or a champion leaves and nobody knows how the system works. Ownership is the discipline that prevents these.

Check these points:

• Each agent has a named business owner, and a named technical owner if they differ.
• An executive sponsor can make decisions about scope, risk and budget. The role is described in Executive Sponsor for an AI Project: What the Role Requires.
• Changes to prompts, tools, models and permissions go through a request and approval step.
• There is a documented way to pause the agent, and the people who may use it know about it.
• If the person who built the setup leaves, another person can run it from the documentation.

Ownership also covers the human side: who trains the team, who hears complaints and who decides whether an output is good enough. A model that improves every few months does not reduce the need for these roles. It makes them more important, because the system changes more often than your org chart.

How do you run this checklist in one working session?

You do not need a long program to find out where you stand. A focused session with the right people usually reveals the gaps.

• Pick one role for an agent, such as order support or internal knowledge search. Readiness is easier to judge for one concrete role than for the company in general.
• Invite the business owner, whoever manages the relevant systems, someone responsible for security or compliance, and an executive who can decide.
• Go through the five areas above. For each test, mark yes, partly or no, and write down the evidence for every yes. A yes without evidence counts as partly.
• Sort the results. Any no in permissions or ownership is a blocker. A no in data or memory limits scope. A no in evaluations means you cannot safely change models yet.
• Choose the smallest set of fixes that unblocks the role, and give each a name and a date.
• Repeat the session after the first fixes land, and again whenever you consider a new model or a new role.

If most answers are yes with evidence, you are ready to try a more capable model on a bounded task and compare it with your evaluation set. If the permission or ownership answers are mostly no, pause and fix those first. Our article on building a company superintelligence layer explains how these foundations fit into a structure that improves as models do.

How does Be Human handle these foundations?

Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the checklist above becomes a routine instead of a one time exercise. The agent's identity, memory and permissions stay under your control, and changes to the underlying model go through the same review as any other change.

Frequently asked questions

Do we need to wait for superintelligence before doing any of this? No. Every item on the checklist improves the reliability of the AI you use today, and none of it depends on a particular future model. Starting now means your first stronger model meets a prepared company.

Who should lead the readiness assessment? An executive sponsor with authority over scope and risk should own it, with the business owner of the target role running the session. Technical staff or a partner supply the evidence on data, access and logging. Avoid delegating it entirely to IT, because several tests concern business decisions.

How often should we repeat the checklist? Repeat it whenever you add a role, change a model or alter a major integration, and review permissions on a regular schedule. A light review each quarter is a sensible rhythm for most teams. The point is to catch drift before it becomes an incident.

What if we fail several tests? That is normal and useful, because it tells you where to spend effort. Fix permissions and ownership first, then data and evaluations, and keep the agent's scope small until the answers improve. A narrow agent with sound foundations is worth more than a broad one without them.

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