Company Superintelligence Layer: Seven Components to Build

A company superintelligence layer is the set of components that lets AI models do real work inside your business under your control: models, a harness, memory, tools, permissions, channels and observability. Build it in a deliberate order, starting with one useful role, the memory and tools that role needs, and the approval limits around it. The models will keep changing, so the value sits in the other six components, which your company owns and improves.

Key takeaways

• The layer has seven components: models, harness, memory, tools, permissions, channels and observability. Models are the part you rent. The other six are what you keep.
• Start with one role, not seven components. Define the work, the memory and tools it needs, the approval boundaries and one observable success criterion.
• Build permissions and observability earlier than feels necessary. They are easy to set up on day one and painful to retrofit once people depend on the agent.
• Keep memory, tool definitions and test cases in formats you control, so a better model can replace the current one without a rebuild.
• Treat the layer as operated infrastructure with owners, reviews and change control, not as a one-time project.

What is a company superintelligence layer, and why seven components?

The word superintelligence here is a planning stance, not a claim about any model available today. The idea is simple: if models keep getting more capable, the companies that benefit most will be those that already have a place for a capable model to plug into. That place has to know the business, reach the right systems, respect limits and show its work.

Most companies begin with a model subscription and a chat window. That covers one component, and only partly. The agent forgets yesterday, cannot touch the ticketing system, has no defined permissions and leaves no record of why it answered the way it did. Naming seven components gives you a checklist for finding the gaps.

If you want the longer argument for why the layer matters more than any single model, read Build a Company Superintelligence Layer That Improves With Models. For a view of how these components sit alongside your existing software, The Seven Layers of Company AI Infrastructure, Explained is the companion piece. This article is the practical walkthrough: what each component is, what good looks like, and what to build first.

Models, harness and memory: the thinking core

These three components decide what the agent can reason about and how it holds a task together.

Models. Choose a model for the role, not for a ranking. A role that drafts customer replies has different needs from one that reconciles records or reads long contracts. Some roles do well with one model, others with a stronger model for hard steps and a cheaper one for routine steps. The rule that matters most is replaceability: no prompt, tool or memory format should depend on a single provider's quirks. When a better model arrives, you want to test it against your own cases and switch in an afternoon, not a quarter.

Harness. The harness is the program wrapped around the model. It assembles the instructions and context for each run, calls the model, executes the tools the model asks for, handles errors, decides when to stop and hands work to a person when it should. Published engineering guidance on building agents makes the same point repeatedly: begin with the simplest loop that works and add structure only when a measured problem justifies it. A harness that is too clever is hard to debug and hard to hand over.

Memory. Memory is what makes the agent yours. It usually has three parts:

• Identity and instructions: the role, tone, rules and escalation paths, written in plain documents.
• Knowledge: policies, product facts, process notes and reference material the agent can retrieve when needed.
• Working history: what the agent did, what was decided and what a person corrected.

The common failure is putting everything in front of the model every time. Good context design gives the agent a small, relevant selection and lets it retrieve more on demand. The second failure is unowned memory. Decide who may edit each part, who reviews changes and when stale items expire. Keep it in readable files or a database you can export, because memory is the component that is most costly to lose and most valuable to carry between models.

Tools, permissions and channels: how the agent touches the business

The next three components determine what the agent can do, what it is allowed to do and where people meet it.

Tools. A tool is an action the agent can request: look up an order, search a knowledge base, create a draft, update a record. Good tools are narrow, clearly named and described in language the model can use correctly. They return useful error messages instead of silent failures. Start with read-only tools. Add write tools one at a time, and make writes safe to repeat, so a retried request does not create a duplicate. A short list of reliable tools beats a long list of vague ones.

Permissions. Give the agent its own identity, separate from any employee, and grant only what its role needs. Deny by default. Separate what it may read, what it may draft and what it may execute, and require a named human approval for anything irreversible or external, such as sending money, deleting records or contacting a customer for the first time. Write the boundaries down before the build, because they shape the tools. Then review them on a schedule, since roles drift. The step-by-step method is in How to Run a Permission Review for Your AI Agents, Step by Step.

Channels. A channel is where people ask the agent for something: email, a team chat, a ticket queue, a shared inbox. Choose the channel your team already uses, or adoption will stall. Two design points matter. First, the channel should carry the requester's identity, so the agent knows who is asking and what that person may request. Second, treat everything arriving through a channel as untrusted input. An email or a pasted document can contain instructions aimed at the agent, so the harness and the permissions must hold even if the model is persuaded by text it should have ignored.

