Superintelligence in Business Planning Without Dates

Superintelligence in business scenario planning is, for now, a planning topic and not a forecasting one. No one can say with confidence when, or whether, systems far more capable than human teams will be available. What a company controls is the quality of decisions that hold up at any pace of progress: document processes, measure what the AI does, and limit what it can access and execute. This article shows how to build scenarios and choose those decisions.

Key takeaways

• Planning by scenarios is more useful than betting on a date: each scenario has observable signals and a response agreed in advance.
• Some decisions hold in every scenario: documented processes, quality and cost metrics, minimum access, and the ability to switch vendors.
• Autonomy should grow on measured evidence from a real workflow, not on expectations about what the next generation of models will do.
• Separating official documentation, implementation experience and hypothesis keeps speculation from turning into an investment plan.
• Reviewing scenarios on a fixed schedule, with a named owner, costs little and stops the subject from becoming anxiety or hype.

What does it mean to plan for superintelligence without predicting dates?

Superintelligence, in its most common use, is the hypothesis of a system that broadly outperforms humans at cognitive tasks. Today that is a debate and a research topic, not a product a company can buy. What companies actually run are language models, assistants and agents with defined roles. If you want to understand that difference calmly, read the difference between AGI, ASI and AI agents and the superintelligence myths that get in the way of decisions.

Planning without predicting dates means changing the question. Instead of "when will AI outperform our team?", the question becomes "what would we do differently if AI became more capable gradually, unevenly, slowly or quickly, and what is already worth doing in all of those cases?". The first question requires guessing. The second requires only management discipline.

A methodological habit helps here. When you read any material on the subject, separate three kinds of claims: what a vendor's or an authority's official documentation describes, what teams report from implementation experience, and what is hypothesis. Date predictions almost always belong to the third group, even when they come with a confident tone.

How do you build scenarios for more capable AI?

A scenario is not a forecast. It is a plausible story about the environment, tied to signals you can observe and to a response already agreed. For most companies, four scenarios are enough:

• Gradual progress: models improve in regular steps and agents take on more tasks, always under supervision. Signal: the share of tasks the agent completes without human correction rises steadily in your own workflow. Response: expand scope in stages.
• Uneven progress: AI becomes very good at some tasks (for example, reading documents or code) and stays fragile at others. Signal: clear gains in one process and none in another. Response: concentrate investment where the evidence appears.
• Slowdown: cost, regulation or technical limits slow progress. Signal: the models you use change little over a long period. Response: consolidate, reduce cost per task and improve how you operate what you already have.
• Broad leap: much greater capability in many areas at once. Signal: an agent passes your internal tests in processes that used to require human judgment. Response: review roles, approvals and access limits before expanding autonomy.

For each scenario, write one page: what would change in your process, which signal would confirm it is happening, who decides, and what the first action is. If there is no observable signal, the scenario is just an opinion and should be dropped or reworked.

Which decisions hold in every scenario?

The most useful part of the exercise appears when you compare the responses and look for what repeats. In general, four areas show up in every scenario.

Document. An agent, today or in the future, can only help with a process that someone knows how to describe. Record steps, exceptions, owners, decision criteria and what "done well" means. This material serves to train people, guide a simple agent and, later, evaluate a better one. Companies that already have an organized knowledge base are also preparing for the company superintelligence layer, which depends on reliable context.

Measure. Before any pilot, define the current baseline of the process: time, rework, perceived quality and cost per task. Without it, any improvement or decline is just an impression. Evaluation tests built from the company's real cases, in the style described in the agent evaluation guides published by vendors such as OpenAI and Anthropic, give you a yardstick that stays valid when the model changes.

Limit. Grant the minimum access needed to data and actions. Separate what the agent can read, what it can suggest and what it can execute. Irreversible actions, such as payments, mass messaging and changes to sensitive records, stay with human approval. OWASP's authorization guidance is a good technical reference for this design.

Keep the option to switch. Avoid tying processes, prompts and data to a single vendor or model. Keep instructions, test cases and logs in a format you control. If the scenario is fast progress, you switch models with little friction. If it is a slowdown, you renegotiate without depending on anyone.

Illustrative scenario: a service company with WhatsApp support

