Company Brain: How a Git Repository Becomes Corporate Memory for AI Agents

A company's knowledge rarely resides in one place. Product decisions are in the wiki, customer histories in the CRM, issues in the ticketing system, and the truly important nuances in meeting notes that nobody opens after the appointment. In many software companies, this creates a familiar pattern: Sales, Customer Success, and Support approach the development team with product, code, and analytics questions. Someone there types the question into the coding agent, waits, and sends the answer back. The human becomes a translation layer for a machine that could answer the question itself long ago.

The obvious solution—giving an AI agent access to all systems and letting it search—works worse in practice than expected. An approach that has spread this year under the term Company Brain reverses the logic: Instead of sending the agent to the data, the data is brought to the agent. As markdown files in a Git repository, with tools that are already present in every development team anyway. We examined the approach closely because it promises an unusually good ratio of effort to benefit for developing AI applications in medium-sized companies. This article explains how a Company Brain emerges, why simple files are more powerful here than vector search, how the memory grows in a controlled manner, which attack patterns you should know, where the limits lie, and how to start pragmatically.

What a Company Brain is

A Company Brain is a private Git repository into which a company's relevant data sources are regularly synchronized as pure text files: wiki pages, help articles, support tickets, meeting notes, excerpts from the CRM, parts of the source code. A coding agent, as used by development teams for daily work, navigates this repository the same way it navigates a codebase: It reads files, searches for terms with grep, and follows references between documents.

This sounds unspectacular, and that's exactly the point. Three properties make the approach interesting for companies:

• No new system. It requires no vector database, no knowledge platform, and no additional vendor. Git, a coding agent, and a chat channel suffice.
• Files are the source of truth. There is no database schema, no index that becomes outdated, and no pipeline that someone has to debug. The main branch of the repository is the current state of knowledge, every change is traceable as a commit.
• Inspectable for humans. Every file can be opened, checked, corrected, or deleted. What the agent knows is exactly what's in the repository.

The term is now also being occupied by platform providers who understand it as semantic layers, knowledge graphs, or managed memory systems. These approaches have their justification, especially where data definitions need to be standardized company-wide. For most medium-sized companies, the lean variant is the better entry point: a repository that can be set up in a few hours and whose benefit can be tested immediately with real questions. How such AI agents for companies work fundamentally and which autonomy levels make sense, we have described elsewhere.

From wiki with AI search to repository

The path to the Company Brain begins in many companies at the same place: the wiki. The AI functions of common knowledge platforms are now good enough to support product research or find the right pages for a support case, provided the team disciplines itself to store everything there, including call recordings and ticket exports. This is sufficient for working at the screen. It's not sufficient for automation, because these assistants typically cannot be called via API or webhook. Knowledge that only a human can query remains a reference work in everyday work.

The first step beyond this is typically a support workflow: A new ticket triggers a cloud agent via webhook that reads the codebase and suggests in an internal note what the cause might be before anyone from support even opens the case. This works remarkably well for diagnosis and remarkably poorly for solution proposals. The agent knows the code, but not the history: What similar cases were there, what helped at the time, what was promised to the customer? This is exactly the gap the repository closes. Tickets, codebase, documentation, and help articles migrate as files to one location, and the same agent that previously only saw the code now sees the context.

From there it's a small step to the company-wide tool. A Slack channel where everyone can ask the agent questions is initially conceived as a temporary solution in most setups. The effort is low: The repository takes about two hours, connecting the channel to a cloud agent takes minutes. Once teams see that product questions, analytics requests, and research are answered without a detour through development, the temporary solution becomes a priority.

Why files and grep beat classic vector search

The intuitive architecture for corporate knowledge in recent years has been Retrieval-Augmented Generation (RAG): Documents are broken into sections, embedded as vectors, and searched for similarity when a question arises. The second generation replaced the vector index with tool connections via the Model Context Protocol (MCP): The agent gets a search tool for each system and decides for itself when to call it.

