Architecting Graph Based Factual Layers for AI Agent Productivity

In modern software engineering, the primary competitive advantage is no longer just writing code. It is building the connective tissue that allows AI agents to reason about the entire production system. By moving beyond agents limited to a single repository toward a graph based, system wide factual layer, engineers can achieve a level of operational control that was previously impossible. The primary bottleneck to AI productivity is not model intelligence, but context starvation. Organizations that map their infrastructure, code, and traffic into a unified graph will see compounding returns in developer velocity and incident response. This is a guide for platform teams and engineering leaders who want to move from prompting agents to architecting systems that agents can actually master.

The Hidden Cost of Repo Blind Agents

Most coding agents operate in a vacuum, limited to the files directly in front of them. Mat Jones, a staff engineer at Adyen, argues that this creates a fundamental ceiling on productivity. When agents lack visibility into the wider system, such as DNS chains, data store topology, and infrastructure, they are essentially guessing. By building Architect, a graph based factual layer, Jones allowed agents to query the reality of the system rather than hallucinating it.

> The fact that you can now multitask a lot heavier. So like my workflow at the moment is Mondays especially work from home it is great so I will open dev in factory, whatever. And then I will have something like four or five agents next to each other.
>
> -- Mat Jones

The consequence of this visibility is a shift in the role of the engineer. Instead of debugging individual services, the engineer becomes an orchestrator of parallelized AI agents. This parallelization is only possible because Jones built Atrium, an internal memory sharing layer that prevents agents from stepping on each other. The result is that features are delivered in parallel rather than sequentially, creating a massive divergence in output compared to teams still working with single agent, repo bound workflows.

Why the Obvious Fix Makes Things Worse

Conventional wisdom suggests that if you want to understand your system, you should query it directly via logs or recursive SQL functions. Experience proves this leads to immediate system collapse. When the team attempted to ingest 7 million trace spans a second into a relational database using recursive functions, the CPU spiked to 100 percent and the database administrators intervened.

The system failed when faced with this obvious solution. The lasting advantage came from a shift in architecture: moving to Apache Flink for stream processing and aggregating data before it hits the graph database.

> It turns out that it was really good until we pointed it at life. OK. Because for our test environments, beat your environment, very small number of traces compared to the live platform. So all of a sudden we pointed it on live, seven million spans a second.
>
> -- Mat Jones

This teaches a lesson in systems thinking: performance at scale is not a linear extension of performance in testing. By accepting that they did not need 100 percent of the trace data, only the connective tissue between services, they reduced the write volume to 4,000 records per second. This created a sustainable, high throughput system that works in production.

The 18 Month Payoff: From Reporting to Auto Fixing

The ultimate goal of Architect is not just visibility, but Sentinel, an anti pattern monitoring system that identifies issues and automatically raises merge requests. This creates a feedback loop where the system maintains itself.

The immediate discomfort of this approach is high. It requires months of groundwork, negotiating access with telemetry and infrastructure teams, and building complex ingestion pipelines. Most teams will not wait for this. However, the payoff is a moat of operational excellence. By knowing which code changes affect critical payment flows, the team can implement dynamic gating, allowing low risk code to bypass manual review while enforcing 100 percent test coverage on critical paths. This is where delayed payoffs create a massive competitive advantage. While competitors are frozen by fear during peak seasons, teams with this level of visibility can continue to ship safely.

Key Action Items

• Build the Skeleton First (Immediate): Start with a service graph. Do not attempt to map code or infrastructure initially. Focus on the HTTP and database calls that connect your services. This provides the highest immediate utility for observability.
• Implement an Agent Communication Layer (Over the next quarter): If you are running multiple agents, build a simple Atrium style memory layer. This prevents agents from overwriting each other and allows them to synchronize commits, which is essential for parallel development.
• Adopt Graph Based Context (Over 3 to 6 months): Move away from raw logs for AI context. Store service dependencies, data schemas, and infrastructure topology in a graph database like Neo4j. This reduces token usage significantly by allowing agents to perform lookups instead of re reading codebases.
• Prioritize CLI over Tool Bloat (12 to 18 months): Do not fall into the trap of creating dozens of MCP tools. If a task can be performed by a simple script or a CLI tool, use that. It is more deterministic and reduces the infinite loop risk where agents get confused by an excess of interface options.
• Shift from Human Readable to Agent Readable Documentation (12 to 18 months): Begin generating documentation like flow diagrams that is specifically designed for agents to ingest. This creates a contract that agents can verify, reducing the reliance on human to human communication for system alignment.