Superintelligence Vendor Evaluation: Evidence, Questions, Red Flags

To evaluate a vendor that promises superintelligence, set the word aside and judge what the vendor will actually deliver: one defined role, behavior you can observe on your own work, clear permissions, and an honest account of what the vendor does not control. Superintelligence describes a possible level of capability, not a product feature, so every claim must become something you can inspect, measure and stop. If a claim cannot be turned into a test, treat it as marketing.

Key takeaways

• Superintelligence in a pitch is a claim about direction, not evidence. Ask what exists today, in production, under someone's operational responsibility.
• Strong vendors can name the role, the tools, the memory, the approval boundaries and the success criterion in plain language.
• Evidence that matters is evidence on your data and your workflow, produced under conditions you can observe, not demonstrations built for the sales call.
• The most reliable red flags are vagueness about who operates the system, refusal to define limits, and promises that cannot be tested or reversed.
• A short, bounded trial with a written exit is a better filter than any presentation.

What does a vendor actually mean by superintelligence?

The word is used in at least three different ways, and a buyer should know which one is on the table before any other question.

The first meaning is a claim about a model: the vendor resells or wraps a general-purpose model and describes it as approaching or exceeding human expertise. The second is a claim about the future: the vendor believes capability will keep rising and positions its product as the way to be ready. The third is a claim about a system: the vendor builds a layer of memory, tools, permissions and evaluation around models, so the company benefits as models improve. Our guide to building a company superintelligence layer describes that third idea in more detail.

Only the third is something a business can buy and operate. The first is a property of a model the vendor may not control. The second is a forecast, and forecasts are not deliverables. When a pitch slides between all three without marking the transitions, you are being asked to pay for the second while being shown the first.

A useful opening request is simple: ask the vendor to restate the pitch without the word superintelligence. What remains is the real offer. If what remains is a clear role with defined tasks, tools and limits, you have something to evaluate. If it collapses into general phrases about transformation, you have learned something important early.

What evidence should you ask a vendor to show?

Evidence has a hierarchy. Treat anything higher on this list as worth more than anything lower.

• Behavior on your own material: the vendor runs a bounded task on a sample of your real documents, tickets or records, with you watching, and shows the inputs, outputs and mistakes.
• A written evaluation method: a description of how the vendor checks quality over time, including the test cases, who reviews failures and what happens when results drop. Published engineering guidance on agent evaluations, such as Anthropic's material on evals for agents, shows what a serious method looks like.
• Operational records: how incidents were handled, how changes were approved, how permissions were reviewed. Redacted examples are enough.
• Architecture documentation: where data is stored, which systems the agent can read or write, how credentials are held, and how the agent is stopped.
• References you can speak to directly, about the situation they were in, not only a summary of outcomes.
• Case studies, last. They are the easiest to polish and the hardest to verify. Our article on how to read AI case studies lists the details that separate a real account from a promotional one.

Notice what is absent: benchmark scores quoted without context, demonstrations on prepared data, and testimonials without a reachable person. Benchmarks measure a model on a fixed task set. They do not tell you whether the system will handle your exceptions, your permissions or your tone with customers.

If the vendor can only offer material from the lower end of this list, that does not make the vendor dishonest, but it should lower your confidence and shorten the commitment you are willing to make.

Which questions separate an operator from a salesperson?

Good questions are specific enough that a vague answer is obvious. Put these to the vendor in writing and keep the answers.

• What is the single role this system would perform for us, and what is it explicitly not allowed to do?
• Which of our systems will it read, which will it write to, and who approves each permission?
• What does it remember between sessions, where is that memory stored, and how do we inspect or delete it?
• Who operates it day to day: your staff, a partner, or a third-party platform? Who answers when something fails outside business hours? (See reseller or operator for why this matters.)
• Which model or models does it depend on, and what happens to our setup if you change or lose access to one?
• How do you detect that quality has dropped, and what do you show us when it does?
• How do you handle hostile or manipulated input, such as instructions hidden in an email or document? The OWASP list of risks for language model applications is a fair reference for what a prepared vendor should already be discussing.
• What can we export if we leave, and in what form? The article on avoiding AI vendor lock-in covers the practical checks.
• What is the success criterion for the first engagement, and who on our side signs off that it has been met?

Watch how the vendor answers, not only what it says. An operator tends to respond with boundaries, trade-offs and things it does not yet know. A salesperson tends to respond with capability and enthusiasm. Both can be sincere, but only the first pattern helps you decide.

Note also whether the vendor asks you questions. A serious provider will want to understand your workflow, your data quality, your approval chain and your tolerance for error before proposing anything.

Which red flags should pause the conversation?

No single item below proves a vendor is unsuitable. Several together should slow you down.