Both paths have a common problem that only becomes apparent in operation. A vector search delivers what sounds similar, not what applies. And an MCP search makes it too easy for the agent to stop early. Teams operating the approach report the same pattern: The agent calls the search tool, receives three tickets and a meeting note, considers this sufficient, and formulates a conclusion. Not because there are no further pieces of evidence, but because the tool gives it no reason to search further.

The same agent behaves differently in a file system. With grep, it quickly finds two hundred files in a mature repository where a topic appears, opens fifty of them, follows cross-references, and builds a picture before answering. This is no coincidence. Current models know this way of working from programming and often prefer shell tools like grep over specialized search tools. Anyone who offers the agent corporate knowledge in the form of a codebase uses one of its strongest capabilities.

The model providers also describe this shift. In the recommendations for context engineering for agents, the principle is called just-in-time context: The agent only keeps light references like file paths in context and loads content only when it needs it. Pre-embedded indexes thereby don't become obsolete, but they are no longer the only path.

Whether an additional search layer should sit on top of the files is a second-order question, and practice knows both answers. Teams that manage with grep report that a subsequently added vector search brings little and robs the system of its simplicity. Others place a local hybrid search over the same markdown files: The open-source tool QMD, for example, combines full-text search, vector search, and re-ranking, runs entirely on its own machine, and is called by the agent like any other command-line command; its collections can be synchronized via Git before each update. The common denominator of both variants weighs more heavily than their difference: The knowledge exists as files, and the agent reaches it via tools it can operate iteratively, instead of via a collection of MCP servers whose result it receives once and considers complete.

The last row already shows the most important trade-off. We'll return to this under security.

How the repository is structured

The architecture can be described in five layers.

Connectors. For each data source, there exists a small script that fetches data via the API of the respective system and writes it as markdown into its own folder, such as context/wiki/ or context/tickets/. The scripts are deliberately kept simple: no build step, no dependency on a platform. If the format of a source changes, the script is adjusted, not a data model migrated. The principles we recommend for robust data synchronization between systems apply here one-to-one: idempotent runs, clear responsibility per source, make errors visible instead of swallowing them.

Automated sync. A CI workflow, usually GitHub Actions, runs the connectors on schedule and commits the result back to the repository. Daily is sufficient for most sources. The Git history thereby becomes a by-product with high value: A diff shows which tickets are new, which wiki pages have changed, and which customer file has grown.

Command-line tools for live data. Not everything belongs in files. Metrics from the data warehouse, transactions, or inventories are too volatile and too extensive for a daily export. For such sources, the agent gets the appropriate command-line tools installed in its sandbox, such as a client for the data warehouse, and the files in the repository contain the identifiers it needs for targeted queries. Experience speaks for command lines rather than MCP servers here: Some cloud agents repeatedly show regressions with MCP connections, while a CLI runs stably and can be tested manually by any team member.

Orientation for the agent. A file at the top level, typically AGENTS.md, describes which folders exist, what they contain, and how to search them. Additionally, skills define recurring tasks: How to compile a customer file, how to connect a new source, how to generate a weekly report. This format is quickly becoming the standard, even if the agent providers don't yet support it uniformly. A study by the University of Heidelberg on the spread of such context files in open-source projects describes AGENTS.md as a cross-tool format that brings together the manufacturer-specific variants. In the repository, the skills exist once and are made visible via symlink for Cursor, Claude Code, and other agents.

Access for the team. The agent runs as a cloud instance and is connected to a Slack channel. Anyone with a question asks it there, without opening a development environment and without being a user of the coding agent themselves. Anyone who wants to work more deeply clones the repository and uses the agent directly.

Four practices that turn data into knowledge

A repository full of raw exports is not yet a Company Brain. The first version may look like this: dump everything in, install tools, let the agent do its thing. The difference to the mature system emerges afterward in the curation, and four practices have proven effective for this:

