Superintelligence Consulting: How to Choose a Partner Without Hype

Superintelligence Consulting: How to Choose a Partner Without Hype

To choose a superintelligence consulting partner without falling for hype, ignore the label and judge what the partner delivers: a mapped process, a limited scope, a primary source behind every technical claim, and a pilot with an agreed metric before any expansion. Superintelligence, in the technical sense, is a hypothetical concept, not a product you can hire. What a company actually buys is today's AI systems, with known limits, running on real processes.

Key takeaways

• Superintelligence is a research hypothesis and a topic of public debate. Anyone selling it as a ready-made service is using a marketing label, not describing a deliverable.
• Good partners talk about processes, data, permissions, evaluation and accountability, not promises of unlimited intelligence.
• Every technical claim should have a primary source: official documentation from the model provider, engineering articles, standards and guidance from recognized bodies.
• The first contract should be a small pilot with one real workflow, logs, a written success criterion and a clear option to stop.
• At the end of the project, your team must know how to operate, adjust and shut down what was built.

What is a consultancy selling when it uses the word superintelligence?

Three different things show up under the same label, and it is worth separating them in the first conversation.

The first is a concept: the idea of a system that would outperform humans at practically every intellectual task. It is a legitimate subject for research, policy and philosophy. It is not something a mid-sized company installs in its operation. If you want to understand how the terms differ, read the difference between AGI, ASI and AI agents.

The second is a commercial narrative: using the word as a shortcut to say the solution is very advanced, without explaining how. This is where the biggest buying risks live, because the promise is broad and the deliverable is vague.

The third is a real service under a different name: process diagnosis, AI agent design, system integration, evaluation and monitoring. That service is useful and can be assessed with objective criteria. The buyer's job is to find out which of the three is on the table.

One simple question helps: if we remove the word superintelligence from the proposal, what concrete content is left? If a clear scope remains, good. If only adjectives remain, the conversation ends there.

Which red flags show up in the proposal?

No single sign condemns a vendor, but the set is usually revealing. Be wary when the proposal includes:

• A guaranteed-result promise, or a claim that AI will replace entire departments without describing how work is split between people and the system.
• Vague language about capabilities, such as general intelligence, total autonomy or unlimited reasoning, with no examples of specific tasks.
• No sources: no reference to model documentation, engineering articles or risk management guidance.
• Case studies without context, numbers without an origin, or logos displayed with no way to know what was actually done.
• An open scope, such as transform the company with AI, with no first bounded workflow.
• Silence on personal data, legal basis and international transfer, or an answer that LGPD is a detail to sort out later.
• No evaluation plan: they do not say how they will measure whether the system got things right or wrong.
• Agents with broad access to systems, no restricted permissions, no decision logs and no human approval for sensitive actions.
• Hidden dependency: only the consultant knows how to run it, and final documentation is not planned.

Two of these signs already justify a harder conversation. Four or more suggest the label is doing the work the proposal should be doing.

What should you ask in the first meeting?

Good questions are specific and hard to answer with a slogan. Bring this list to the meeting and write down the answers:

• Which exact process do we start with, and who is responsible for it today?
• How will the current state be measured before anything changes?
• Which data will the system access, and which data stays out of reach by our decision?
• Which actions can the agent take on its own, and which require human approval?
• Where are the records of each decision kept, and who can audit them?
• How do you evaluate answer quality before going to production?
• Which official documentation supports the technical choices made in the architecture?
• What happens if the pilot result is poor? How do we stop, and what do we keep?
• Who operates the system after handover, and what do we need to learn to do it?
• Does any of our data leave Brazil? If so, under which legal basis and with which safeguards?

Watch the behavior, not only the content. A good partner accepts uncomfortable questions, admits what they do not know and separates documented fact from their own opinion. Someone who gets irritated by a question about sources probably does not have any.

How do you separate documentation, experience and hypothesis?

A useful editorial rule also works as a buying rule: every claim a consultant makes falls into one of three categories, and they should say which one.

Official documentation is what the model or platform provider publishes about its own product: limits, behavior, ways of use. Guidance from reference bodies belongs here too. Examples of reading any buyer can ask the partner about: the NIST AI Risk Management Framework, for structuring risk management, and the OWASP Top 10 for LLM applications, for the most common security risks.

Implementation experience is what the consultant learned building and running systems. It is valuable, but it should be presented as experience, not turned into universal law, and without citing third-party results the consultant cannot show.

A hypothesis is something not yet tested in your context. Saying an agent should reduce rework in a certain workflow is a hypothesis until the pilot measures it. Hypotheses are fine. The problem is selling them as fact.

Ask for the proposal to use this separation. For agent architecture, for example, the engineering article Building effective agents from Anthropic argues for starting with the simplest solutions and adding complexity only when needed. A partner who proposes a complex system from day one should explain why they depart from that guidance.