• The pitch relies on the word superintelligence but cannot name one role, one workflow or one observable result.
• The vendor describes the system as autonomous without describing the approval boundaries around it.
• No one can say who is responsible for monitoring, incident response and permission review after launch.
• Evidence is limited to demonstrations on the vendor's own data, or to results that cannot be traced to a reachable reference.
• The vendor discourages a bounded trial and pushes for a long commitment first.
• Contract language is silent on data return, deletion, model changes and ending the engagement. The guide to the AI agent statement of work shows what those sections should contain.
• The system needs broad access to company systems from day one, with no staged expansion.
• Claims about the future are offered as reasons to skip evaluation, for example that the system will improve on its own so testing is unnecessary.
• Risk is treated as someone else's problem. A vendor who cannot discuss failure modes has not looked for them. Frameworks such as the NIST AI Risk Management Framework give you a neutral vocabulary for pressing on this.

The last red flag is the most telling. Any capable system fails sometimes. A vendor who is comfortable describing how its system fails, how failures are caught and how they are reversed is showing the kind of maturity that actually protects you.

How do you run the evaluation, step by step?

The plan below fits a mid-sized company and does not need a technical team to start. For a wider treatment of vendor testing, see how to test an AI vendor's claims before committing.

• Step one: translate the pitch. Write one paragraph describing the role the vendor proposes, without the word superintelligence. Ask the vendor to confirm it in writing.
• Step two: choose one workflow with a clear owner, real inputs and a result a person can check. Avoid anything where an error would be hard to reverse.
• Step three: define the success criterion before the trial. Decide what good looks like, what is unacceptable, and who judges. Without this, every outcome can be described as a success.
• Step four: set permissions at the minimum. Read access first, write access only where an approval step exists. Record who granted each permission.
• Step five: run a bounded trial on real material, with a sample you hold back to test whether results hold on unseen cases.
• Step six: review failures with the vendor. Note how quickly they are acknowledged, how they are explained and whether the fix is a change you can see and approve.
• Step seven: test the exit. Ask for an export of what the system holds about your company and confirm you can read it without the vendor.
• Step eight: decide using written evidence. Compare the result with the criterion from step three, not with the impression left by the presentations.

The stage of the project matters too. A trial proves different things from a pilot, and a pilot proves different things from production. The article on proof of concept, pilot or production lays out what each stage must show before you move on.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a real engagement.

A distribution company receives two proposals to help its operations team handle supplier correspondence. The first vendor opens with a presentation about superintelligent systems that will run the whole back office. It offers a polished demonstration, a long-term agreement and broad access to the email system and the order platform from the start.

The second vendor talks about one role: drafting replies to routine supplier queries and flagging anything involving a change to an order. It proposes read access to one shared inbox, drafts that a named person approves before sending, a written list of what the agent must never do, and a short trial against a sample of past messages the vendor has not seen.

The operations lead asks both vendors the question about who operates the system and who responds to a failure. The first answers that the platform is highly reliable. The second names a person, an escalation path and a process for pausing the agent.

Neither vendor used a different underlying technology. The difference is that the second one made its claims testable, bounded the risk and described its own limits. The company can learn from the second trial even if it ends in a no. From the first, it could only learn after committing.

How does a managed approach handle this problem?

Be Human treats the evaluation as part of the service rather than a hurdle before it. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, all written down before anything is switched on. Be Human then operates the agent remotely, with monitoring, recurring evaluations, integration maintenance, permission review and incident response, so that the answer to who is responsible is a named process rather than an assumption. Changes go through a controlled path the client can see, and the company keeps human control over identity, memory, channels, tools and permissions. For a closer look at the recurring work, see what managed AI services include.

Frequently asked questions

Is any vendor really delivering superintelligence today? Treat the claim as unproven unless the vendor can show, on your work, what the system does and under what controls. Capability is a moving subject and you do not need to settle it to buy well. Buy a defined role you can test, and let model improvements arrive as a benefit rather than a promise.

Should we avoid vendors who use the word at all? Not automatically. Some vendors use it as shorthand for a long-term direction while still offering a clear, bounded service. Judge the offer behind the word: a named role, observable evidence, stated limits and a way out.

Who inside the company should lead the evaluation? Assign one accountable owner from the business side, ideally the leader of the function the agent will serve, with support from whoever manages security and data. A named sponsor keeps decisions moving and prevents the evaluation from becoming a technical exercise without a business question.

What if the vendor refuses a bounded trial? Ask why, and listen for a concrete reason such as data access that must be arranged first. If the reason is only that the system works better at scale, or that a trial would not show its value, consider that a strong signal to wait. A good vendor can show something real in a small, reversible setting.

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