How to Choose a Superintelligence Company Partner You Can Trust

The best superintelligence company partner is one who helps you build a layer you own and can inspect, not one who promises a finished intelligence. Judge candidates on three things: demonstrated skill in memory, tools, permissions and evaluation; written handover terms that keep your knowledge portable; and a habit of saying plainly what the system cannot yet do. A partner who is vague on any of the three is a risk, however polished the demo looks.

Key takeaways

• Treat superintelligence as a direction for your company's operating infrastructure, not a product that arrives in a box.
• Ask the partner to show working capability in memory, tool access, permissions, evaluation and monitoring, not slides about models.
• Put handover terms in writing before work starts: who owns prompts, memory, configurations, evaluation sets and logs, and how you get them back.
• Prefer partners who name limits, failures and unknowns early. Certainty about the future is a warning sign.
• Start with one useful role and an observable success criterion, then let the partner earn a wider scope.

What are you actually asking a partner to build?

Before comparing partners, be clear about the object. A company intelligence layer is not a chatbot and not a single model. It is the set of things that let AI agents work as part of your business: a stable identity, memory of your context, the channels people use to reach them, the tools they may call, the permissions that bound those tools, and the operating context that tells them how your company works. Humans stay in control of each of those parts.

This matters because models will keep changing. The layer is what persists when they do. If you want the longer argument, Build a Company Superintelligence Layer That Improves With Models covers why the durable asset is the infrastructure around the model rather than the model itself.

So the question for a partner is not whether they can access the strongest model. Almost anyone can. The question is whether they can design, implement and operate the layer around it in a way that your team can understand, audit and eventually run without them if you choose.

A useful test of your own clarity: can you describe the first role the layer should fill in one paragraph, including what it may touch and what a good week looks like? If not, the first useful work with a partner is defining that role, and a good partner will tell you so rather than start building.

Which capabilities should a partner be able to show?

Ask for evidence of each of the following. Evidence means a walkthrough of something real, with the partner explaining the decisions they made, not a description of what is possible.

• Context and memory design: how the system stores what it should remember, how it retrieves it, what it forgets, and who can correct it. Retrieval-based approaches and fine-tuning solve different problems, and a capable partner can explain why they would choose one for your case.
• Tool design: how the agent calls your systems, with narrow, well-described tools rather than one broad connection. Anthropic's engineering guidance on writing tools for agents is a good reference for what careful tool design looks like.
• Permissions and authorization: least-privilege access, separate credentials per role, approval steps for consequential actions, and a clear record of what was granted. The OWASP authorization guidance is a fair baseline to hold them to.
• Resistance to hostile input: a plan for prompt injection, where text in an email or document tries to steer the agent. They should describe controls, not claim immunity.
• Evaluation: a repeatable set of test cases drawn from your real work, run before and after every change. Anthropic's writing on evaluating agents explains why this is the discipline that separates dependable systems from lucky ones.
• Observability: traces and logs that let someone reconstruct what the agent did and why. The OpenTelemetry observability primer describes the concepts, and a partner should be able to show their equivalent.
• Operations: monitoring, incident response, integration maintenance and a routine for reviewing permissions. Building is the smaller half of the work. Running it is the larger half.

Notice what is missing from the list: a model benchmark, a count of agents deployed, a claim of intelligence level. None of those tell you whether the system will behave well on a Tuesday when a supplier emails an odd request.

If you want a broader checklist for vetting claims, Superintelligence Vendor Evaluation: Evidence, Questions, Red Flags goes further into what counts as proof.

What should the handover terms say?

Handover is where most partnerships quietly succeed or fail, because it is discussed last and matters most. You are not planning to leave, but you should be able to. That ability is also what keeps a partner honest about quality.

Ask for these terms in the contract or statement of work:

• Ownership: your data, your memory contents, your configurations, your prompts and instructions, and your evaluation cases belong to you. Anything the partner reuses across clients should be clearly separated and described.
• Portability: a documented export of all of the above in a readable format, delivered on request and at the end of the engagement, not only at the partner's discretion.
• Documentation: an architecture description, a list of every integration and credential, and the reasoning behind major choices, kept current as the system changes.
• Access: administrative access to the accounts and infrastructure where the layer runs, held by your company, not only by the partner.
• Model flexibility: the design should allow a model to be swapped without rebuilding memory, tools and permissions.
• Recovery: a tested way to back up and restore the system, with a named owner for the test.
• Wind-down: what happens to your data and credentials when the engagement ends, including deletion and confirmation of it.

Two companion articles help here. How to Avoid AI Vendor Lock-In With Business Agents explains the structural choices that keep you free, and AI Agent Statement of Work: What to Put in It, Section by Section shows where each of these terms belongs in the document.

