Build, Buy or Manage Your Superintelligence Layer: A Decision Test

Build, buy or manage? For most companies the answer depends less on which model powers an agent and more on who owns the memory, tool access and permissions that let it act on company information. Build in-house when that layer is a lasting source of advantage and you can staff its maintenance for years. Buy a product when a standard tool covers the workflow and its permission and logging model meets your audit needs, and use a managed operator when you need a custom role under your control without carrying the run-and-maintain work yourself.

Key takeaways

• Decide by ownership, not by model: the real question is who holds the memory, the tool connections and the permission rules.
• Buy when a product covers a common workflow and lets you configure, export and audit its permissions and logs.
• Build only when the layer is strategic and you can fund evaluations, credential rotation, incident response and permission review every quarter.
• Use a managed operator when you need a role built around your memory and tools with boundaries your leaders set, but lack the internal capacity to run it.
• Before any integration, write the approval boundaries and one observable success criterion for the specific role.

What the superintelligence layer actually contains

When leaders talk about the AI layer, they often mean the model. The part that decides whether an agent is useful and safe sits around the model. It defines what the agent knows about your business, which systems it can read and write, which actions need a person to approve, and what record remains afterward. These are the components you are really deciding on, whatever the vendor calls them.

For a single role, the layer usually includes five parts:

• Identity and operating context: the role's purpose, tone, scope and the things it must never do.
• Memory: the documents, records and past interactions it can retrieve, and how those sources are refreshed or removed.
• Tools: the connections to your systems, with each action named, limited and assigned an owner.
• Permissions: who may grant, change or revoke access, and what approval each change requires.
• Observability: logs and evaluations that show what the agent did and whether the outcome was right.

Standards help with the last two parts. The OpenTelemetry observability primer explains how traces, metrics and logs make a running system inspectable, which is the minimum you need to judge an agent's behavior after launch. The OWASP authorization guidance makes the case that access decisions should be enforced consistently by the system, not left to the interface or to the model's own judgment. Protocols such as the Model Context Protocol aim to standardize how models connect to external tools, which makes the tool layer easier to move. Portability is a useful question to put to any vendor: where will your tool definitions, memory sources and logs live if you leave?

The four-question decision test

Answer these four questions for one specific role, not for "AI in general." Write each answer as a full sentence. If you cannot write the sentence, the decision is not ready to be made.

• Does this workflow differentiate us, or is it a common process that many firms run in the same way?
• Who will own the permissions, and can we show who approved each tool connection and when?
• Can we observe what the agent did and judge whether the outcome was acceptable?
• Who maintains the layer when a connected system changes, a model is replaced or a policy shifts, and what is that person's time commitment?

Read the answers together. A common workflow with no differentiating knowledge points toward buying. A differentiating workflow with a named permission owner, observable outcomes and internal engineers who will maintain the integrations points toward building. If you have a differentiating workflow and a clear owner but no maintenance capacity, a managed operator is usually the better fit. Two or more unclear answers on ownership and maintenance are a signal to narrow the scope before choosing any source at all.

When buying a product is the right answer

Buying fits workflows where mature products already exist, such as meeting notes, standard inbox triage, document intake or scheduling. In these cases the know-how is generic, and speed to a working tool matters more than custom memory. The risk is not in the feature list. It sits in the details: whether you can configure which tools the product can call, whether permissions can be reviewed without a support ticket, and whether logs can be exported in a form your own team can read.

Before signing, ask the vendor to show you the permission screen and a sample log entry. Ask what happens to your data and configurations if you cancel. The cost of leaving is often the hidden part of buying, and the exit questions are set out in more detail in this guide to avoiding AI vendor lock-in.

When building in-house makes sense

Building is justified when the memory reflects know-how that a product cannot replicate, when the data must stay inside your own infrastructure, or when the workflow changes so often that no roadmap will track it. It is also justified when your engineers already run production systems and treat agent behavior as one more service to monitor.

The cost that leaders underestimate is the run phase. A build needs evaluations that repeat after every change, credential rotation, incident handling, permission reviews and integration updates when external APIs move. Budget for those activities as recurring work with a named owner, not as a one-time project. Teams that skip this step often end up with a working prototype that nobody is responsible for after the builder moves on.

When a managed operator fits better

A managed operator suits a company that wants a role built around its own memory and tools, with approval boundaries set by its leaders, but does not want to staff a platform team. The operator should leave you with the layer's definitions, logs and permission records in a form you can read. If you cannot review the tool list and the approval rules without asking the operator to explain them, the arrangement has drifted from the model you wanted.

Be Human designs, implements and operates personalized AI infrastructure for companies, with the agent's identity, memory, channels, tools, permissions and operating context kept under the client's control. A first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations can then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The service is delivered remotely, in English and Portuguese.

Illustrative scenario: a distributor's order desk

Illustrative scenario, not a client case: a regional distributor with a small order desk wants an agent to answer routine stock and delivery questions and to draft replies for the sales team. Leadership works through the four questions. Stock lookup is common across the industry, so the team buys a support product for inbox triage and keeps it narrow. Pricing exceptions and customer purchase history are different. They reflect years of account knowledge, so the team chooses a managed operator and keeps the customer memory and the discount approval rule under its own control. Before the agent goes live, the owner of each tool connection is named, and the permission list is scheduled for review.

Where to start this week

The decision becomes concrete when you write down the role and its boundaries. Work through these steps in one working session with the operations lead and whoever owns the affected systems:

• Write the role in one sentence, including the single decision or task it supports.
• List every system the role would read or write, and mark each action that needs a human approval.
• Name the owner of permissions and the person who will review them on a fixed schedule.
• Choose one success criterion you can observe from logs or from a short evaluation set.
• Run the four-question test for each candidate source and record the answers beside the decision.

The permission steps are covered in more depth in this permission review guide, and the overall stack can be drawn using the one-page architecture map. If you want help finding the first task worth handing to an agent, take the free Be Human AI diagnostic after this article.

Frequently asked questions

Should we build the layer ourselves if we already have strong engineers? Strong engineers are necessary but not sufficient. Building also requires a named owner for permissions, evaluations that repeat after every change, and time for incident response and integration updates. If that capacity is not already planned, a build will often stall after the first release.

Is buying a product always the lower-risk choice? Buying reduces the build effort, but it moves risk into areas you must check, such as configurable permissions, exportable logs and the cost of leaving. A product is low-risk only when its permission model and records meet the approval rules your business requires. Test those before signing.

What should a managed operator leave us with if we end the relationship? You should keep the role definition, the tool list, the approval boundaries, the permission records, the logs and the evaluation criteria in a form your team can read and reuse. Ask for these items in the contract and check them during the first review. Anything held only inside the operator's systems is a dependency you should price in before you sign.

How do we know we made the right decision? A right decision shows up as a clear owner, an observable success criterion and a maintenance plan that someone is actually performing. Review those three items after the first few months of operation. If the role is useful, the logs show it, and the permissions still match what leaders approved, the decision was sound for that scope.

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