What does a measurable pilot look like?

The pilot is the best filter against hype, because a label does not survive a real workflow with logs. A lean design follows these steps:

• Pick a single workflow with a clear start and end and enough volume to observe, such as triaging quote requests or answering frequent questions on WhatsApp.
• Record the current state: response time, rework, recurring errors, points where the team gets stuck. Without this starting point, no improvement can be demonstrated.
• Define the success metric in one plain sentence, written and signed by both sides before the start.
• Limit data and actions: what the system reads, what it writes, what it never touches and what depends on human approval.
• Build a set of test cases with real situations and hard cases, and use it to evaluate before and during the pilot. The Anthropic article Demystifying evals for AI agents describes how to think about this evaluation.
• Test in a controlled environment before touching customers. See how in testing AI agents with mock tools and a sandbox.
• Turn on decision logs from day one, so you can review mistakes and successes with evidence.
• At the end, bring the parties together and choose one of three outcomes: expand, adjust or stop. Stopping must be a legitimate outcome, with no contractual embarrassment.

The central point is that the pilot does not prove the AI is intelligent. It proves, or fails to prove, that a specific workflow improved according to a metric you chose.

Illustrative scenario: two proposals for the same problem

Imagine, as an illustrative scenario, a distributor that receives orders and questions over WhatsApp and wants to shorten the support queue. Two consultancies submit proposals.

The first promises an enterprise superintelligence platform that will learn the whole business and handle sales, support and finance. It does not detail the data accessed, does not describe evaluation and proposes a broad contract from the start.

The second proposes mapping how support works today, choosing a single request type for the pilot, limiting the agent to checking order status and answering already documented questions, handing everything else to a person and logging every decision. It defines how the team will review a sample of conversations and what success means. It cites the documentation of the providers used and states where data is processed.

The second proposal looks less ambitious, and that is exactly what makes it assessable. If it works, expansion is an informed decision. If it does not, the company lost little and learned a lot. For the channel itself, it helps to know the rules of the WhatsApp 24 hour customer service window before closing the scope.

Data, LGPD and accountability: what cannot wait

Many consultancies treat data protection as a final step. In AI projects, it shapes the architecture. Before signing, demand clarity on four points.

First, which personal data enters the system and under which legal basis. Second, where processing happens and whether data is sent abroad, a topic covered in international data transfer under LGPD when using AI providers. Third, who is responsible for what among your company, the consultant and the model and platform providers. Fourth, how the system handles decisions that affect people and how they can request review.

The Brazilian regulatory picture is still moving. Instead of betting on predictions, ask the partner for a monitoring plan, follow the publications of the ANPD (Brazil's data protection authority) yourself, and read what your company should watch in Brazil's AI regulation. A serious consultant does not promise guaranteed compliance. They promise a documented process.

Security belongs here too. Agents that read messages from third parties are exposed to malicious instructions hidden in the text. Ask how the partner handles this risk (see prompt injection protection for AI agents) and which permissions the agent receives. The answer should talk about least privilege, restricted tools and human approval, not trust in the model.

How the map, limit, pilot and transfer method applies

The method Juan Carlo uses to organize this kind of decision has four steps. Map: understand the current process and record the baseline. Limit: define which data and actions the system may use. Pilot: run one real workflow with logs and an agreed metric. Transfer: hand over documentation and knowledge so the company can decide to expand, adjust or stop. Managed operation, when it makes sense, is delivered through Be Human (be-human.ai). You can find more detail in how Juan Carlo works with companies.

Regardless of whom you hire, use these four steps as a yardstick. If a proposal skips mapping, does not limit access, has no pilot or has no handover, an essential stage is missing.

Frequently asked questions

Is there such a thing as real superintelligence consulting? Superintelligence is a hypothetical concept, and no partner can deliver it as a product. What exists are AI consultancies that implement current systems, with real capabilities and known limits. Evaluate the service by what is delivered, not by its name.

Is it worth hiring someone who uses that term in their marketing? It is not necessarily a problem, as long as the proposal stands without the label. Ask for scope, sources, an evaluation plan and a limited pilot. If the answers are concrete, the term is just style. If they are evasive, it is a red flag.

How long should a pilot last? Long enough to observe the chosen workflow in varied situations, including hard cases, and short enough that the decision does not drag on. Set the period together with the metric, before starting. What matters is that the end of the pilot produces a clear decision: expand, adjust or stop.

What should I receive at the end of the project? You should receive the workflow documentation, the access and permission rules, the criteria and test cases used in evaluation, the decision logs and an operating guide for your team. It should also be clear who maintains the system and how it is shut down. If any of this depends only on the consultant, the handover is incomplete.

Sources

• NIST: AI Risk Management Framework
• OWASP: Top 10 for LLM Applications
• Anthropic: Building effective agents
• Anthropic: Demystifying evals for AI agents