What a Superintelligence Consultant Should Deliver to Your Company

A superintelligence consultant should deliver working artifacts for your company, not forecasts about future models. The core set is a layer map of your AI stack, a permission model that states what an agent may read, write and approve, an evaluation plan tied to one observable success criterion, and a handover your own staff can operate. A proposal that lists predictions but none of these is selling outlook, not capacity.

Key takeaways

• Ask for artifacts you can inspect: a layer map, a permission model, an evaluation plan and a handover.
• Judge a consultant by the changes they make to daily operations within weeks, not by their view of future model capability.
• Every agent permission should name the systems it reads, the systems it writes to, and the actions a named person must approve.
• Agree one observable success criterion before anything is built, and keep a record of how it is measured.
• Keep memory, instructions, tool configurations and access logs under your control so a change of provider does not erase the work.

What a superintelligence consultant should actually deliver

The word superintelligence describes systems that could exceed human ability across many domains. No one can give a reliable calendar for that, which means a consultant who sells dates or forecasts cannot be held to them. What a company can hold a consultant to is the operation that exists after the engagement: which role an agent fills, what memory and tools it uses, what it may do alone, and how anyone will know whether it works.

In practice, the deliverables fall into five groups:

• A layer map of the current and planned AI stack, with a named owner for each layer.
• A permission model listing every system the agent can reach, the access level for each, and the approval boundary.
• An evaluation plan with one success criterion, a fixed set of test cases, and a review rhythm.
• An operating handover with runbooks, an access inventory, backup steps and an escalation path.
• A list of open leadership decisions, each with the default that applies if nobody decides.

Each group should be written in plain language that the operations lead can read without the consultant in the room. If the material only makes sense to the person who wrote it, the work has not been transferred.

Start with a layer map, not a model comparison

A layer map shows how the pieces of an agent fit together: the business role and its process, the memory and knowledge sources, the tools and integrations, identity and permissions, the model and its provider, evaluation and monitoring, and the governance that decides who changes what. The map is useful because it separates things that tend to get tangled. A model can be replaced. A policy document that the agent relies on is not replaced when the model is swapped. The one-page guide Draw Your AI Stack: A One-Page Architecture Map for Leaders shows a workable format.

For each layer, the map should state the owner, the point of failure, and what it would cost to replace. Those three answers show where attention belongs. A layer with no owner is the first thing to fix, even before any agent is built.

Illustrative scenario: a regional distributor wants an agent to answer order status questions. Its layer map shows that order data lives in the ERP, that the rules for answering come from a policy document maintained by nobody in particular, and that the model could come from several providers. The map turns a vague project into two concrete tasks: assign an owner to the policy document, and confirm which fields the agent may read from the ERP.

Write the permission model before any tool is connected

A permission model answers four questions for every tool: what the agent may read, what it may write, which actions need a human to approve, and how each action is recorded. Start from denial and add access only where the role requires it. The OWASP authorization guidance makes the same basic point in software terms: access should be checked against an explicit policy on each request, not assumed from context.

This matters more for language agents than for ordinary software, because an agent can be steered into requesting actions it should not take. A message inside a customer email, a web page the agent reads, or a document in the memory store can contain instructions written to change its behavior. The control against that is the permission model, not the wording of the prompt. Good prompts help, but they are not a boundary.

A practical sequence:

• List every system the agent could touch, including indirect routes such as shared folders and inboxes.
• For each system, mark read, write or none, and choose the narrowest scope that serves the role.
• Mark as approval-required any action that changes a customer record, sends an external message, spends money or deletes data.
• Name the person who approves each class of action and the time they have to respond.
• Give the agent its own identity so every action appears in the log under that identity, not under a shared account.
• Set a review date. The steps for that review are described in How to Run a Permission Review for Your AI Agents, Step by Step.

Permissions also need a revocation path. Write down how access is removed, who can remove it, and how quickly it takes effect. A permission that cannot be withdrawn quickly is a risk even when it is never used.

Design the evaluation plan around one success criterion

An evaluation plan turns the question did the agent do well into a test that someone else can repeat. Begin with one observable success criterion. For the distributor above, that might be the share of order-status answers that match the ERP record and cite the policy clause they relied on, measured against a fixed set of past questions. A criterion of that kind can be checked without anyone relying on an impression of the output.

The plan should contain four parts. First, a test set drawn from real past cases, with the expected outcome written down. Second, a regression run that repeats the same tests after every change to prompts, tools or the underlying model. Third, a threshold agreed before the build, so that a result below it triggers a decision rather than a debate. Fourth, a weekly sample of live conversations reviewed by a person. Traces of each tool call, recorded with consistent fields, show where a failure began. The OpenTelemetry observability primer describes the general practice of collecting traces, metrics and logs so that a system can be understood from its outputs.

Choosing the criterion is often harder than building the test. The guide How to Define Success Criteria for an AI Agent Pilot explains how to pick one that matters to the business rather than one that is simply easy to count.

Plan the handover so your team can run it without the consultant

A handover is complete when your team can answer routine questions and handle a bad day without calling the consultant. That requires a runbook for normal operation and for the most likely incidents, an access inventory listing every credential and its holder, versioned copies of the instructions and prompts, a list of memory sources with their owners, and a backup and restore procedure that has actually been tested. Backups that have never been restored are a hope, not a plan.

The handover also needs a change path. Ongoing edits should move through a visible request, review and approval sequence rather than being made directly in production. The steps for that sequence are set out in How to Request and Approve Changes to a Managed AI Agent.

Be Human designs, implements and operates personalized AI infrastructure for companies, with agents that keep their identity, memory, channels, tools, permissions and operating context under human control. A first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The handover records each of those choices in documents your team keeps, so the setup stays visible to the company.

How to check a proposal before you sign

Before you sign with any consultant, read the proposal against a short list:

• Does it name one role, and state what the agent will not do?
• Are permissions written per system, with approval points and a revocation path?
• Is the success criterion measurable without relying on the consultant's own judgment?
• Who owns the memory, the logs and the instructions, and can you export them in a usable form?
• If the work stops, what remains in your hands, and in what format?
• Does it use a recognized risk vocabulary, such as the NIST AI Risk Management Framework, when describing how risks are identified and reviewed?

A proposal that answers these questions in concrete terms deserves serious comparison. One that answers with forecasts, general promises or long lists of capabilities is asking you to trust the outlook rather than the work.

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

Frequently asked questions

Is a superintelligence consultant different from an AI consultant? The term is used loosely, and a consultant who uses it should still deliver the same concrete artifacts as any serious AI implementation advisor. The useful question is whether the work produces an operating layer your company can inspect today. The label on the proposal matters less than the deliverables listed in it.

Should my company wait for more capable models before hiring a consultant? Waiting rarely removes the need for the basics. A layer map, a permission model and a clear success criterion are needed whichever model is used, and they make later model changes easier to absorb. A first role can start now with its scope kept narrow.

How long should a handover take to produce? The effort depends on how many systems the agent touches and how many people will operate it. The essential parts are the runbook, the access inventory and the restore test, and a proposal should state when each will be delivered. Ask to see a draft of the handover early in the engagement, not only at the end.

Can a small company use this checklist? Yes. A small team can apply the same five groups at a smaller scale, with one owner covering several layers. The main requirement is that someone is named for each permission and each decision, even when that person has many other responsibilities.

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