AI coding tools can read an entire repository and still misunderstand the system.
The problem is rarely a lack of tokens. The agent can inspect files, search documentation, and open pull requests. What it cannot infer reliably is why a service exists, who owns it, which downstream systems depend on it, or why the obvious refactor was rejected six months ago.
That information usually exists somewhere. It is split across old Slack threads, architecture diagrams, tickets, commit messages, and the memories of the people who built the system. Giving an agent a larger context window does not organize any of it. It only gives the agent a larger pile to search.
Teams adopting AI development tools need to treat context as infrastructure.
The context problem is an architecture problem
Most coding agents start with the repository. That works well for a contained task, such as adding a validation rule or updating a component. It becomes less reliable when the work crosses service boundaries.
A repository can show that one application calls another. It may not explain that the receiving service is being retired, that a third team owns the migration, or that a compliance rule limits how the data can be stored. The code describes the current implementation. It does not always describe the organization around it.
This is why agents can produce code that is technically correct and operationally wrong.
Spotify's Xirp describes itself as an agentic development environment with institutional memory. Connected to Spotify Portal, it gives agents information about services, ownership, dependencies, and architectural decisions instead of limiting them to the file currently open.[1] Backstage, the open source foundation behind Portal, uses a centralized software catalog to track services, libraries, websites, machine-learning models, ownership, dependencies, deployments, and related resources.[2]
The idea is simple: an agent should not have to rediscover the company every time it starts a session.
A catalog gives context a home
Many teams attempt to solve this with documentation. The result is often another folder that slowly becomes outdated.
A software catalog takes a different approach. It creates a structured inventory of the systems the company operates. Each component can have an owner, lifecycle state, dependency map, repository, deployment information, documentation, and operational metadata.
That structure helps humans answer basic questions quickly. It is even more useful for agents because the information can be retrieved consistently. Instead of searching five repositories and guessing which README is current, an agent can ask for the system record and follow its declared relationships.
Backstage also supports software templates that encode an organization's preferred project setup.[2] That matters because good context is not limited to explaining what already exists. It can guide new work toward approved patterns from the beginning.
A useful catalog should answer questions such as:
- Who owns this service?
- What depends on it?
- Which environment is authoritative?
- What data does it handle?
- Which deployment and testing standards apply?
- Where are the decisions that explain its current design?
If those answers are unavailable to engineers, they will also be unavailable to their agents.
Graphs are useful when the answer takes more than one hop
Search works well when the question and the answer use similar words. It becomes weaker when the answer depends on a chain of relationships.
A small knowledge graph can model those relationships directly. The graph-memory-starter project demonstrates this with three SQLite tables, typed relationships, a recursive query, and a prompt hook. Its example questions require the system to follow several connections before returning an answer.[3]
The same pattern applies to software. A change request may touch a function, which belongs to a service, which publishes an event, which feeds a reporting workflow owned by another team. A text search can find each piece. A graph makes the path explicit.
The code-review-graph project applies this idea to source code. It builds a persistent structural map using Tree-sitter, updates it incrementally, and exposes relevant context to coding tools through MCP.[4] Rather than repeatedly reading large portions of a repository, an agent can retrieve the symbols and relationships connected to the change it is reviewing.
This does not mean every company needs a large graph database. A useful first version may be a software catalog, repository metadata, a few typed relationships, and a retrieval endpoint. The goal is not to model the entire company. It is to make the important relationships dependable.
Better context also needs boundaries
Centralizing context creates a new responsibility. Agents should not receive every piece of company information simply because it is available.
The context layer needs the same access controls as the systems it describes. Customer data, credentials, private conversations, and restricted operational details should remain outside a general coding-agent retrieval path. Context should be selected according to the user, task, repository, and environment.
It also needs provenance. An agent should be able to distinguish a current system record from an unverified note written two years ago. Ownership, update timestamps, source links, and lifecycle states help it decide which information deserves trust.
Without those controls, a context platform becomes a faster way to distribute stale or sensitive information.
Start with one expensive question
The best starting point is not "build an enterprise knowledge graph." Start with a question your team repeatedly spends time answering.
It might be:
- Which applications use this shared library?
- Who can approve a production change to this service?
- What breaks if we change this event schema?
- Where has this function already been implemented?
- Which repositories need the same security update?
Document the sources needed to answer that question. Turn the durable parts into structured records and relationships. Then expose only that narrow context to an agent and compare the result with the current search-heavy workflow.
The test is practical: does the agent open fewer irrelevant files, make fewer incorrect assumptions, and produce a change that requires less architectural correction?
If it does, expand from there.
Context is becoming part of the development platform
Model quality will continue to improve, but stronger models do not remove the need for company-specific knowledge. The more work agents perform, the more expensive a missing ownership rule or hidden dependency becomes.
Teams have spent years improving pipelines for code, tests, deployments, and observability. Context now deserves the same treatment. It needs sources, structure, access controls, update paths, and an owner.
At Correll Technologies, we help teams design software systems that remain understandable as they grow. If your developers are adopting AI tools while working across fragmented repositories, documentation, and internal services, we can help build the catalog, retrieval layer, and integration strategy that gives those tools reliable context. Start a conversation with our team.
Sources
[1] Xirp