Illustrative scenario, no real data: a home services company handles quote requests and rescheduling over WhatsApp. Today, an AI agent answers simple questions and hands the rest to the team.

The leadership wants to know whether to hire more people or bet on more autonomous AI. Instead of deciding by gut feeling, it builds the four scenarios. In all four, it finds it needs the same things: the support script written down, a log of each conversation with the reason for any handoff, a measure of how many conversations the agent resolves without correction, and a rule that rescheduling and billing are only confirmed by a person.

Only after that does the company define what changes in each scenario. If the agent starts resolving reschedules well, with evidence in the log, human approval can be reduced for that type of case. If nothing improves, the focus shifts to cost per conversation and script quality. The hiring decision stops depending on a date and starts depending on a number the company measures itself.

Step by step to start in the next few weeks

The method we use in AI projects follows four moves: map, limit, pilot and hand over. Applied to scenario planning, it looks like this:

• Map: choose one important process and describe the current flow, the exceptions, the people involved and the data used. Record the baseline.
• Map: list which decisions in that process are routine and which require judgment or carry legal or financial consequences.
• Limit: define what the AI can read, suggest and execute. Apply the principle of least access and state which personal data is involved, in line with LGPD (Brazil's data protection law).
• Pilot: run a single real workflow, with a decision log and a success metric agreed before you start.
• Pilot: review the logs at fixed intervals and note error cases, not only the successes.
• Hand over: give the team the script, logs, tests and access rules, with a named owner.
• Decide: at the end of the pilot, choose between expanding, adjusting or stopping, and record the reason.

No forecast is needed to carry out this list. It produces what any scenario will demand: a written process, evidence of performance and access control.

Which signals should you track, and when should you review the scenarios?

Scenarios age. Set a fixed review schedule, for example every quarter, and name one person responsible for bringing evidence. Good sources of signal are, in order of weight:

• Your own numbers: resolution rate without correction, error types, cost per task and human review time.
• Official documentation from the vendors you use: changes in capability, limits and data policy.
• Regulatory milestones and guidance from authorities such as Brazil's data protection authority (ANPD), along with tracking the Brazilian AI legal framework.
• Risk management frameworks, such as the NIST AI Risk Management Framework and the OECD AI principles, which help structure governance questions without depending on a specific technology.

Headlines, videos and expert predictions count as context, not as triggers. A good rule: no change in investment or autonomy happens because of a news story. It happens when a signal defined in the scenario shows up in your data.

What to avoid when dealing with superintelligence in the company

Some mistakes repeat and are easy to avoid.

• Waiting for the ideal technology before you start documenting and measuring. That work does not lose value.
• Giving broad access to systems "because the model is smart". Capability does not replace minimum permission.
• Treating a general-purpose assistant as if it were superintelligence and delegating decisions that require human accountability. For automated decisions about people, LGPD provides a right to review (see LGPD automated decision-making and the right to review).
• Creating a large, slow committee. One owner, one recurring meeting and one page per scenario are usually enough.
• Telling the team promises or threats with no basis. Explain what the company will measure and how people take part in the review.

Frequently asked questions

Does superintelligence already exist, and is my company already using it?

There is no solid public basis for treating today's commercial assistants and agents as superintelligence. They are useful systems for defined tasks, with errors and limits that need supervision. Planning for something more capable is prudent, but operating what exists with control is what creates value now.

Should I postpone AI projects until the technology matures?

In general, no. Documenting the process, defining metrics and limiting access are work that serves any scenario, and a small pilot with logs teaches more than waiting. What is worth postponing is expanding autonomy, until there is measured evidence in your own workflow.

Do I need an AI committee to do this planning?

For most small and mid-sized companies, no. One responsible person is usually enough, supported by whoever knows the process and whoever looks after data and security, plus a review on a fixed schedule. If the company grows or handles sensitive data, the structure can become more formal over time.

How do I present this to the board without promising results?

Present the scenarios as hypotheses, each with an observable signal, an agreed response and a cost of preparation. Show the decisions that hold in all of them and the current baseline of the chosen process. That way the conversation is about risk and evidence, not about a forecast no one can support.

Sources

• NIST: AI Risk Management Framework
• OECD: AI Principles
• OWASP: Authorization Cheat Sheet
• Anthropic: Demystifying evals for AI agents