Superintelligence Strategy for Mid-Sized Companies: Three Horizons

A superintelligence strategy for companies is a plan that stays valid as AI gets stronger, because it is organized around what AI can reliably do rather than around dates. For a mid-sized firm, a practical version has three horizons: supervised assistants, accountable operators and systems that outperform your best experts. Each horizon has its own things to build, decisions to make and signals to watch, and the foundations (context, access control, measurement, ownership) carry across all three.

Key takeaways

• Define horizons by observed capability, not by calendar. You cannot act on a forecast, but you can act on evidence from your own work.
• Horizons apply to individual processes, not to the whole company. Invoice follow-up may sit in a later horizon than contract review.
• Most of the preparation is shared across horizons: documented context, scoped permissions, evaluations built from real cases and a named human owner.
• Move a process to the next horizon only when measured evidence supports it, and write down in advance what would send it back.
• Keep your memory, tools and evaluations portable so that a better model is an upgrade, not a migration project.

Why plan by capability instead of by calendar?

Predictions about when much stronger AI will arrive disagree with each other and change often. A mid-sized company has no use for a date it cannot verify. It does have use for a trigger it can observe: this class of work now comes back correct without edits, over a long enough run to trust.

Planning by capability turns an argument about the future into an operating question about the present. Instead of asking whether superintelligence is near, you ask what a given process currently needs from humans, and what evidence would let you reduce that. The answer is specific, testable and reversible.

This also keeps the strategy honest. A plan tied to a date becomes obsolete the day the date passes or the forecast shifts. A plan tied to capability simply waits for the signal. If you want a vocabulary for the risk side, the NIST AI Risk Management Framework organizes the work into governing, mapping, measuring and managing, which fits well with the horizon approach below.

One idea runs through everything that follows: the lasting asset is not any single model, it is the layer you own around it. That means your context, tools, permissions and evaluations. The article Build a Company Superintelligence Layer That Improves With Models covers that layer in more depth.

Horizon one: supervised assistants

In the first horizon, AI produces useful drafts, summaries, analysis and bounded actions, but a person checks the output before it matters. Errors are frequent enough, or costly enough, that review is not optional. Most companies that use AI seriously today have at least some processes here, and that is a perfectly good place to be.

What to build in this horizon:

• One clearly defined role, such as a research assistant for the sales team or a first-draft writer for customer replies.
• Written context the assistant can draw on: product definitions, policies, tone rules, examples of good work and the decisions your team already made.
• Narrow tool access, mostly read-only, with any outbound action passing through a person.
• A visible review step and a log of what was changed during review.
• A small set of real cases that you rerun whenever the model, prompt or tools change.

The decision that matters most here is who reviews and what they are accountable for. Review that nobody owns turns into rubber-stamping within weeks. Name the reviewer, define what a correction looks like and keep the corrections, because they become your best evaluation material. Both Anthropic and OpenAI publish practical guidance on building evaluations for agents and model outputs, and both start from the same idea: test against realistic tasks, not demos.

A lightweight set of rules for who may use what, and with which data, belongs here as well. AI Governance for Companies: A Lightweight Start for Mid-Sized Firms describes a version a mid-sized team can actually maintain.

Horizon two: accountable operators

In the second horizon, agents carry multi-step work across your systems. They gather information, make decisions inside limits, take actions and report back. People review samples, exceptions and anything above a threshold of money, legal exposure or customer sensitivity, instead of reading every output.

This is a different operating model, not just a faster version of horizon one. The agent needs identity, permissions and a defined scope, and the humans around it become supervisors of outcomes. What to build:

• Permissions per action, not per system. Reading a record and changing it are separate grants, and the principle of least privilege applies as it would for any employee. The OWASP Authorization Cheat Sheet is a good reference for the underlying discipline.
• Approval boundaries written in plain language: what the agent may do alone, what it must ask about, what it may never do.
• Monitoring that shows what the agent did, why and at what cost, so a manager can answer questions without reading raw logs.
• Recurring evaluations, so that a model update or a changed integration does not quietly degrade results.
• An incident process with an owner, a way to pause the agent and a way to restore a known good state.
• Defences against untrusted input. An agent that reads email or web pages can be steered by text inside them, so tool access and content handling need deliberate limits.

The key decision is what the agent may do without asking, and that decision should be revisited with evidence, not preference. Anthropic's guidance on building effective agents favors simple, composable designs with clear checkpoints, which is also what makes an agent easy to supervise. If you are unsure whether a process is ready to move up, the stages in Proof of Concept, Pilot or Production: What Each AI Stage Must Prove give a useful test.

Horizon three: systems that exceed your best experts

The third horizon is the one people usually mean by superintelligence: systems whose judgment across most knowledge work in your domain is better than that of your strongest people, and which can pursue long projects with little direction. Nobody can say with confidence whether or when this arrives, and a mid-sized company should not build around a guess.

