The Knowledge Graph as the Foundation of Agentic Modernization

The first two posts in this series argued that the knowledge about a company lives in its legacy code and showed how a cited as-is specification can be reconstructed from it. One question remained open, and it decides whether agentic modernization succeeds or fails: in what form must this knowledge exist so that AI agents can work with it? My answer is unambiguous: not as documents, but as a knowledge graph. This post explains what that means, how such a graph is built, and why it is the foundation of every agentic initiative on existing systems.

Agents are only as good as their context

Anyone who points an AI agent at a legacy system today quickly runs into the limits of the approach. The agent receives a functional concept from 2011, a wiki of uncertain currency, and access to a few million lines of code. What it produces is an interpretation: it searches for passages, combines them, and formulates a plausible answer. Whether the rounding rule for a particular contract type still applies, whether the interface it is supposed to change is needed by a nightly batch, whether the table is still written by a second program: none of that is in any document, and where it is not written down, the model guesses. Hallucinated requirements, overlooked dependencies, and rework consume the efficiency gain that justified the initiative in the first place.

The problem lies not with the model but with the form of the knowledge. Documents are written for people who know the context and close gaps from experience. An agent has no such experience. It needs facts it can query: which program writes which table, which job triggers which other job, under what condition a rule applies, and for each of these statements the evidence in the source code or in observed usage.

In the first post of this series I described why legacy is a knowledge archive; in the second, how we reconstruct the cited as-is from it. The third step is the question of form: machine-readable legacy knowledge is the prerequisite for agentic modernization to begin at all.

What a knowledge graph is and what it contains

A knowledge graph stores the knowledge about a system as typed nodes and relationships. Nodes are the things a system is made of: programs, enhancements, tables, interfaces, screens, batch jobs, business rules. Relationships describe what actually happens between them: a program calls another one, writes to a table, is triggered by a job, renders a screen, logs to an audit log. Every node carries a business description and a technical description, the locations in the source code, and the version of the analysis run it came from.

Three properties distinguish this graph from any collection of documents:

• Typed. Entities and relationships follow a strict schema. A query returns facts, not passages of text: not "documents in which the table is mentioned," but "the six programs that write to the table."
• Versioned. Every analysis run is a version. What changed between two releases becomes visible and auditable instead of disappearing into the history of a wiki.
• Cited. Every statement traces back to source lines in a program or to a screenshot and event log. Trust is verified, not assumed.

We populate the graph from two directions. SLIP, the Sysparency Legacy-Code Intelligence Platform, reads the source code and establishes the facts in a deterministic, symbolic analysis: call and dependency graphs, data reads and writes, screen and process flows, interfaces and jobs. App2Spec observes the application in use and turns screenshots and events into standardized entities: screens, controls, navigation paths, data fields, business rules, and process steps. Both paths store their results as typed, cited entities according to a fixed schema, and every analyzed system is modeled to the same standard. That is why a mainframe core system is structured in the graph exactly like a web application, and why statements can be connected across system boundaries.

Symbolic first, generative second

The order in which the graph is built is not a technical footnote. First, the symbolic analysis establishes the structure: complete, deterministic, reproducible. Only then do AI agents read the symbolic model and the source code and explain every component twice, in business terms for process owners and in technical terms for architecture and development. The AI does not invent a structure; it explains a proven one. In the graph, both layers remain separate: the exact facts from the analysis and the generated explanations, each with a reference to its source. That is the quality bar auditors and architects can accept, and it is the reason agents may trust the graph even though they should not trust documents.

From artifact to infrastructure: the graph as the fact base for agents

The knowledge graph unfolds its full value when it is connected to agentic AI systems via the Model Context Protocol (MCP). Any compliant agent platform, whether a coding agent, a transformation copilot, or an enterprise assistant, queries the graph directly and receives exact, cited facts about the landscape. The agent no longer has to interpret the legacy estate from documents; it asks.

Documentation used to be an artifact. For agents, it is infrastructure.

This inverts the usual economics of AI in the enterprise. Until now, every AI initiative built its own context: collect documents, ingest code, interview experts, and start over with the next project. With one central graph, all agentic initiatives inherit the same foundation. Four applications show the difference:

