AI coding agents are becoming remarkably capable at understanding and modifying software. But as organizations deploy them across large monorepos and complex microservices environments, a harder problem emerges: AI coding context.
The model may be capable of making a change while still lacking the organization wide context required to make the right change safely.
A developer can ask an AI coding agent to deprecate an API field, update an authentication flow, or modify a gRPC service interface. The agent can inspect the code available on the developer's machine and search for references. What it may not know is that the field is consumed by four other services across separate repositories, that one of those services belongs to another team, or that the same field eventually carries sensitive data into a third party integration.
This is not simply a context window problem.
It is a context engineering problem for AI agents: how do we provide agents with accurate, current, organization-wide evidence about how software actually behaves?
One approach is to generate that evidence directly from source code using deterministic static analysis, continuously update it as the code changes, and expose it to AI agents through the Model Context Protocol, or MCP.
The resulting context layer can serve more than AI coding agents. The same evidence about services, APIs, callsites, fields, third party integrations, and sensitive dataflows can support application security, privacy data mapping, AI governance, SOC investigations, and compliance.
What if AI agents could interact with your organization's service graph?
Imagine being able to visually explore the services, APIs, dependencies, sensitive dataflows, and third party integrations across your organization, then query the same service graph using natural language.
An engineer could ask which gRPC services depend on a particular API before changing it. A security or privacy team could ask which third party integrations receive PII. An AI governance team could ask which AI integrations exist and what sensitive data reaches them.
The graph becomes more than documentation. It becomes an interface to the organization wide context hidden across the codebase.
For example, asking “Which third party integrations receive PII?” can query the underlying dataflow graph and surface the relevant integrations, sensitive data elements, repositories, code locations, and risk status.
The same context can then be exposed programmatically to AI coding agents through MCP.
Instead of asking an AI agent to reconstruct these relationships from source code every time, the underlying evidence already exists and can be queried when needed.
Claude Code at Scale: The Harness Matters as Much as the Model
Anthropic has published guidance based on Claude Code deployments across multimillion line monorepos, legacy systems, distributed architectures spanning dozens of repositories, and organizations with thousands of developers.
One of its most important observations is that the harness matters as much as the model.
That harness can include CLAUDE.md files, hooks, skills, plugins, Language Server Protocol integrations, subagents, and MCP servers.
The reason becomes apparent when looking at how Claude Code and other AI coding agents navigate large codebases.
Claude Code uses agentic search. It traverses directories, reads files, uses tools such as grep, and follows references to find the code relevant to a task.
That works remarkably well when the agent has enough starting context to know where to look.
The challenge grows when the answer spans multiple services, repositories, teams, or protocols.
An agent may need to search through enormous amounts of code merely to establish the relationships it needs before it can begin solving the actual problem.
Where CLAUDE.md helps
CLAUDE.md provides a useful mechanism for giving Claude Code persistent instructions and knowledge about a codebase.
Teams can use it to document architecture, development commands, conventions, important directories, workflows, and other information the agent would otherwise have to discover repeatedly.
For large organizations, however, manually maintained context has an inherent limitation: software changes continuously.
Services appear and disappear. APIs evolve. New consumers begin using fields. Ownership changes. Developers introduce new SDKs and external integrations.
CLAUDE.md is therefore valuable for relatively stable knowledge and instructions, but it is not necessarily the ideal database for continuously changing relationships such as:
Service → API → Method → Field → Consumer → Callsite
This is where automated context discovery becomes useful.
Why API Specifications Are Not Enough for AI Coding Agents
Consider a protobuf definition for an Address message:
message Address {
string street_address = 1;
string address_line_1 = 5;
string address_line_2 = 6;
string city = 2;
string state = 3;
string country = 4;
}
Suppose an engineer asks Claude Code or another AI coding agent:
Deprecate street_address and migrate consumers to address_line_1.
The protobuf schema provides excellent documentation of the Address message.
But it does not necessarily tell the agent every service consuming street_address, every callsite where the field is referenced, which repositories contain those consumers, or which teams own them.
This is the difference between protobuf documentation and actual runtime architecture context derived from the code.
The same problem applies to OpenAPI, GraphQL, and other API specifications.
API specifications describe contracts. They do not inherently provide a continuously updated map of every downstream consumer and field usage across an organization's software estate.
In one test monorepo we use at HoundDog.ai, what appears to be a one line protobuf change affects four services, three teams, and two programming languages.
Without that context, the AI agent has to reconstruct the relationships itself.
It searches repositories, follows imports, greps for references, generates temporary scripts, and reasons about which results actually represent downstream consumers.
Then another developer asks a similar question and much of the discovery happens again.
API Discovery and gRPC Service Discovery Directly From Code
An alternative is to separate discovery from reasoning.
HoundDog.ai's Dataflow Context Engine uses a lightweight deterministic code scanner written in Rust to analyze source code and generate structured context about software architecture and sensitive dataflows.
For application architecture, the scanner can discover relationships such as:
Service → API → Method → Field → Consumer → Callsite
For security and privacy, it can map:
Sensitive Data → Transformations → Callsite → Log, Storage, API, Third Party, or AI Integration
The scanner performs interprocedural dataflow analysis across functions and files, allowing it to follow data through deeply nested application paths rather than relying solely on nearby syntax or simple pattern matching.
Because the discovery layer is deterministic, the same commit produces the same underlying graph.
AI can then be applied selectively to the resulting traces to provide context, adjust severity, and eliminate false positives.
This creates a useful division of labor:
Static analysis discovers. AI reasons. MCP delivers.
The model does not need the complete source code to perform the reasoning step. It can reason over the traces and structured context already extracted by the scanner.
The scanner is lightweight enough to operate directly in development workflows. In our testing, it can analyze 10 million lines of code in under a minute on standard CPU infrastructure.
That makes it practical to continuously regenerate context rather than periodically rebuilding a service catalog or data map.
Building a Service Catalog From Source Code
The same discovery process can generate a service catalog.
Traditional service catalogs often depend on developers registering services and keeping metadata current. That can work well, but it creates another system engineering teams need to maintain.
Code already contains much of this evidence.
A deterministic scanner can discover services, APIs, implementations, consumers, callsites, fields, dependencies, and other relationships directly from the software itself.
The resulting service catalog can answer questions such as:
- What services exist?
- Which APIs does this service expose?
- Which repositories implement them?
- Which other services depend on them?
- Which fields are actually consumed?
- Which teams own the affected code?
- Which services will be affected if this API changes?
This turns the service catalog from a mostly navigational inventory into an active source of context for humans and AI agents.
Microservices Documentation That Changes With the Code
Documentation has a freshness problem.
Creating microservices documentation once is relatively easy.
Keeping it accurate is much harder.
Large engineering organizations merge code continuously. Services appear and disappear. APIs evolve. Fields gain new consumers. Dependencies change. Developers introduce new SDKs.
A manually maintained architecture diagram or wiki can begin drifting as soon as the next pull request merges.
This is particularly problematic for AI agents.
Giving an agent more context is not necessarily helpful if that context is stale.
The alternative is to derive the documentation from the same source of truth that developers are changing: the code.
If service relationships, API dependencies, protobuf usage, and dataflows are regenerated as code changes, the organization gets microservices documentation that continuously reflects the implementation.
The goal is not simply better documentation.
It is evidence that regenerates itself as the code changes.
Context Engineering for AI Agents
This leads to a broader idea about context engineering for AI agents.
A model's context should not be treated as a giant bucket that organizations try to fill with as much source code and documentation as possible.
Different kinds of context have different characteristics.
Instructions and relatively stable organizational knowledge may belong in CLAUDE.md files or skills.
Symbol navigation may be best handled through LSP.
Source code can be inspected locally when detailed implementation reasoning is required.
But relationships that can be deterministically extracted from code can be computed separately and provided as structured context.
For example:
Code → Services → APIs → Fields → Consumers → Sensitive Dataflows → Third Party and AI Integrations
That representation is much smaller than the complete source code used to derive it.
It can also span repositories that the developer does not have checked out locally.
This is particularly important for large enterprises where the complete software estate may consist of hundreds or thousands of repositories.
Using an MCP Server for Organization Wide AI Coding Context
Once these relationships exist as structured data, an MCP server can expose them to AI coding agents.
The Model Context Protocol provides a standardized mechanism for agents to interact with external tools and information.
An AI coding agent can therefore ask the context engine:
- Which services consume
Address.street_address? - Which repositories call this RPC?
- Which fields from this API are actually used downstream?
- What is the blast radius if I change this service contract?
The MCP server does not have to rediscover those relationships when the question arrives.
It queries context that has already been generated from the organization's source code.
This becomes especially useful when the relevant code cannot physically exist on one developer's machine.
A centralized context engine can analyze selected repositories through source control and CI integrations and expose the resulting context organization wide.
The developer can continue working inside Claude Code or another compatible AI coding environment while gaining access to relevant relationships across repositories.
MCP therefore becomes the delivery mechanism.
The deterministic scanner remains the discovery mechanism.
Better AI Coding Context Can Reduce AI Token Cost
There is another consequence of this architecture: AI token cost.
Consider what happens when an agent needs to understand the blast radius of an API change.
Without precomputed context, the agent may have to inspect directories, search for definitions, read files, trace imports, find references, inspect protobuf definitions, identify consumers, and determine which results actually matter.
All of that consumes tokens and time before the agent begins making the requested change.
And the organization may pay that discovery cost again for the next developer asking a similar question.
Precomputing deterministic relationships changes the economics.
In one internal HoundDog.ai test using the same prompt and test monorepo, an agent without precomputed context spent 9 minutes and 57 seconds and approximately $1.75 reconstructing the relevant relationships.
When the same information was available through a single structured context call, the task took 1 minute and 23 seconds and approximately $0.29.
This is an illustrative internal measurement, not a universal benchmark. Different models, repositories, prompts, and tasks will produce different results.
But it demonstrates the underlying problem.
If AI coding agents repeatedly rediscover deterministic relationships, organizations repeatedly pay for that discovery through inference cost, latency, and context consumption.
At enterprise scale, that can become significant.
From gRPC Documentation to Change Blast Radius
The value of structured context becomes particularly apparent with gRPC and protobuf.
Traditional protobuf documentation can tell an engineer which services, RPCs, messages, and fields have been defined.
A context engine can go further by connecting those definitions to their actual consumers.
Suppose an engineer wants to deprecate:
Address.street_address
The useful answer is not simply:
street_address exists in Address.
The useful answer is:
These four services consume the field. These three repositories contain the affected callsites. These teams own them. These are the exact files involved. These downstream dataflows depend on the field.
That is the context an AI coding agent needs to reason about change blast radius.
It also illustrates why API discovery, gRPC service discovery, service catalogs, and AI coding context are closely related problems.
They are different views of the same underlying software graph.
Deterministic Evidence as the Baseline for AI Reasoning
There is already an important production example of this architectural pattern in security.
HoundDog.ai powers privacy code scanning for Replit, where our infrastructure currently runs approximately 100,000 scans per day across a platform serving more than 50 million creators.
Replit Security Agent combines deterministic security tools with LLM based reasoning rather than asking an LLM to discover every vulnerability from source code alone.
Replit's research into securing AI generated applications concluded that deterministic tools should establish the security baseline while LLMs provide contextual reasoning. Replit's CEO summarized the results by saying that combining current LLMs with deterministic tools such as static analysis produced “90%+ better outcomes.”
The distinction matters beyond vulnerability scanning.
Static analysis is well suited to answering deterministic questions such as whether a sensitive value can reach a logging function or external API.
An LLM is better suited to questions such as whether that behavior is appropriate given the application's purpose, how serious it is, and what remediation makes sense.
The combination gives the model evidence before asking it to reason.
Using Static Code Analysis to Discover Shadow AI
The same approach becomes increasingly important as organizations adopt AI.
Security, privacy, and governance teams face a deceptively simple question:
Where is AI actually being used across the organization?
An inventory based solely on procurement records, surveys, or known SaaS applications may miss AI introduced directly by developers.
A developer can add an AI SDK, framework, or API integration in a pull request. That integration may begin processing customer information without appearing in a central AI inventory or privacy data map.
Static code analysis provides another source of evidence.
HoundDog.ai recognizes more than 1,000 third party and AI integrations and traces more than 100 categories of sensitive data through application code into destinations including APIs, AI providers, logs, storage, and third party services.
Finding an SDK alone, however, is not enough.
The more useful question is:
What data actually reaches it?
For example, the scanner may detect that a medical history field is constructed into a patient context string, wrapped in a LangChain message, and ultimately sent to OpenAI.
That produces much richer evidence than simply reporting that the repository imports an AI library.
The same analysis can identify whether credentials reach logs, whether health identifiers reach an external CRM, or whether personal information flows into an analytics or communications platform.
For example, the underlying graph can trace a medical record number from its source through application logic and into Salesforce, including the exact callsites and code path responsible for the flow.
This is where software architecture context and privacy context begin to converge.
The same graph that tells an AI coding agent which service consumes a protobuf field can tell a privacy or security agent where sensitive information ultimately goes.
One Context Layer for Coding, Security, Privacy, and AI Governance
Once an organization has a continuously updated graph derived from source code, AI coding agents are only one possible consumer.
- A privacy agent could ask: Which third party integrations receive PII?
- An AI governance agent could ask: Which AI integrations exist, and what sensitive data reaches them?
- An application security agent could ask: Which sensitive values can reach this external API?
- A SOC investigation agent could ask: Which code path introduced PII into these application logs?
- An AI coding agent could ask: Which services will break if I change this protobuf field?
The underlying evidence can be the same.
This creates a useful architectural pattern:
Deterministic evidence first. Agentic reasoning second.
Why Not Just Build Another AI Agent?
There is an obvious alternative.
Why not simply build an AI agent that discovers all of this?
Give it access to every repository. Ask it to discover services, reconstruct API relationships, identify consumers, find SDKs, trace sensitive data, and maintain the resulting graph.
For smaller environments, that may be reasonable.
At enterprise scale, however, the economics become different.
If hundreds or thousands of developers repeatedly ask AI agents to reconstruct relationships across millions of lines of code and hundreds of repositories, the organization repeatedly pays for the same discovery through token cost, latency, context consumption, and compute.
Building a centralized discovery agent moves part of the problem rather than eliminating it.
The organization now owns another AI system that needs to understand every supported language, framework, API protocol, repository structure, and evolving code pattern while keeping its conclusions consistent and current.
There is a simpler architectural principle:
Compute deterministic relationships once, refresh them continuously in CI, and let authorized AI agents query the resulting evidence.
Use AI where reasoning is valuable.
Avoid paying AI to repeatedly rediscover facts that can be deterministically extracted from code.
The Missing Context Layer for AI Coding
The next phase of AI coding will not be defined only by better models or larger context windows.
It will increasingly depend on the infrastructure surrounding those models.
Claude Code at scale already illustrates the importance of the harness.
CLAUDE.md can provide persistent project knowledge.
LSP can provide precise symbol navigation.
Skills can supply specialized instructions.
MCP servers can connect agents to structured information outside their immediate context.
The missing piece for many large organizations is an accurate representation of the relationships hidden across their software estate.
For software organizations, one useful representation looks like:
Code → Services → APIs → Fields → Consumers → Sensitive Dataflows → Third Party and AI Integrations
That graph can power API discovery, gRPC service discovery, protobuf documentation, microservices documentation, and a continuously updated service catalog.
An MCP server can expose the same context to Claude Code and other AI coding agents.
And because the relationships are computed before the prompt arrives, agents can spend less time and fewer tokens rediscovering the codebase.
That is the larger opportunity for context engineering for AI agents.
Do not ask an AI agent to infer organization wide context from scratch every time it needs it.
Generate the evidence from code.
Keep it current at the speed of development.
Then make that context available to every authorized AI agent that can benefit from it.
Give Your AI Coding Agents the Context They Are Missing
Stop making AI agents rediscover your codebase with every prompt.
HoundDog.ai's Dataflow Context Engine generates continuously updated context about your services, APIs, fields, downstream consumers, dependencies, and sensitive dataflows directly from source code, then makes that evidence available to AI coding agents through MCP.