What you can do is prepare for what would stay true if it did. Three things do not change:

• Your data, your customers and your obligations are still yours. A stronger system still needs accurate context about your business, and still operates inside your legal and contractual limits.
• Authority and accountability still sit with humans. Someone must set objectives, decide what is acceptable and answer for the result.
• Verification becomes the bottleneck. When producing analysis is cheap and excellent, the scarce skill is deciding which goals to pursue and checking that outcomes are real.

So the preparation is about control and portability. You want clear decision rights for who can set an objective, who can approve spending or external commitments and who can stop the system. You want records that let you audit what it did. And you want your context and tools to be portable, so that moving to a stronger model is routine. AI Vendor Lock-In: Keep the Gains In-House as Models Change explains how to keep that flexibility.

How do you tell which horizon a process is in?

Horizons describe processes, not companies. A firm can run customer follow-up in the second horizon while contract review stays in the first. Use these tests for each process separately:

• If a person reads every output before it is used, the process is in horizon one.
• If people review samples and exceptions while the agent acts inside written limits, it is in horizon two.
• If the system proposes goals, redesigns its own workflow and humans mainly approve direction and verify results, you are approaching horizon three.
• If nobody measures the output, the process is below horizon one. Fix measurement before anything else.

Promotion should follow a rule, not a feeling. Write down the evidence required to move up, for example a sustained run of reviewed cases with no material corrections, and the event that moves a process back down, such as a failed evaluation after a model change. Demotion should be as easy and as unembarrassing as promotion.

Here is an illustrative scenario. A regional distributor has an agent that drafts replies to suppliers about invoice mismatches, and an accountant sends each one. After a long run of reviews, the accountant finds that one class of mismatch, such as a missing purchase order reference, is almost never edited. The company lets the agent send that class directly, below a set value, with a weekly sample review. That class is now in horizon two. Disputes over damaged goods stay in horizon one, because they involve judgment and relationships. Demand planning stays there too, because nobody has yet built a way to measure its quality.

What should a mid-sized company do now?

The steps below work regardless of which horizon you end up needing. They build the layer you will use whether models improve slowly or quickly.

• Name an executive owner for AI work, with authority over budget and scope and time to attend reviews.
• Choose one role in one process where the work is frequent, the inputs are digital and the result is observable.
• Write down the context that role needs: policies, definitions, exceptions, examples and the people it should escalate to.
• Set permissions and approval boundaries before the first run, and record who can change them.
• Define one success criterion that someone outside the project could check, and build an evaluation set from real past cases.
• Add monitoring, a pause switch and a restore path before widening access.
• Write promotion and demotion rules for the process, so horizon changes are decisions rather than drift.
• Keep memory, tool definitions and evaluations in formats you control, so you can change models without starting over.
• Review permissions and results on a fixed schedule, and rerun evaluations whenever something underneath changes.

Be Human handles this as managed operations. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. After that, Be Human can run monitoring, recurring evaluations, integration maintenance, permission review and incident response, and make improvements through controlled changes that your team approves. The agent's identity, memory and permissions stay under your control, and the service is delivered remotely in English and Portuguese. A broader self-assessment is available in Superintelligence Readiness Checklist for Company Leaders.

Which mistakes weaken a horizon plan?

The same few errors appear again and again, and most are organizational rather than technical.

• Treating the plan as a prediction. If the plan says something will happen by a certain time, it will be wrong, and people will stop trusting it. Keep it conditional on evidence.
• Promoting a whole department at once. One process at a time keeps failures small and lessons clear.
• Skipping the reviewer. A review step without a named owner decays quickly, and the decay is invisible until something goes wrong.
• Confusing a demo with a measurement. A smooth presentation says little about how the system handles your messy cases.
• Tying memory and tools to a single provider. It makes every future improvement more expensive than it needs to be.
• Waiting for certainty. The foundations above cost little and pay off in every scenario, so there is no reason to hold them back.

Frequently asked questions

Do we need a superintelligence strategy if we only use AI for drafting? Yes, but a small one. Drafting is horizon one work, and the strategy at this stage is mostly a few written rules, a named reviewer and a set of real cases you can test against. That small base is what makes later steps safe.

Should a mid-sized company wait until AI gets stronger before investing? Waiting saves little and costs the learning. The context, permissions, evaluations and ownership you build now transfer to stronger models, so early work is not wasted. What you should avoid is large commitments tied to one model or one provider.

Who should own the strategy? An executive who controls scope and budget should own it, supported by people close to the processes involved. Technical staff or an outside partner can run the work, but decisions about what the agent may do belong to the business. Without that owner, horizon changes happen by accident.

How often should we revisit the horizons? Review each process on a fixed schedule, and also whenever the underlying model, the tools or the data change. A scheduled review catches slow drift, while the event-based review catches sudden changes in quality. Keep both short and based on evidence from your evaluation set.

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