A partner who resists putting portability in writing is telling you something about how they expect the relationship to work.

How do you tell an honest partner from a persuasive one?

Persuasion is easy to produce in a sales process. Honesty shows up in small behaviors, and you can test for them directly.

Look for these standards:

• They separate what exists from what is planned. When describing a capability, they say whether it is running today for someone, in testing, or a direction.
• They name what the system will not do. A good proposal contains a list of exclusions and approval boundaries as concrete as the list of features.
• They explain failure. Ask what went wrong in a past engagement and what changed. A story with no failure in it is not credible.
• They resist unsupported claims about intelligence. Nobody can truthfully promise that a system will become superintelligent for your company on a schedule. Honest partners talk about building infrastructure that gets more useful as models improve, with human oversight throughout.
• They define success in observable terms. If the success criterion cannot be checked by someone on your side, it is a mood, not a criterion.
• They are willing to be tested. They accept a trial on your real, messy material instead of a curated demo.
• They use risk language you can verify. Referencing recognized frameworks such as the NIST AI Risk Management Framework is a reasonable sign they think in terms of governance, provided they can also show how it changes their actual practice.

Be equally careful with references. Customer stories are only as good as the detail behind them, and How to Evaluate AI Case Studies Without Being Misled is worth reading before you rely on any.

What does a good comparison look like? An illustrative scenario

This is an illustrative scenario, not a real engagement.

A regional distribution company has two partners on its shortlist. The first runs a smooth demo: an assistant answers questions from a small set of well-prepared documents and speaks confidently about transforming operations. The second asks to see a week of real, unfiltered requests from the customer service inbox before proposing anything.

The second partner returns with a proposal for one role: handling order status and delivery exception inquiries. The proposal lists the systems the role may read, the single system it may write to, and the actions that always need a human approval. It names three situations the agent will not handle at the start and explains why. It describes an evaluation set built from the real inbox, how it will be re-run after each change, and who in the company can read the logs. The handover section states that the company owns the evaluation set, the instructions and the memory, with an export on request.

The first partner is not necessarily dishonest. But the company can check almost nothing the first partner said, and can check nearly everything the second said. When the choice is between enthusiasm and verifiability, verifiability is the better foundation for a layer that will hold company knowledge.

A selection process you can run before signing

You do not need a long procurement exercise. You need a sequence that forces evidence to surface early.

• Name an accountable executive on your side. Someone must own the decision, the budget and the success criterion. Executive Sponsor for an AI Project: What the Role Requires describes what that person does.
• Write the first role in one paragraph: the work, the people served, the systems involved, the actions that need approval, and what success looks like in a form you can observe.
• Ask each candidate for a written proposal against that paragraph, including exclusions, risks and handover terms.
• Run a working session on your own material. Give each candidate the same real, anonymized samples and watch how they handle ambiguity and edge cases.
• Interview the people who would operate the system after launch. Ask who responds to an incident, how quickly they acknowledge it, and what a permission review looks like in practice.
• Request the export test. Ask the partner to show, on a sample environment, how your memory, configuration and evaluation cases would be exported.
• Compare proposals on verifiability, not ambition. Score each claim by whether you could check it yourself.
• Start small, with a defined review point where either side can stop or adjust scope.

This sequence also protects you from the cost of a poor choice. A short, bounded start with clear exit terms means a wrong decision is recoverable.

How does Be Human approach this?

Be Human designs, implements and operates personalized AI infrastructure for companies. An engagement begins with one useful role, the memory and tools it needs, the approval boundaries around it and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The agents keep their identity, memory, channels, tools, permissions and operating context under human control, and the work is delivered remotely in English and Portuguese. Be Human does not claim that any system is superintelligent today, and treats the layer as infrastructure that should improve as models do.

Frequently asked questions

Do we need an outside partner at all? It depends on whether you have people who have operated agents in production, with evaluation, permissions and incident handling. If you do, you may only need targeted help. If you do not, a partner shortens the path, provided the handover terms let your team take over when ready.

Should we pick a large consultancy, a specialist firm or a freelancer? Size matters less than whether the people doing the work can show the capabilities above and commit to the operating half, not just the build. A freelancer can be a fit for a narrow task, but continuity, coverage and documentation become the questions to settle in writing.

What should we do if a partner says they can deliver superintelligence? Ask what exactly will be running, for which role, with which permissions, and how you will observe that it works. If the answer returns to general claims about intelligence, treat it as marketing and steer the conversation back to a bounded first role.

How long should the first commitment be? Long enough to define the role, build it, evaluate it against real work and review results, and short enough that you can change course without penalty. Tie the commitment to a review point with a clear decision, and make sure the exit terms, including data export and deletion, are already agreed.

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