Company Brain: the context architecture trying to curb AI agent hallucination in production

A concept debated in Silicon Valley proposes an integrated structure of data, rules, and relationships, organized into distinct layers, so that AI agents stop inventing different answers to the same question. For those who build these systems, it's a new name for a well-known architecture problem.

The problem every AI team in production has already seen

Three agents, three different answers to "how many sales did we close this month." Anyone who has put more than one AI agent into production recognizes the symptom: each one queries a different source, applies a business rule only it knows about, and delivers a plausible but wrong number.

This is the problem the Company Brain concept tries to name, according to an article published in Exame, a Brazilian business magazine, by Antonio Duarte, CEO and co-founder of Nekt, a Brazilian company. The central thesis is simple: agents don't have the tacit experience a senior analyst accumulates over years at a company, so they reproduce error at scale, not as an exception.

What Company Brain actually is

In practice, Company Brain isn't a product, it's an architecture pattern: a structure that brings together data, processes, and business rules in a format queryable by both humans and agents. For anyone who works with data, it sounds familiar, it's the old promise of the data catalog and the data mesh, except now with a new and insatiable consumer, the autonomous agent that runs the same query thousands of times without supervision.

The practical difference lies in what this repository needs to store. Having tables and documents isn't enough, it's necessary to capture what usually stays only in the heads of the people who run the business: the criterion that defines a sale as closed, the formula used to calculate a metric, the procedure followed when a customer requests a cancellation. Without that, the agent fills the gap with inference, and language model inference over business rules is a recipe for hallucination.

The four layers, translated into architecture

The Exame piece describes Company Brain in four layers, which map almost directly to architecture decisions any data platform team has already discussed:

• Ingestion: structured data (CRM, ERP, spreadsheets) and unstructured data (emails, meeting transcripts, internal documents) enter the system.
• Curation: organized history, corrected inconsistencies, data prepared for querying, the heavy data engineering work that rarely shows up on a board slide.
• Context graph: the truly new layer. This is where relationships between data and business rules live, the meaning of each metric, documented processes. It's a knowledge graph applied to corporate semantics, not just entities.
• Controlled access: agents consume this information via APIs and MCP, with activity-specific permissions.

The layer that actually differentiates Company Brain from a well-built data warehouse is the third one. A data warehouse stores the what; the context graph stores the why and the how, and it's this semantic metadata that the agent uses to avoid making up the answer when the raw data is ambiguous.

RAG, knowledge graph, or fine-tuning: what changes in practice

The source doesn't go into implementation detail, but the technical decision behind a context graph has trade-offs that builders already know under other names. It's worth comparing the three most common approaches to giving an agent business context:

The practical point: pure RAG solves text retrieval, not business rule ambiguity. Fine-tuning locks the rule inside the model, which is terrible when commercial policy changes every quarter. The context graph is more expensive to maintain, but it's the only one of the three options where you can audit why the agent answered what it answered, a requirement that becomes mandatory as soon as the agent takes part in a decision with financial impact.

Governance isn't a feature, it's a prerequisite

Using MCP to give agents access solves connectivity, not permission. The original article is direct about this: an agent that analyzes commercial data may need to read the CRM without being authorized to write to it, and a financial agent should only access the subset of data relevant to its role.

For those designing this kind of system, that means treating each agent as an IAM principal, not as a script with a generic API key. Logging every action performed stops being a best practice and becomes an audit requirement, especially when the agent operates continuously and without a human in the loop for every call.

The Nekt case: 20 agents, 10,000 calls per month

According to Duarte, Nekt uses this architecture internally for its own go-to-market operations: more than 20 agents make around 10,000 calls a month, all sharing the same data environment and the same definitions of customer, sale, and outcome. One of these agents, dedicated to checking inconsistencies in the CRM, has already resolved hundreds of issues without human intervention.

The number matters less for its volume and more for what it demands in terms of maintenance: every time Nekt changes a stage in the sales funnel or a service criterion, that change needs to reach the context graph before it reaches the agents. It's the same schema drift problem any data pipeline faces, except now the downstream consumer makes a business decision instead of just generating a report.

When it's not worth building this

Building a context graph with ongoing curation is expensive and slow to deliver value. The source itself acknowledges that companies still structuring their first operations have more urgent priorities. The signs that it's worth investing are concrete: information scattered across different tools with no single source of truth, recurring meetings just to decide which number is correct, dependence on one or two people who hold all the tacit knowledge, and recurring distrust in the answers agents already produce today.

If none of these symptoms appear, the cheapest path remains well-built RAG over a reasonably organized document base, with human review at critical decision points. Company Brain solves a real scale problem, but scale is exactly what most teams still running two or three agents in production are missing.

The bias worth noting

A reading caveat is worth making: the author of the original article is CEO and co-founder of Nekt, a company that, according to the article itself, uses this architecture internally to organize its go-to-market operation. That doesn't invalidate the diagnosis, which reflects a real technical problem documented in any team that has run multiple agents against the same base, but it explains why the text reads more like an account of internal practice than a neutral, independent case study.

Anyone evaluating whether to adopt the idea should ask for the same thing they'd ask of any new vendor: a latency benchmark of the context graph under load, and a clear plan for who keeps the semantic layer updated when the business rule changes.

Source 1: Exame (https://exame.com/bussola/company-brain-o-que-e-o-conceito-que-ganha-forca-no-vale-do-silicio/)

Opinion piece "Company Brain: o que é o conceito que ganha força no Vale do Silício," published by Exame (Bússola) on November 5, 2026, signed by Antonio Duarte, CEO and co-founder of Nekt.