1. Filter. Only synchronize what answers questions. Archived projects, automatic notifications, and bot comments distract the agent and cost context.
2. Merge. A folder customers/ with one file per customer, where CRM data, tickets, and meeting notes converge, is significantly more useful than three separate folders. With each context update, a script runs over all files, collects what belongs to a customer, and generates a file from it with the core information and links to all associated files.
3. Link. Relative links between related files, in both directions: The customer file refers to each ticket, the ticket back to the file. Each file also carries the identifiers from the source systems so the agent can ask specifically when needed. The agent then navigates instead of searches and consumes noticeably fewer tokens until it finds the right context.
4. Derive. A model takes over enrichment tasks on schedule: classify tickets, evaluate conversations, extract structured fields from free text. Here the memory becomes an active team member that does preparatory work at night.

What a Company Brain accomplishes in everyday life

The benefit shows itself less in spectacular individual cases than in the sum of small requests that would otherwise interrupt a team member:

• Prepared support responses. For each new ticket, there is already an internal note that summarizes cause, similar cases, and previous solutions before the case is even opened.
• Product questions from Sales and Customer Success. Does our product support scenario X? What did we promise customer Y regarding feature Z? The answer comes with a reference to the source file.
• Analytics without a queue. How many customers use feature Z, and since when? The agent knows the identifiers from the files and queries the data warehouse itself.
• Customer briefings. Before a meeting, the agent delivers a summary of all touchpoints from recent months, including open tickets and the sentiment from the last conversation.
• Onboarding. New team members ask questions in the channel instead of digging in the wiki. And because the channel is public, everyone learns along with what questions the agent answers well.

The last point is more than a pleasant side effect. A shared channel makes visible what the team expects from the agent and where it fails. This transparency is the fastest way to improve the repository where it actually has gaps.

That this principle also works on a large scale is shown by Shopify. The internal agent River, which reads code, opens pull requests, and queries the data warehouse, works exclusively in public Slack channels and rejects direct messages; every conversation becomes a searchable transcript. Over a period of 30 days, the company counted nearly 60,000 sessions in over 5,000 channels with more than 7,000 people involved, according to its engineering blog. The public threads are evaluated, and the patterns from them flow back into skills, prompts, and agent presets. Internally, this is called the apprenticeship model: Those who watch how experienced team members work with the agent learn things that aren't in any documentation.

How the memory learns without running wild

A repository invites everyone to change everything. Exactly that shouldn't happen, for two reasons: Non-technical team members shouldn't have to work in Git, and behavioral changes of the agent need control. The approach solves both with a simple rule. Knowledge flows into the repository via the synchronized sources, i.e., via the wiki, the ticketing system, and the protocols that everyone maintains anyway. Behavior only changes via pull requests.

Concretely, this looks like this: Anyone who has a recurring type of question asks the agent in the channel to create a skill for it. The agent asks the follow-up questions it needs for a clean implementation, writes the skill file, and opens a pull request. A person who understands the system reviews the proposal and helps with the merge. To ensure proposals are usable from the start, there are skills that describe how skills are built and how they are reviewed. The result is an internal catalog of capabilities that exists as markdown in the repository, versioned and traceable like code. Anyone who wants the agent to be able to do something new doesn't have to ask anyone from development. Anyone who wants to maintain control over behavior has it through the review.

Security: the dangerous trio

A Company Brain is useful because it knows a lot. That's exactly why its operation deserves more care than a chatbot with access to the public website. Security researcher Simon Willison has reduced the risk to a formula that has established itself as the Lethal Trifecta: An agent becomes dangerous when three conditions are simultaneously met.

1. It has access to confidential data. For a Company Brain, that's the purpose.
2. It processes content that is not trustworthy. Tickets, meeting notes, and wiki pages can contain instructions that an attacker has placed, for example in a support request.
3. It can communicate externally. Without a channel to the outside world, the first two conditions remain largely inconsequential.

Language models cannot reliably distinguish instructions in data from legitimate instructions. Prompt injection is therefore not an error that can be fixed with a better system prompt, but a structural property. What it looks like concretely in a Company Brain is shown by the security notes in the next chapter.