• Impact analysis in seconds. The question "We want to retire this interface. Which programs write to the material master through it, and which batch jobs break?" used to require days or weeks of investigation across teams and time zones. With the graph it is a query; experts review the answer instead of assembling it.
• Evidence-based scoping. Whether an S/4HANA transformation, a carve-out, or a replacement: the scope is counted from the inventory, not estimated from interviews.
• Test derivation. From cited business rules and process flows come test cases that safeguard the actual behavior of the legacy system, not the remembered one.
• Grounded agentic development. Coding agents that build the target system in the agentic Software Development Lifecycle query the graph for the interfaces, data structures, and rules of the legacy estate instead of guessing them.

The last point is the decisive one for us. When reqCoder, ReqPOOL's complete, fully automated agentic Software Development Lifecycle, which is already in use internally at ReqPOOL, generates software from a to-be specification, the as-is in that specification comes from the graph, and so does the context for the agents' decisions. Without this graph, agentic development on legacy systems remains an experiment; with it, it becomes fit for acceptance.

One graph for the entire landscape

A knowledge graph shows its value not on a single system but across the landscape. Large organizations do not operate one legacy system but dozens: ERP instances per region, mainframe core systems, custom software, standard software with extensive customizing. According to analyses by Sysparency, the custom development on a single SAP instance in large industrial groups frequently comprises tens of thousands of objects. As long as each system is documented on its own, the edges between them remain invisible: the interface through which the warehouse system waits for a batch to finish in the ERP, the table that is read by three systems.

Because all systems land in the same graph, exactly these cross-system relationships emerge. Three principles make this possible:

1. One standard. Every system passes through the same pipeline and is stored according to the same schema. Divisions, regions, and legal entities become comparable.
2. Repeatable on demand. The analysis is run again after every release and before every program. A one-time study describes the landscape as it was on a given day and starts aging immediately; the graph tracks the landscape instead of trailing it.
3. Wave by wave. The entry starts with one system; the rollout proceeds in waves. Each wave adds systems to the same graph, so the value compounds instead of fragmenting into project silos.

I consider this point underestimated. Most modernization programs do not fail on the individual system but on the dependencies nobody knew about. A graph that models the landscape makes the impact of a change known before the change is made.

The graph belongs to the organization

A foundation is only a foundation if it stays. That is why three commitments are non-negotiable for us. Documentation, knowledge graph, and assistant remain with the client as working tools; knowledge about the systems no longer depends on individual heads, and not on us either. The graph does not depend on the model provider: the facts come from the symbolic analysis, not from the language model; if the model is replaced, they remain, and only the generated explanations are rewritten. And access is governed per role, per system, and per agent, so that a coding agent sees only what it needs for its task.

Add to this the conditions that are decisive for banks, insurers, utilities, and public administration: extraction reads code and metadata, no business data; analysis runs in a client-specific environment in the EU; client data and source code are never used to train AI models; and in ReqPOOL consulting projects there are no license costs for the platforms used. You pay for expertise and effort. The graph is yours.

What this means for your modernization program

In our projects, an approach has proven itself that begins with the graph and not with the target architecture:

1. Select one system. A representative, business-critical system, ideally one with an open transformation question right now.
2. Run the full pipeline. Extraction, symbolic analysis, agentic interpretation, and consolidation in the graph; based on our experience from ReqPOOL projects within days, verifiable per project.
3. Test against reality. Your experts challenge the graph and the assistant with their hardest current questions, including via MCP from their own agent tools.
4. Decide on the rollout. Extend the landscape wave by wave and make the graph the basis of the to-be specification and of agentic delivery.

The order matters because it brings the most expensive insight forward. Those who design the to-be first and understand the legacy later find the dependencies during acceptance. Those who start with the graph know them on day one.

The next step

If you want to point agentic tools at your legacy systems, the knowledge graph is the first step, before the first agent. How we turn legacy systems from source code and usage into a cited graph is described in our service Reverse Engineering; the platform that builds the graph from source code and opens it to agents via MCP is presented on the SLIP page. In an expert conversation we clarify which system you should start with and which transformation question makes a suitable first test.