Superintelligence Readiness Assessment: 12 Questions to Score

A superintelligence readiness assessment is a short, honest check of whether your company's own AI setup would hold up if the models behind it became far more capable. The twelve questions below score six layers: role, memory, tools, permissions, evidence and operations. The layer with the lowest score is the one that would limit you first, and it is rarely the model.

Key takeaways

• Readiness is mostly about what surrounds the model: the role it holds, the knowledge it reads, the tools it can touch, the limits on its access, the proof that it works and the people who run it.
• Score each of the twelve questions 0, 1 or 2, then add the two answers in each layer. The lowest layer is your first constraint, whatever your total is.
• A single zero can cap an otherwise strong setup, so read the scores by layer and not as one grade.
• Permissions and evidence deserve attention first when scores tie, because a more capable agent amplifies whatever access and blind spots already exist.
• The check is useful with one agent or none. Zeros simply show what to prepare before the first agent starts work.

What does a superintelligence readiness assessment actually measure?

You do not control when models improve, and nobody can honestly give you a date. What you do control is everything around the model: who owns the work, what the agent can read, what it can act on, how its access is limited, how you know it is doing well and who keeps it running. A readiness assessment looks at those things and ignores speculation about the models themselves.

The reasoning is simple. A more capable model placed inside a weak setup does not fix the setup. It uses the same shared login, reads the same outdated documents and goes unchecked in the same way, only faster and more broadly. A company with clear roles, controlled memory, narrow permissions and a habit of testing can swap in a stronger model and benefit. A company without them inherits the same problems at a larger scale.

This check is narrower than a full leadership programme. If you want the wider agenda, including strategy and governance, the superintelligence readiness checklist for company leaders covers it. If you want a fuller picture of the parts involved, the seven layers of company AI infrastructure explains them in more depth. This article does one thing: it helps you find the single layer most likely to hold you back.

How do you score the twelve questions?

Score every question the same way:

• 0: No, or nobody can say.
• 1: Partly, or yes but never tested or written down.
• 2: Yes, written down, and checked recently.

Answer for one agent or one workflow, not the whole company. If you have no agent yet, answer for the first role you would give one. Be strict. A guess that things are probably fine is a 1 at best. It helps to have the people who actually run the work in the room, not only the sponsor.

Questions 1 to 6: role, memory and tools

These three layers decide whether the agent has a clear job, the right knowledge and a sound way to act.

• Role, question 1: Can you describe the agent's role in one sentence and name the person who owns its results?
• Role, question 2: Is there a written list of what the agent must not do, and a named person or team it hands work to when it reaches that limit?
• Memory, question 3: Does the agent read company knowledge (policies, product facts, customer history) from sources you control, rather than from whatever someone pasted into a chat?
• Memory, question 4: Does a named person keep that knowledge current, and can you see which sources the agent used for a given answer?
• Tools, question 5: Does the agent act through defined connections with each action recorded, rather than through shared logins or workarounds nobody documented?
• Tools, question 6: Could you change the model behind the agent without rebuilding its tools, knowledge and instructions?

A few notes on why these matter. Questions 1 and 2 are about ownership. An agent with a vague role produces vague results, and nobody can tell whether it is succeeding. Questions 3 and 4 are about context. A model can only act on what is placed in front of it, and choosing and maintaining that material is a discipline of its own. Anthropic's engineering team has written about [effective context engineering for agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), and the central point holds for any company: the quality of an agent's work follows the quality of what it reads.

Question 6 is the one most leaders skip. If your instructions, knowledge and tool connections live inside one vendor's product, a better model elsewhere is out of reach. If they live in assets you own, a better model is a configuration change followed by a test.

Questions 7 to 12: permissions, evidence and operations

These three layers decide whether you can trust the agent, prove it and keep it alive.

• Permissions, question 7: Does the agent have its own identity with the least access it needs, separate from any employee's account?
• Permissions, question 8: Are there defined actions that need human approval before they happen, and is each approval recorded?
• Evidence, question 9: Do you have a set of real example tasks with known good outcomes that you rerun whenever the model, instructions or tools change?
• Evidence, question 10: For any output, can you see what the agent read, which tools it called and what it cost to produce?
• Operations, question 11: Is there a routine, with named owners, for reviewing permissions, repairing integrations and handling incidents?
• Operations, question 12: Can you stop the agent, roll back a change, and restore its configuration and memory, and have you actually tried it?