Every security decision should be measured by whether it weakens one of the three conditions without substantially curtailing the agent's benefit. The three factors can be treated individually; this succeeds most easily with external communication. In practice, this means, sorted by effectiveness:

• Disable network access of the agent, at the sandbox level, not by instruction in the prompt. A manipulated agent doesn't follow its own prompt. Where connections are unavoidable, a positive list of fewer, verified domains applies.
• Limit and monitor output. If the agent only communicates via a few visible channels, what it sends can be checked: by a second agent without access to confidential data that proofreads before sending, or by downstream control that reports anomalies.
• Keep repository private and tightly restrict access. Raw access belongs to the people who really need it. The bot only posts in a designated channel; this creates a natural audit trail.
• Only synchronize what all employees should be allowed to see. The agent can surface everything in the repository. Data with a higher protection level stays out or migrates to a separate repository with its own access circle. Personal data is pseudonymized or removed before sync.
• Treat credentials as crown jewels. Each connector authenticates with a token that is restricted to the minimum, read-only if possible. A leaked token weighs heavier than the synchronized data because it grants live access to the source system.
• Secure the supply chain. Sync scripts run with access to all secrets. A minimum age for package versions (for example, five days since their publication) gives the community time to discover malicious releases before they reach the own system.

This doesn't reduce the risk to zero. The most helpful comparison is with employees: Nobody grants them the right to accidentally delete the database either. Permissions are granted by task, behavior is observed, and still a remainder remains because people can be deceived. The goal is to raise the effort for an attack above its benefit and make the likely error cases visible, limited, and repairable. How these principles translate to agents in the development process, we describe in the article on security of AI agents in development.

Security notes: Attack patterns you should know

The trio describes the risk abstractly. In operation, you encounter it in concrete patterns, and most of them look harmless at first glance. In the OWASP list of the biggest risks for LLM applications, prompt injection is in first place, with the note that neither retrieval nor fine-tuning eliminates the problem and only layered measures help: minimal rights for tools, filtering of inputs and outputs, human approval for risky actions. The following overview shows what the most important patterns look like in a Company Brain and which countermeasure works in each case.

No single point on this list makes the system secure. But the patterns show that effective countermeasures almost always lie in the infrastructure and not in the prompt: network, rights, review, visibility. Anyone who goes through the overview during the security review before opening the channel has covered the likely error cases.

Limits and trade-offs

The approach is deliberately simple, and simplicity has a price. Anyone planning a Company Brain should soberly weigh these points against the benefit.

One access level for all. A repository knows no fine-grained rights per user and document. Anyone allowed to use the channel potentially sees everything that was synchronized. The approach therefore fits best for companies where knowledge is shared internally by default. Where knowledge is strongly separated by confidentiality levels, it requires either multiple repositories or an architecture where the permissions of the source system are passed through. That then speaks more for MCP connections with user authentication, at least for sensitive sources. And personal matters stay out in any case: direct messages, messenger histories, and private notes belong in a personal memory, not in the company's.

State of the last sync instead of live data. A daily sync means the agent knows in the files the state of the last run. For wiki, tickets, and protocols, this is unproblematic. For inventories, prices, or account balances, it is not; such questions belong to the command-line tools or to a live interface. The sensible architecture is hybrid: files for memory, tool connections for actions and real-time data.

Connectors are the bottleneck. The agent only knows what a script can fetch. Systems without usable API or export function remain blind spots. You should know these gaps before starting, not afterward.

Context files are not self-running. A study by ETH Zurich measured what context files like AGENTS.md actually accomplish in coding tasks: The success rate did not increase on average, but inference costs rose by over twenty percent. Concrete instructions were followed, general repository overviews didn't help. Translated to the Company Brain, this means: A good AGENTS.md tells the agent how to search and what the folders mean. It doesn't tell it what the company does. Every line of context costs attention and money, so it deserves a justification.

