Superintelligence Scenario Planning Without Predictions

Superintelligence scenario planning means defining a few distinct levels of AI capability, then testing each company decision against all of them instead of betting on one arrival date. You describe what AI could do in your workflows at each level, mark which decisions hold up everywhere, and set observable signals that tell you when to move. The result is a plan that stays useful even when your timing guesses turn out wrong.

Key takeaways

• Plan around what AI can do, not when it will arrive. Capability levels are testable. Dates are opinions.
• Sort every AI decision into one of three groups: holds in every scenario, keeps options open, or is a bet that needs a trigger.
• Most of the valuable work is the same in every scenario: clean knowledge, clear permissions, observable results and human approval boundaries.
• Replace forecasts with signals. A signal is something you can measure inside your own workflows, such as a task your agent could not do last quarter and now does reliably.
• Review the scenarios on a fixed rhythm and after any major model change. A plan nobody revisits is just another prediction.

Why do predictions fail as a planning input?

Most AI planning conversations start with a question nobody can answer: when will systems become far more capable than people at most knowledge work? Informed experts disagree, and the disagreement does not narrow just because a leader needs a number for a budget meeting. If your plan depends on one answer, the plan is as fragile as the guess.

There is a second problem. A date-based plan makes the wrong people comfortable. Believers overinvest in ambitious projects that outrun the company's data and controls. Skeptics defer everything and discover later that they have no memory, no tooling and no habits to build on. Both groups made a prediction and then called it strategy.

Scenario planning has a long history in business for exactly this reason. It does not ask which future is correct. It asks which decisions you would still defend if any of several futures showed up. For AI, the useful twist is to define the futures by capability instead of by calendar, because capability is what changes your operations.

What is a capability-based scenario?

A capability-based scenario is a short description of what AI systems can reliably do at a given level, stated in terms of your own work. It avoids vague phrases such as "much smarter" and instead says what a system can take on, how long it can work unsupervised, and how often a person must check it.

For most companies, four levels are enough. You can rename them, but keep them distinct.

• Assisted: AI drafts, summarizes and answers questions. A person starts every task and reviews every result.
• Delegated: an agent owns a defined role end to end, such as triaging requests or preparing weekly reports, inside clear approval boundaries.
• Coordinated: several agents hand work to each other across departments, and people supervise exceptions and outcomes rather than steps.
• Beyond expert: systems outperform your best specialists at complex analysis and planning, and can propose changes to how the company itself runs.

Notice what these levels do not contain: any year. Your company may sit between two of them depending on the function. Finance may be at assisted while customer support is at delegated. That unevenness is normal and useful, because it shows where the next level would matter first.

For a broader view of how horizons differ for mid-sized firms, see Superintelligence Strategy for Mid-Sized Companies: Three Horizons.

How do you run the planning exercise, step by step?

You need a small group and a few hours of focused time, plus someone who owns the result. A leader from operations, one from finance or risk, and one person who knows the actual workflows is a good minimum. Work through these steps in order.

• Step one: list the decisions. Write down every AI-related choice currently open or recently made. Include tool purchases, hiring, data projects, contracts, training and any agent pilot. Aim for specific items, not themes.
• Step two: define your capability levels. Use the four above or adapt them. Write two or three sentences per level describing what changes in your workflows.
• Step three: describe each level for each function. For each major team, note what work would move to AI, what would stay with people, and what new work would appear, such as reviewing agent output.
• Step four: test each decision against each level. Ask whether the decision still makes sense, becomes harmful, or becomes irrelevant. Record a short reason, not a score.
• Step five: sort the decisions into no-regret moves, option-preserving moves and bets. The next section explains how.
• Step six: attach a signal and an owner to every bet. A bet without a trigger is a hope.
• Step seven: set a review date and a rule for off-cycle reviews, for example after a major model change or an incident.

Keep the output to a few pages. If the document is long, nobody will reread it, and rereading is the point.

How do you sort decisions into no-regret moves, options and bets?

The sorting step is where the exercise pays off. Use the test results to place each decision in one of three groups.

• No-regret: the decision is sound at every level. Examples include documenting how your processes really work, cleaning the sources an agent would read, defining who can approve what, and logging what agents do so results can be inspected. Do these now.
• Option-preserving: the decision is sound at most levels and cheap to reverse. Examples include choosing tools that let you swap models, keeping your knowledge and prompts in formats you own, and signing shorter terms with providers. Do these with attention to exit costs.
• Bet: the decision pays off only at certain levels, or harms you at others. Examples include restructuring a team around agents that do not yet exist, or committing to a single provider's proprietary workflow format. Do these only after a signal fires, and size them so a wrong call is survivable.

