Superintelligence Vendor Claims: How to Spot Overstated Promises

A superintelligence vendor claim is a statement about general machine capability that a buyer cannot test today. A claim worth budget can be reduced to a named task, a measured result, and a clear owner for errors. If a pitch cannot be reduced that way, treat the word superintelligence as marketing, not as a specification.

Key takeaways

• Ask every vendor claim to name one task, its inputs, its outputs and the measurement used to judge it.
• Treat the word superintelligence as undefined until the vendor defines it in operational terms you can check.
• Require evidence you can rerun yourself, not only a demonstration chosen by the seller.
• Read approval boundaries, permissions and rollback before you read any performance statement.
• Start with one bounded role and a success criterion you wrote down before the first meeting.

Why superintelligence is not a testable claim

The term describes a level of general capability beyond human performance across most cognitive work. No product on the market can be verified against that definition during a procurement meeting, and no vendor can deliver a demonstration that proves it. When a pitch uses the word, the sentence usually does one of three things: it sets a long-term direction, it borrows credibility from research the buyer has not read, or it implies that the product will keep improving without any work from the buyer.

None of those is a capability you can write into a contract or measure in a quarterly review. Your job is not to debate the definition. Your job is to ask what the sentence means for a specific piece of work your team does this week.

Separating capability claims from marketing language

A capability claim has three parts: a task, a condition, and a measure. An example is a claim that an agent drafts first replies to supplier questions about invoices, using only the approved payment policy, and routes any dispute above a defined amount to a named person. Marketing language has none of those parts. It says the system is intelligent, learns from everything, or works at human level, and it leaves the buyer to fill in what that means.

Some phrases deserve a pause on sight:

• "Fully autonomous" with no list of actions that still need a person.
• "Learns from your business" with no description of which data is read, stored, or reused.
• "Human-level" or "expert-level" with no task named.
• "Enterprise-grade" with no reference to access controls, logs, or review steps.
• "Proprietary model" with no explanation of what the model does in your workflow and what it does not.

None of these phrases is automatically false. Each one is a request for a sentence that can be checked.

A checklist for every superintelligence pitch

Use these questions in the first meeting and again before any contract discussion. Write the answers down, and mark any question the vendor answers only with a general statement.

• Which exact task does this claim cover, and what is explicitly out of scope?
• What inputs does the system read, where do they come from, and who owns them?
• What output counts as correct, and who on our side decides that?
• Which test set or sample produced this result, and can we run our own cases through it?
• How does the system perform on the difficult cases that matter most to us, and how was that measured?
• Which actions can it take without approval, and which require a named person to confirm?
• How are its permissions granted, reviewed, and revoked?
• What happens to our documents, memory, prompts, and logs if we stop working together?
• Who is accountable when an output causes a financial, legal, or customer loss?

If the vendor cannot answer the first three questions, the rest of the conversation is premature.

How to test a claim with your own cases

Demonstrations, case studies, and public benchmark scores are all useful, but none of them tells you how a system behaves on your process, with your data, under your rules. Benchmarks measure general tasks. Case studies are selected by the party that wants the sale. Ask instead for a repeatable test built from your own past work, including the messy cases that did not go smoothly the first time. Public guidance on agent evaluation, such as the material from Anthropic linked in the sources, treats evaluation as a set of defined tasks with graded outcomes rather than a single impressive run. Apply the same logic to vendor claims. For a deeper method on reading published results, see how to evaluate AI case studies without being misled.

Illustrative scenario (not a client case): A regional distributor is offered an agent that will "handle procurement intelligently." The operations lead asks for the list of purchase order types in scope and a set of past exception cases, including the ones staff still discuss. The vendor runs the cases in a sandbox in front of the team. Several results fail in ways the demo never showed, and the scope is narrowed to order status questions before any price or contract term is discussed. The claim did not disappear, but it became something the company could evaluate.

Check permissions and recovery before performance

A capability is only as safe as the access it is given. An agent that reads email, a shared drive, and a customer ticket queue can be influenced by any text it reads, including text written by someone outside your company. The OWASP Top 10 for LLM Applications describes this class of risk, and the OWASP authorization guidance explains why each tool should receive only the access the task needs. Ask the vendor which credentials the agent uses, whether those credentials are scoped to read or to write, which actions require a human approval step, and how the agent is stopped if its behavior changes.

Performance claims deserve less weight than these answers. A system that performs well and has broad, unreviewed access is a larger exposure than a narrower system whose boundaries are written, tested, and reviewed on a schedule. For the review routine itself, see how to run a permission review for your AI agents, step by step.

A step-by-step plan before you sign

Use this sequence to turn a broad pitch into a decision you can defend internally:

• Write the single task and the success criterion in plain sentences, before the vendor presents.
• Gather a sample of real past cases, including difficult ones, with the correct answer where it is known.
• Ask the vendor to run that sample and return the actual outputs, not a summary of them.
• Score the outputs with someone who knows the work, using the criterion written in the first step.
• List every action the system would take and assign each one an approval level.
• Review what the vendor says about data retention, memory, logs, and exit before a second meeting.
• Decide to proceed to a bounded pilot, narrow the scope, or stop. A stopped pilot should still leave useful records. The guidance on how to define success criteria for an AI agent pilot can help you set the threshold before the test begins.

A decision guide for the outcome of this sequence is simple. If the claim survives the sample and the approval map, proceed to a bounded pilot. If it survives only in part, narrow the task. If the vendor resists the test itself, stop.

How Be Human handles claims that cannot yet be verified

Be Human designs and operates personalized AI agents with the scope written down from the start: one defined role, the memory and tools that role needs, the approval boundaries for each action, and an observable success criterion agreed before launch. Managed operations then include monitoring, recurring evaluations, integration maintenance, permission review, and incident response, so a capability is re-tested against real work after deployment rather than accepted once at signing. Be Human does not promise future capability levels. It makes the current scope, the evidence, and the review schedule visible to the business owner who has to decide.

When the pitch is still too broad to test, the first useful step is to find one narrow task where a measurable result is possible. Take the free Be Human AI diagnostic to identify the first task worth handing to an agent.

Frequently asked questions

Is a superintelligence vendor claim ever worth considering? Yes, when the vendor translates the claim into a bounded task with inputs, outputs, a measure, and a named owner for errors. The word itself does not justify a budget, but a specific workflow with a repeatable test can. Treat the broad claim as context and the narrow task as the decision.

What is the single most useful question to ask a vendor? Ask which exact task the claim covers and what the system does on the cases where it fails. A vendor that can answer both precisely is describing a product you can evaluate. A vendor that answers with general statements about intelligence is asking you to accept the claim without evidence.

Do benchmark scores prove that a vendor's system will work in our company? No, benchmark scores measure performance on general tasks chosen by the people who built the benchmark. They can be a rough signal of model quality, but they do not show how the system handles your documents, your permissions, or your exceptions. Run your own sample of past cases before treating any published score as relevant.

Who inside our company should review vendor claims before we commit? The business owner of the workflow should own the success criterion, a person who does the work should score the outputs, and whoever manages security or access should review permissions and logs. Keeping these roles separate prevents the vendor's demonstration from being the only judge of its own result.

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