Curation needs responsible parties. Filtering, merging, and linking are not one-time tasks. Without a person who maintains the repository, reviews the skill pull requests, and observes the questions in the channel, it runs wild like any wiki. The advantage over the wiki: The agent itself can help with maintenance, for example by reporting contradictions between files.

Data protection. As soon as customer data flows to a model provider, the usual requirements for commissioned processing and data minimization apply. The decision about which fields to remove before sync is not a technical one but an organizational one. It belongs at the beginning of the project.

Buy or build?

The market now offers ready-made knowledge platforms with rights management, compliance certificates, and interfaces for departments. Finished products are the right choice when fine-grained permissions are non-negotiable or when nobody in the company can maintain a repository. For technology companies, the calculation is currently different: A cloud agent and a Git repository full of markdown files are so cheap and set up so quickly that a switch to a purchased product would rather mean a step backward. Nobody has solved the topic comprehensively yet. In one to two years, there will very likely be mature products that take over many of the described problems, and then the decision shifts. Until then, the self-built Company Brain wins where speed, control, and independence count: Every line is visible, and the knowledge remains in an open format that any future agent and any future product can read. From our experience, this vendor independence is the underestimated factor.

How to start pragmatically

A Company Brain doesn't have to begin as a major project. Our recommendation follows the same logic we suggest for every AI use case on the path to pilot: start small, measure with real questions, then expand.

1. Choose two to three sources that have the greatest leverage. Usually these are support tickets, codebase, and documentation if the first use case is in support, or wiki and meeting notes if it's about product and customer knowledge.
2. Set up private repository, connect connectors, set up sync via CI. An afternoon with a coding agent is sufficient; it writes the scripts mostly by itself.
3. Write an AGENTS.md that explains what is where. Short, concrete, with examples of good search strategies.
4. Test with twenty real questions. Questions that were actually asked in the last month. Where the agent fails, usually a source or a cross-reference is missing, rarely a better model.
5. Curate. Filter, merge, link. Only now is it worth opening the channel for the whole team.
6. Conduct security review. Sandbox network, positive list, tokens, protection levels of data, data protection, and the attack patterns from the security notes. Before opening, not afterward.
7. Add skills and automations. Only when the memory reliably answers do the pull request process for new skills and nightly derivations like ticket classification or weekly reports come into play.

What you avoid in this order: connecting all sources at once, opening the channel before the answers are reliable, and postponing the security review.

Outlook: the Company Brain for customers

The next stage is already emerging. Today, every communication to the outside runs through a human who checks the agent's answer and passes it on. For support requests, integration questions, and product details, this is a bottleneck that provides little value: The human translates what the system already knows. First companies are therefore testing a stripped-down version of their Company Brain that customers can directly query in shared channels without the confidential content itself flowing outward.

This turns the dangerous trio from a theoretical to a concrete problem: The agent has confidential data, reads messages from external parties, and responds to them. The controls from above then get a different weighting. This variant's data access is restricted, the output is checked before sending, and the shared channel ensures that both sides see what is asked and answered. Anyone who wants to manipulate an agent over a thousand messages doesn't do so unnoticed in a channel that the own team and the provider read along. This is not completely solved. But it is the direction in which customer communication will develop, and anyone who builds the internal memory cleanly today has already done most of the preparatory work for this step.

Conclusion: Context is the actual work

The debate about AI in companies likes to revolve around models. The Company Brain shows that the bottleneck lies elsewhere: in the context an agent receives and in the form in which it receives it. Running a company has always meant giving the right people the right information at the right time. This ability doesn't become less important in an organization where agents collaborate, but becomes a core competency.

The Git repository as corporate memory is a remarkably robust tool for this. It is versioned, inspectable, tool-independent, and set up in hours. Its weaknesses (unified access level, state of last sync, ongoing maintenance requirements) are known and manageable. We work internally with versioned skills and context files for our agents and see the approach as a natural extension of this practice to all corporate knowledge. For decision-makers seeking entry into agent systems without binding themselves to a platform, it is currently one of the most down-to-earth paths: little magic, much craftsmanship, quickly measurable benefit.