A quick decision guide helps when the group is stuck on a single item.

• If it is useful when AI stays at the assisted level, treat it as no-regret.
• If it becomes more useful as AI improves and costs little to undo, treat it as an option.
• If it only works when AI improves a lot, or it is hard to undo, treat it as a bet and name the trigger.
• If it breaks at any level, redesign it before approving it.

The pattern surprises many leaders. The no-regret group is usually the largest, and it is mostly operational groundwork rather than technology. That is also why you can start before any debate about timing is settled. The practical side of that groundwork is covered in How to Prepare Your Company for Superintelligent AI Today.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a real case. Imagine a mid-sized distribution company deciding how to handle supplier communication. Today, three coordinators answer supplier emails, chase delivery confirmations and update a shared spreadsheet.

The leadership group lists three open decisions: pilot an agent for supplier follow-ups, sign a long contract with a workflow platform that bundles its own agent, and reorganize the coordinator team around a future automated process.

They test each against the four levels. The pilot holds at assisted and delegated, and it teaches the company how to supervise an agent, so it is no-regret as long as approvals and logging are in place. The long platform contract works at delegated but locks workflows into a proprietary format that may block a coordinated or beyond-expert setup, so it becomes a bet and they ask for shorter terms and exportable data. The reorganization depends on a capability the company has not seen, so it is a bet with a trigger: the agent must handle a defined share of supplier threads without correction for a full review period, as measured in the pilot's own logs.

None of those conclusions required a forecast. They required a clear description of the work and an honest look at what each choice costs to reverse. If you want to define what a pilot must demonstrate, How to Define Success Criteria for an AI Agent Pilot covers it.

Which signals should trigger a review?

Signals turn scenario planning from a workshop into a management habit. Good signals come from inside your company, because external headlines are noisy and rarely match your workflows. Examples worth tracking:

• Tasks that agents now complete without human correction, compared with the last review.
• The time a person spends reviewing agent output compared with doing the task directly.
• The kinds of errors that appear: fewer careless slips, or the same ones recurring.
• Cases where an agent proposes a better process than the documented one, and the proposal holds up.
• Requests for broader permissions, and whether the evidence supports granting them.

To make these signals trustworthy you need evaluations that run repeatedly on real tasks. Anthropic's guidance on [demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) explains how to build checks that show whether an agent improved or regressed after a change. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a helpful reference for structuring how you map, measure and manage risks as capability changes.

Permissions deserve their own signal. As agents become more capable, the temptation is to widen access because the agent seems reliable. Treat that as a decision with evidence, not a drift. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) reinforces least privilege and consistent checks, which apply no matter how capable the system behind the request becomes.

How does Be Human's managed approach handle this?

Be Human designs, implements and operates AI agents that keep their identity, memory, channels, tools and permissions under human control. In practice, that means the no-regret work is built into a first engagement: one defined role, the memory and tools it needs, approval boundaries and an observable success criterion. Managed operations then supply the signals described above through monitoring, recurring evaluations and permission review, and controlled improvements let a model change be tested before it reaches the role. Because the agent's knowledge and configuration stay under the company's control, a change in the underlying model is a change to test, not a rebuild.

Frequently asked questions

Do we need to believe superintelligence is coming to use this method? No. The method works whether you think highly capable systems are close, distant or uncertain, because it tests decisions against several levels rather than assuming one. Skeptics and believers can use the same document and disagree only about how soon to review it.

How often should we revisit the scenarios? Set a regular rhythm, such as every quarter, and add an off-cycle review after a major model change, an incident or a new request to widen an agent's permissions. If nothing has changed, the review can be short. The habit matters more than the length.

What if our company is too small for scenario planning? The exercise scales down. A small team can list its open AI decisions, describe the four levels in a page and sort the decisions in one meeting. The same groundwork, clear processes and owned knowledge, helps at any size, and Superintelligence for Small Business: Is It Relevant Yet? discusses where to start.

How do we avoid vendor lock-in while the situation is uncertain? Treat portability as an option-preserving move: keep your knowledge, prompts and configuration in formats you own, and prefer terms that allow you to switch models. AI Vendor Lock-In: Keep the Gains In-House as Models Change covers the practical checks. Lock-in is rarely a problem on day one and often a problem at the first renewal.

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