Permissions come down to a long-standing security principle: give each actor only what it needs. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) describes least privilege and deny-by-default checks in terms that apply directly to an agent. A more capable agent with broad access is a larger risk, not a smaller one.

Evidence is what turns an opinion into a decision. A fixed set of example tasks lets you compare a new model against the old one on your own work. Anthropic's article on [evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) explains how teams build those sets and why they matter when anything changes. Question 10 adds traceability: if you cannot see what happened, you cannot fix it.

Operations is the layer that looks least exciting and fails most quietly. Integrations break when a connected system changes. Permissions drift when people change roles. Question 12 is a blunt test: an untested restore is a hope, not a control.

How do you read your score?

Add the two answers in each layer. Each layer lands between 0 and 4. Then use this guide:

• A layer at 0 or 1 is a blocker. Fix it before widening what the agent does or upgrading the model.
• A layer at 2 or 3 is workable but fragile. Name the missing piece and schedule it.
• A layer at 4 is strong. Recheck it whenever the model, tools or scope change.
• If two layers tie for lowest, start with the one earlier in the list (role, memory, tools, permissions, evidence, operations), because later layers assume the earlier ones.
• The exception: a zero on question 7 or 8 always goes first. Unlimited access without approvals is the one gap that gets worse as models improve.
• Ignore the grand total as a verdict. A high total with a single zero still has a ceiling, and a modest total with no weak layer is a better base to build on.

Do not compare your score with other companies. The check measures your setup against your own work, and its value is the conversation it forces between the people who own the process, the data and the access.

What does this look like in practice? An illustrative scenario

This is an invented example, not a real client. A distribution company has an agent that drafts replies to supplier questions for the purchasing team. The leaders score the twelve questions and get these layer totals: role 4, memory 3, tools 3, permissions 1, evidence 2, operations 1.

The total looks respectable, but the layers tell a different story. The agent works through the login of a senior purchasing manager, which is why permissions scored low. It can see and change far more than its job requires, and nobody approved that on purpose. Operations scored low too, because nobody owns the review of that access and nobody has tried restoring the agent's setup after a failure.

The team had been planning to switch to a stronger model. The check shows why that would be the wrong first move. A stronger model behind the same shared login would act with the manager's full rights, with less obvious errors. The first work is smaller and more useful: give the agent its own identity limited to supplier correspondence, require approval before any change to terms or prices, assign an owner for quarterly access review, and run one restore test. Only then does the model upgrade make sense, and the team can run its example tasks to confirm it helps.

What should you do after you score?

A short plan keeps the result from becoming a document that nobody reads:

• Write down the six layer totals and the single lowest layer, with the question numbers that scored 0 or 1.
• Assign one named owner to that layer and agree what a 2 on each of its questions would look like.
• Fix the lowest layer first, in the smallest change that moves its score. Do not start two layers at once.
• Rescore after the change, and again whenever the model, tools or scope change.
• Set a success measure for the agent's work that you can observe, such as the number of drafts approved without edits in a week. How to define success criteria for an AI agent pilot walks through this.

The managed approach at Be Human follows the same order. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations then cover the recurring work behind questions 9 to 12: monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. Access and approvals stay under human control, and a recurring review such as the quarterly AI agent permission review keeps the permissions layer from drifting.

If you want a neutral reference for the risk side of this work, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a vocabulary for mapping, measuring and managing AI risk that fits alongside this check.

To find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

How often should we repeat the readiness check? Repeat it whenever the model, the tools or the agent's scope change, and otherwise on a regular schedule such as quarterly. Permissions and integrations drift quietly, so the operations and permissions layers benefit most from a recurring look.

Who should answer the twelve questions? Ask the people who run the work: the process owner, whoever manages the data and knowledge sources, and whoever controls access. The executive sponsor should read the results, but sponsors alone tend to score generously, so treat disagreement between answers as useful information.

Can a company with no AI agent yet use this check? Yes. Answer for the first role you would give an agent, and expect many zeros. Those zeros are a preparation list: who will own the role, which knowledge it needs, what access it should have and how you will test it.

Does a high score mean we are ready for superintelligence? No. The score tells you whether your own setup would let a more capable model do useful work under human control, but it says nothing about when such models will exist or how they will behave. Treat it as a measure of how well your company can absorb improvement, and keep rechecking it as the setup changes.

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