Observability: how you know the layer works

Observability is the seventh component and the one most often skipped. It answers three questions: what did the agent do, was it right, and what did it cost.

Start with a record of every run: the request, the context supplied, each tool call and result, the final output, any human approval or correction, the time taken and the cost. This is the same discipline engineers apply to any service, applied to an agent, and standard conventions for tracing generative AI calls already exist. You do not need to invent a format.

Then add evaluations. Collect real examples of the role's work with the outcome a good employee would reach. Run them whenever you change a prompt, a tool, the memory or the model. A small set of honest cases, including awkward ones, tells you more than a demo. When a new model is released, the same cases let you compare it against the current one on your work instead of on a public benchmark.

Finally, tie the record to one success criterion agreed in advance, such as the share of requests resolved without rework, reviewed weekly by a named person. If you cannot observe success, you cannot improve the layer, and you cannot decide whether to expand it. Proof of Concept, Pilot or Production: What Each AI Stage Must Prove explains what evidence each stage should produce.

What to build first: a step-by-step plan

The order below keeps the first version small enough to finish and complete enough to trust.

• Step one: choose one role with a clear owner, a repeating workload and a visible cost of delay. Write it as a short job description.
• Step two: write the approval boundaries. List what the agent may do alone, what needs a person and what it must never do.
• Step three: define the success criterion and how it will be measured, before any build starts.
• Step four: set up identity and permissions for the agent, with read-only access to the minimum systems.
• Step five: assemble the first memory from existing documents. Write the instructions, then add only the knowledge the role needs.
• Step six: build two or three tools, read-only first, and a plain harness with a human handoff.
• Step seven: turn on run records and assemble a first set of real evaluation cases.
• Step eight: open one channel to a small group, review runs weekly, correct memory and tools, then add write actions one at a time.

Notice what is not on the list: a platform decision, a multi-model strategy, a dozen use cases. Those come after one role runs reliably. If you are unsure whether your business is ready for step one, Does Your Business Need an AI Agent? Signs to Act and to Wait offers a quick filter.

An illustrative scenario

Illustrative scenario: a mid-sized distributor wants help with supplier delivery questions that currently interrupt the purchasing team all day.

The role is a purchasing assistant. Its memory holds the team's rules for escalating late deliveries and the standard wording for supplier messages. Its tools are a read-only lookup of order status and a tool that drafts a message but does not send it. Its permissions allow reading orders and writing drafts, nothing else. Its channel is the team's shared inbox, where a buyer forwards a question and receives an answer and a draft. Its observability is a weekly review of runs, with the success criterion that buyers use the draft without rewriting it.

After a few weeks, the review shows the agent misreads a particular supplier's status codes. The fix is a memory note and a clearer tool description, not a new model. Later, a stronger model becomes available. The team runs its saved cases against it, sees where it improves and where it does not, and switches only the steps that benefit. Sending messages directly stays behind a buyer's approval until the record justifies a change. Every piece of that improvement lived in components the company owns.

How Be Human handles the layer in a managed engagement

Be Human designs, implements and operates the layer as one piece of work. A first engagement defines a single useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. After launch, managed operations cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with changes requested and approved by your people. Memory, tool definitions and evaluation cases stay in formats you can export, which keeps model choice open as the field moves. The process for changes is described in How to Request and Approve Changes to a Managed AI Agent.

Frequently asked questions

Do we need all seven components before we start? You need a simple version of each, not a finished version. A role with a short memory, two tools, a narrow permission set, one channel and a weekly review of runs already touches all seven. Skipping permissions or observability is the usual mistake, because gaps there are harder to see and costly to fix later.

Which component should we invest in most? Memory and observability tend to repay the most effort, because they carry over when models change. Memory holds what the agent knows about your business, and observability tells you whether changes help. Models matter, but they are the easiest component to replace.

Can we build this ourselves or should we use a partner? Both are workable. A capable internal team can build it, provided someone owns operations afterward: monitoring, evaluation, permission review and integration upkeep. The common risk is a good build with no one assigned to run it, so decide who owns the layer before choosing who builds it.

How is this different from buying an AI tool? An off-the-shelf tool usually bundles several components behind its own interface, which is fast to start but harder to adapt to your permissions, memory and systems. A layer you control costs more thought up front and gives you room to change models and extend roles. The right choice depends on the role, and the decision path in Custom AI Agents vs Off-the-Shelf AI Tools: How to Decide can help you weigh it.

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