A 45-Minute Answer to One Question

“It’s 3am. An engineer gets paged. A service is throwing errors, and the first question is always…” That’s how Adyen’s engineering team opens its account of Architect, the system it built to map its own platform. The question: “What actually depends on this thing?” Adyen provides end-to-end payments, data insights, and financial products in a single global platform. Its customers include Meta, Uber, H&M, eBay, and Microsoft (Adyen). On Adyen’s platform, answering that question used to mean “forty-five minutes of tab-juggling,” with traces in one window and the code repository in another. But the answer often lives in three places: the code that makes a call, the runtime traces that record it, and the hosts it runs on. At Adyen, those are three domains that normally live in three different tools, owned by three different teams. The code alone spans roughly 250,000 classes. Around 3,000 live services run on tens of thousands of hosts. “It turns out no single person can hold all of that in their head,” the team wrote. Architecture diagrams were “usually correct in spirit and approximate in detail.” AI agents hit the same wall. “Production generates up to 7 million tracing spans per second, so ‘just feed it the context’ turned into hundreds of millions of tokens before we admitted there had to be a better way,” the team wrote. The team summed up the problem: “Most workflows (for both agents and humans) share the same failure mode: they’re guessing.”

Three Graphs Built From What the Platform Does

Adyen’s answer was Architect, “a near real-time, queryable map of how our platform actually fits together, stitched from three graphs.” Instead of relying on static diagrams or manual mappings, Architect “continuously builds an understanding of how the platform behaves and how its code is structured.” The team’s principle: “Observed architecture beats imagined architecture.” The graphs that build up Architect are:

• Service graph: around 3,000 live services and the ~470,000 calls between them. Every workload in every environment emits trace data to Apache Kafka. Apache Flink processes every trace, up to 7 million per second, and extracts and aggregates the calls.
• Code graph: roughly 250,000 classes across 6,000+ modules. Full builds every four hours “eventually became very painful,” so the team moved to incremental builds. A git poller picks up changes, and builds run inside a TaskManager container that holds a cloned, fully built copy of the repository.
• Infrastructure graph: tens of thousands of hosts across tens of data centers, with ~900 metadata items per host. It maps the full hierarchy from platform region and infrastructure region through availability zone, data center, floor, rack, physical host, and virtual machine. Infrastructure changes less often, so scheduled jobs refresh this graph a couple of times per day.

One Query Across Code, Runtime, and Infrastructure

Adyen keeps the three graphs as separate Neo4j databases and bridges them with a composite database. A composite database lets a single Cypher query reach several graphs without storing a merged copy. Each graph keeps its own pipeline and refresh rate: continuous for traces, per change for code, and a couple of times per day for infrastructure. Engineers and agents still query all three at once. In a graph, the connections between a service, the code behind it, and the hosts it runs on are stored as relationships, so a query can follow them directly. Without that structure, an agent has to read the raw material and infer the connections on its own. At Adyen, a single graph query “returns what would otherwise be thousands of lines of context the agent has to read.” Architect is built from observed behavior. In the team’s words: “If it exists in the graph, it is happening. No interpretation. No hallucination.”

From Guessing to “The Graph Says So”

Adyen built Architect for its engineers first. “Then we gave our agents the same map, the same factual foundation, and the forty-five minutes became a few seconds,” the team wrote. AI agents now work from what the team calls “a factual substrate: pre-computed, verified, and queryable.” The result, the team wrote, is “a different confidence level.” The questions agents now answer cross the lines between code, runtime, and infrastructure:

• “Is this runtime dependency actually referenced in the code, or can we drop it?”
• “There’s a hurricane headed to the data center. Which critical flows go down, and what do we shift where?”
• “Can we modularise this service without quietly breaking a production caller?”

Each one needs data from at least two of the three graphs. No single log store, repository, or host inventory can answer it.

The team has implemented resilience health rules on the combined data. Other uses include security tabletops, disaster simulation, and anti-pattern monitoring across code, runtime, and infrastructure. Architect also encodes “the institutional knowledge which would otherwise take a new engineer (or a new agent) months to absorb.” The team’s summary: “If your agents don’t have grounded context, they’re expensive autocomplete. If they do, they become genuine reasoning partners.”

What’s Next for Architect

Adyen is publishing a series on how agents use Architect, one domain at a time: reasoning about runtime incidents, untangling compile-time complexity, and making sense of infrastructure resilience. “Architect is not a graph project. It’s the foundation that makes agentic engineering actually work at our scale,” the team wrote. And it isn’t finished: “Architect is built to become Adyen’s living brain for agents and humans, and it’s only finishing elementary school.”

CTA: Read Adyen’s Full Account of Architect