Personalized AI infrastructure
Superintelligence Company or AI Consultancy: How to Tell Apart
A superintelligence company is not one that built ASI. Seven buyer questions to tell a lasting company intelligence layer from slides or one-off scripts.

A superintelligence company, in any sense a buyer can verify, is not a firm that has built superintelligence, because no vendor can honestly claim that. It is a firm that builds and operates a lasting intelligence layer inside your company: memory, governed tools, clear permissions and recurring evaluation that keep working as models change. An AI consultancy that delivers slides or one-off automations can still be useful, but it leaves you with documents and scripts rather than a layer someone is accountable for running.
Key takeaways
- Judge the firm by what remains in your company after the engagement: memory, tools, permissions and tests, or only a deck and a few scripts.
- Ask who operates the work after launch. A lasting layer needs a named owner, monitoring and a change process.
- Treat any claim of superintelligence as a prompt for evidence, not a reason to buy. Value comes from useful roles with observable success criteria.
- Portability protects you. Your knowledge, configurations and logs should be exportable and should survive a change of model or vendor.
- Compare proposals on the same small, real task and score them on the same evidence.
What should a superintelligence company mean to a buyer?
The phrase is used in two ways, and mixing them up is the first source of confusion.
In research, superintelligence describes a hypothetical system that outperforms people across nearly every intellectual task. It is not something anyone can sell you today, and a vendor who implies otherwise is telling you about their marketing, not their product. In business conversations the phrase more often points to something narrower and more practical: a company intelligence layer, meaning connected agents, memory, tools and rules that make your organization's knowledge usable and that get better as the underlying models get better.
The second meaning is the one you can buy, inspect and test. The article Build a Company Superintelligence Layer That Improves With Models describes that layer in more depth.
So the useful question is not whether a firm calls itself a superintelligence company. It is whether the firm builds something that stays, improves and remains under your control. A consultancy can answer yes to that, and a firm carrying the label can answer no.
What does a typical consultancy engagement leave behind?
Consultancies do valuable work. They help leaders choose where to start, map processes, align stakeholders and write down a direction. The risk is a mismatch between what you needed and what you received. If you needed a working role inside the company, a strategy document and a prototype do not get you there.
A typical one-off engagement leaves a report, a ranked list of use cases and a handful of automations. Those automations often run on the credentials of whoever built them, keep their instructions somewhere only that person knows, and have no test that tells you when they drift. They work until a connected tool changes, a model update shifts behavior or the builder moves on. Then someone has to rediscover how they worked.
A lasting layer is a different kind of deliverable. It is a set of parts that keep running and keep being checked:
- A defined role with a clear purpose, boundaries and an accountable human owner.
- Memory built from company sources, each with an owner and a way to correct it.
- Tools and integrations connected with scoped permissions, not a shared administrator login.
- Approval boundaries that say what the agent may do alone and what waits for a person.
- Monitoring and recurring evaluation, so behavior is observed and not assumed.
- A change process that records who asked for what and who approved it.
None of these parts is exotic on its own. What sets a layer apart is that every part has an owner, a record and a way to change safely. Public engineering guidance on agents, such as Anthropic's writing on building effective agents, tends to favor simple, composable components that you can observe over elaborate ones. Warning signs worth knowing before you sign are collected in Red Flags When Hiring an AI Implementation Partner.
Seven questions that separate a lasting layer from a project
These questions work whatever the firm calls itself. Each one has a good answer and a weak answer, and the difference is usually obvious when you ask for it in writing.
- Who owns the memory and configuration, and can you export them in a usable format? A good answer says the company owns them and they are documented and portable. A weak answer says they live in the vendor's workspace.
- Which single role will the first agent hold, and how will you see that it works? A good answer names one role and one outcome you can observe. A weak answer talks about transformation in general terms.
- What can the agent read, write and send, and who approved each permission? A good answer is a written list, scoped per tool, with the least access needed. A weak answer is a shared login.
- How do you test behavior after a model, instruction or tool change? A good answer describes an evaluation set built from your real tasks and rerun after changes. A weak answer is that someone will check by hand.
- What happens when something goes wrong? A good answer includes monitoring, an incident path and a way to pause the agent quickly. A weak answer is to contact support.
- Who runs this after launch, and how are changes requested and approved? A good answer names operators and keeps a change log. A weak answer treats launch as the end of the work.
- What happens to the work if we leave or switch models? A good answer shows the knowledge and tests carrying over. A weak answer means starting again.
Ask to see artifacts, not descriptions: a sample permission list, an evaluation report or a change log with names removed. Firms that operate real systems have these. Firms that sell slides will describe them. Concepts behind the artifacts are well documented: the OpenTelemetry observability primer explains logs, metrics and traces, and OWASP's authorization guidance explains least privilege. For a wider checklist aimed at vendors who lean on big claims, read Superintelligence Vendor Evaluation: Evidence, Questions, Red Flags.
What does the difference look like in an illustrative scenario?
Illustrative scenario: a regional distribution company wants help with delivery exceptions, the late or damaged shipments that customers ask about by email. Two firms send proposals. This example is invented for explanation and describes no real engagement.
The first proposal includes a discovery workshop, a roadmap deck and a set of automations that draft reply emails from templates. It is clear and easy to start. After delivery, the templates live in one employee's account, and nobody has defined what a good reply is.
The second proposal defines one role, an exception coordinator. It names the sources the role may read, such as order records and the returns policy, and the actions it may take, such as drafting a reply and flagging a case. Anything that changes a delivery commitment waits for a person's approval. The success criterion is observable: every drafted reply cites the order record it used, and a reviewer can see which cases the agent escalated. Past exceptions are kept as a test set and replayed after each change, and a named operator reviews logs on a schedule.
Neither proposal is wrong by default. A short decision guide:
- Choose strategy and slides when you do not yet know which process matters and nobody can name the owner of the task.
- Choose a one-off automation when the task is stable, narrow, rule-based and unlikely to change.
- Choose a lasting layer when the work depends on company knowledge, shifts with context and needs judgment within approval limits.
The stage you are in also matters. Proof of Concept, Pilot or Production explains what each stage must prove before you commit further.
How can you compare firms in a week?
You do not need a long procurement process to see the difference. A short, structured comparison is enough, and it works the same way for a consultancy, a specialist firm or a freelancer.
- Pick one real task with a clear owner and a way to tell whether it was done well.
- Send the same short brief to every firm and ask for a written scope that names the role, data sources, tools, approvals and success criterion.
- Ask each firm for the artifacts behind the seven questions: a sample permission list, the evaluation approach, the change process and the exit terms.
- Have your technical lead or an outside reviewer check how credentials are held and who can revoke access.
- Ask for references you can speak to directly, and treat unnamed or unverifiable results with caution.
- Score every proposal on one sheet with the same rows: ownership, scope, permissions, evaluation, operation and portability.
- Prefer a bounded first engagement over a broad commitment, so you learn how the firm works before you depend on it.
If your team needs a shared vocabulary for the risk conversation, the NIST AI Risk Management Framework organizes the work into governing, mapping, measuring and managing risk. It is a neutral reference that a vendor and a buyer can both use. The score sheet then gives you a defensible reason for your choice, whichever way it falls.
How does Be Human's managed approach handle this?
Be Human designs, implements and operates personalized AI infrastructure for companies: 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, the approval boundaries and an observable success criterion. Managed operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The service is remote and available in English and Portuguese. Be Human does not claim to have built superintelligence; the aim is a company layer that you own, can inspect and can improve as models improve.
If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.
Frequently asked questions
Is there a company that has actually built superintelligence? No vendor has shown verifiable evidence of it, and you should treat such claims as marketing until proven otherwise. What you can evaluate today is what a firm delivers: working roles, memory, tools, permissions and tests inside your company.
Can a consultancy also build a lasting intelligence layer? Yes, and some do. The label does not decide it; the answers to the seven questions do. If a consultancy can show who operates the work after launch, how changes are tested and how you can leave with your knowledge intact, it is doing the work of a layer builder.
Do I need a lasting layer if I only want one automation? Not always. A narrow, stable, rule-based task may be well served by a simple automation. Even then, keep the credentials under company control, document how it works and write down who owns it, so the script does not become a hidden dependency.
What should I ask a firm that says its agents improve themselves? Ask what exactly changes, who approves the change and how it is tested before it reaches production. Healthy improvement is a controlled change with a record and an evaluation, not silent drift. If the firm cannot show the change log and the test results, the improvement is a claim and not a process.
Your next step
See where an AI agent fits in your company first.
Take the free Be Human AI diagnostic. A few questions about your work show which task to hand to an agent first, what it needs to know and where a person approves.
Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.


