Announcing US$ 3.2M pre-seed round · OneVC · Maya · Norte Ventures Read →
Back to blog

Integration, latency and scale:
the context layer's requirements before the first agent

In short: Most companies set their context requirements after the third AI agent, when there are already three integrations, three indexes and three permission rules for the same customer. Setting them before the first agent means answering four questions on integration, latency, scale and governance. This piece shows how each one appears in the design of a unified context infrastructure and what to measure in the proof of concept.

A company's first AI agent is usually born inside one team: a sales assistant that reads the CRM, a service bot that reads the knowledge base. It works well until a second team asks for its own agent, with the same customer, the same contract and a different access rule. From then on, every project redoes the integration, and the customer's context exists in several versions.

A unified context infrastructure solves this by connecting the sources once and serving the same context to every agent.

Company Brain (the business's operational brain): the layer that connects a company's systems once, organises data, memory and knowledge, and delivers that context to any AI agent with each person's permissions.

At Strattum, the requirements we set with customers before the first agent fit into four groups.

Integration: which sources carry the business rule

The list of connectors matters less than the answer to one question: where does the rule the agent will apply live? In many companies it sits in a finance spreadsheet, in a customised ERP or in an approval email, outside the official data pipeline. The requirement has to list those sources and say which system holds for each attribute when the CRM and the ERP disagree. This is where the ontology comes in, the description of the business entities and the relationships between them, which in the Company Brain is versioned in Git and reviewed like code.

Context delivered as a pile of documents beside context organised into entities
Context size weighs on latency and cost

Latency: how much context the agent receives per question

Perceived latency adds up retrieval, prompt assembly and the model's response. The item that weighs most is usually the size of the context. When the context arrives as a pile of documents, the prompt grows, the answer takes longer and the cost goes up. When it arrives organised into entities, the agent receives only what the question requires. In the proof of concept, we measure retrieval time, the size of the context sent and token consumption per answer. That last number shows whether the company can use smaller models for most tasks.

Scale: how much the layer can take before it gets expensive

The volume of documents, entities and queries drives the choice of graph engine, index and infrastructure. The sums have to be done before signing, with the company's real volume and the projection of new use cases. Strattum publishes a capacity calculator to project ingestion, memory, disk and cost.

Governance as the foundation of the context layer from day one
Permissions, citations and logs go into the foundation

Governance: what has to exist on day one

Permissions applied before retrieval, a citation of document and version in every answer and a log of every query. These three controls cost little when they are part of the architecture and a lot when they come in after the first incident. For regulated sectors, the requirement includes where the layer runs: the Company Brain runs entirely in the customer's cloud.

I went through the eight evaluation criteria in the guide What to evaluate in an AI context infrastructure before you implement it. To design these requirements with the Strattum team, go to strattum.ai/contato.

Get the next articles on AI implementation