Company Superintelligence Layer: A Six-Month Build Order

A company superintelligence layer is the working infrastructure that lets AI agents hold a company's context, memory, tools and permissions under human control, and keeps improving as underlying models get better. The practical way to build it is in sequence: fix the business role and its success test first, then add the harness, memory, tools, permissions, channels and observability, with each stage proving itself before the next one begins.

Key takeaways

• Start with one role and one measurable outcome, not with a platform purchase.
• Put the harness, permissions and observability in place before you widen memory or tools.
• Let each layer earn its place: a stage closes only when its evidence is written down.
• Keep prompts, evaluation cases, memory sources and tool contracts in your own hands so the model can be replaced.
• Plan for change from the start, with scheduled reviews of models, tools and access.

Why the order matters more than the components

Many companies begin with the parts that look most impressive: a model subscription, a document index, a chat interface. These parts are not wrong, but assembled without a stated role and a test of success, they become something nobody can audit or extend. A layer that compounds is one where each addition makes the next one easier to add and easier to check, and that only happens when the foundations are settled before the surface area grows.

The sequence below follows a simple logic. Decisions that are expensive to reverse come first, such as which role the agent performs and what it must never do. Decisions that are cheap to change come later, such as the wording of a prompt or the choice of a specific model. The six months are a planning shape rather than a promise, because a team with a clear owner and accessible data will move faster than one that is still deciding who is accountable for the process. If you want a map of the pieces before you start, the AI stack architecture map helps leaders see where each component sits.

Months one and two: fix the role, the success test and the model choice

Start with one role. A useful first role has a clear input, a recognizable output, a named person who receives that output, and a result you can measure in ordinary business terms, such as how long a request waits or how often work comes back for correction. Write the success criterion before anyone opens a model console. If you cannot describe a passing week, the agent will be judged by impressions, and impressions drift.

Next, choose the model, and keep the choice narrow. Select it for the reasoning the role needs, the response time it must meet and the data it will handle, then record why it was chosen. Do not let the model define the layer. You will probably change models during the six months, so the prompts, evaluation cases and tool descriptions you write now should work with any capable model.

Illustrative scenario: a mid-sized equipment distributor wants faster checks on incoming supplier invoices. The team defines the role as flagging invoices whose line items do not match the purchase order and sending those flags to the accounts payable lead. The success criterion is that every flag is reviewed the same working day, with a short note on which flags were false alarms. Nothing else is in scope during month one.

Months two to four: build the harness and the memory

The harness is the code and configuration around the model: how instructions are loaded, how a task is split into steps, when the agent stops, and what it does when a tool call fails. Anthropic's engineering guidance on long-running agents describes the value of written progress records and clear starting points for each session. Build the harness so that a new session resumes from a written state rather than from whatever the model happens to recall.

Memory needs boundaries. Separate three kinds: what the agent keeps permanently (the role's rules, approved terminology, escalation contacts), what it retrieves on demand from approved documents, and what it discards after a task ends. Retrieval from your own document collections is usually the right first pattern for company knowledge, because the source stays in your systems and can be updated or withdrawn. Fine-tuning is a separate decision and rarely the first one. Write down which collections the agent may read, who owns each one, and how outdated content is retired. Memory without an owner becomes a liability the first time a policy changes.

Months three to five: add tools, permissions and channels

Tools are where an agent starts acting for your company, so each one needs a written contract: what it does, what inputs it accepts, what it returns and what it cannot touch. Tool descriptions matter more than most teams expect, because the model chooses among tools based on those descriptions. The Model Context Protocol offers a common way to connect models to external systems, which can reduce custom connection work, but a standard connection does not decide who is allowed to do what.

Grant permissions by role, not by convenience. An agent that reads order status does not need write access to the order system, and an agent that drafts replies does not need to send them. OWASP's authorization guidance favors scoped, checked access on every request rather than broad trust granted once. Require explicit human approval for any action that changes money, customer records or external commitments, and widen that only when the evidence supports it. Where a tool can trigger a payment or create a record, use idempotency keys so a retried call cannot duplicate the action, a pattern that payment providers document for their own APIs.

Channels come last in this group. An agent that posts to a shared chat, answers customer email or receives webhooks is exposed to prompt injection, because instructions can arrive inside content the agent reads. OWASP's prompt injection guidance recommends treating retrieved text as data rather than as commands and keeping tool use within an approved list. Test this deliberately with hostile examples before any channel goes live.

Months five and six: observability, evaluations and controlled change

Observability is what turns the layer from a demonstration into an operation. Record each run with its inputs, the sources retrieved, the tool calls made, the approvals requested and given, any errors, and the final output, all under a consistent schema. OpenTelemetry's observability concepts give you a shared vocabulary for traces, metrics and logs, and its conventions for generative AI help you name what you record. Without this record, the first incident becomes a guessing exercise.

Evaluations turn observations into a repeatable test. Anthropic's guidance on evals for agents recommends starting with a small set of tasks drawn from real successes and failures, graded consistently and rerun after every change. Run it as a routine:

• Export a sample of real runs from the past two weeks and label each one as correct, acceptable or wrong.
• Convert every wrong and borderline case into a fixed test, with the expected behavior written beside it.
• Run the full set before and after each change to a prompt, tool, memory source or model.
• Review the failure log with the process owner every week in the first months, then at the cadence agreed in the review.
• Change one thing at a time, and record the change, its reason and its owner.

From this point, all changes follow a written path. Route requests to change the role, a tool or a permission through a change request process, so each update has a reason, an approver and a test result attached.

Keeping the layer under human control

Be Human designs, implements and operates this kind of layer as a managed service, remotely and in English or Portuguese. 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, so the company keeps decision rights over the agent's identity, memory, channels and permissions while the operating work continues. Quarterly access reviews are part of that routine, and the first months with a managed agent show how that rhythm typically settles in.

If you are unsure which stage your company should start with, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

How long does the build take? The six months describe a sequence, not a fixed schedule. Some companies clear the first two stages quickly, while others spend more time agreeing on ownership and boundaries, which is usually the slower part. The useful test is whether each stage has written evidence before the next one starts.

Do we need the full layer before the first agent goes live? No. A first agent should run with a narrow role, limited tools and human approval on every consequential action. The rest of the layer grows around that working agent as evidence accumulates.

Can we change models later without rebuilding everything? You can, provided the prompts, evaluation cases, tool contracts and memory sources are kept separate from any one vendor's features. Store them as your own assets and rerun the evaluation set on any new model before switching.

Who should own the layer inside the company? A named business owner should be accountable for the role and its success criterion, while operations or IT owns access and logging. Decision rights over permissions and memory should not sit with an outside vendor alone. Smaller teams often combine these responsibilities, but they should still be written down.

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