In short: A unified context infrastructure is the layer between a company's systems and its AI agents. It decides what the agent knows at the moment of the question. Before implementing one, eight points deserve evaluation: source coverage, modelling of business entities, how data is refreshed, latency at query time, capacity at volume, observability of context quality, the interface with agents and governance. Whoever sets these requirements before the first agent avoids redoing the integration for every new use case.
Every AI agent needs context: the customer's history for the sales agent, the current policy for the service agent, the contract and cost centre for the finance agent. Without a common layer, each project builds its own integration, with its own index and its own permission rule. Before long the company has five versions of the same customer.
The unified infrastructure connects the sources once and serves the same context to every agent. The discipline that studies how to assemble that context is called context engineering, the subject of What is context engineering?.
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.
Strattum's Company Brain is an infrastructure of this kind. The criteria below use its architecture as a reference.
The vendor's list of connectors is where the conversation starts. In many companies the business rule lives in spreadsheets, emails, legacy systems and customised ERPs that sit outside the official data pipeline, as The sources left outside the pipeline describes.
In the evaluation, it is worth separating three groups: structured systems (CRM, ERP, customer service, databases and warehouses), documents (SharePoint, Drive, Confluence, Notion) and conversations (Slack, email). The Company Brain connects all three, including TOTVS and SAP, which matters for Brazilian companies.
When the CRM and the ERP report different values for the same customer, the agent needs to know which source holds for each attribute. That requires an ontology: the description of the business entities, such as Customer, Contract, Product and Ticket, and of the relationships between them.
In the Company Brain, the ontology is written in YAML, versioned in Git and reviewed in pull requests, like any of the company's code. The Memory Worker reads the data catalogue, resolves the entities across systems and writes the result to the graph. The question for the vendor is who maintains the ontology after deployment and how a change is reviewed.
A nightly load serves management reports well. An agent answering about a ticket opened ten minutes ago needs data refreshed continuously. It is worth asking how the platform detects changes in each source and what delay to expect between a change at the source and the context being available to the agent. In the Company Brain's Memory Graph, updates happen without a nightly batch.
The latency the user feels adds up context retrieval, prompt assembly and the model's response. Poorly organised context makes the prompt bigger, which makes the answer slower and more expensive. Context organised into entities lets the agent receive only what the question requires.
In the proof of concept, it is worth measuring three things with real questions: retrieval time, the size of the context sent to the model and token consumption per answer. The last number sets the cost of running at scale and shows whether smaller models can handle most tasks.
The choice of graph engine, index and infrastructure determines how much the layer can take before it gets expensive. The technical choice of graph engine shows how Strattum evaluated cost and capacity at volume. To project ingestion, memory, disk and cost before signing, Strattum offers a capacity calculator.
Monitoring whether the platform is up does not tell you whether the context is right. Useful observability answers whether there are recurring questions with no answer in the base, whether two documents contradict each other and whether an answer validated by the team gets used again.
Knowledge, part of the Company Brain, runs a coverage lint that flags recurring questions with no answer and detects contradictions between fragments before incorporating them. Answers validated by the team are reabsorbed as indexed fragments.
The market standard for exposing context to agents is MCP (Model Context Protocol). In the evaluation, what matters is which tools the MCP server exposes, whether it is in production or in preview and whether the APIs let internal applications use the same context. The Company Brain exposes the graph as three MCP tools (search_entity, get_entity_context and run_cypher) and offers APIs for internal applications. Google Cloud's context engineering guide is a good reference on how agents consume this kind of tool.
Permissions, citations and audit cost little when they are part of the architecture and a lot when they come in later. The infrastructure needs to apply the source's permission before retrieval, cite document and version in every answer and log every query. In the Company Brain, all three controls are part of the core, and the whole platform runs in the customer's cloud.
A useful proof of concept uses a real use case, with questions that today require crossing at least two systems. We chose this format for Strattum projects because it exposes coverage, modelling and permission problems all at once. Strattum engineers (FDE) work inside the customer's operation from the start of the project to model the ontology and connect the sources.
To plan your company's context infrastructure with the Strattum team, go to strattum.ai/contato.
