Siemens and Google Cloud are making a strong case that the next frontier in enterprise AI is not better autocomplete, but better coordination.
In a system called Knowledge Fabric, the companies are applying domain-aware graphs, Spanner Graph, and a toolchain that includes Gemini, Google’s Agent Development Kit, and Claude Code to modernize sprawling industrial codebases. The pitch is bigger than a coding assistant. It is an attempt to let AI understand the structure of industrial software well enough to plan, sequence, and execute parts of the software development lifecycle itself.
That matters because Siemens is not dealing with a neat product repo or a few microservices. The company describes codebases that span hundreds of millions of lines and have evolved over more than a decade. In that setting, generic coding tools run into a familiar wall: they can suggest snippets, but they do not know enough about the system to safely navigate dependencies, documentation, and domain intent. Knowledge Fabric is designed to close that gap by turning software modernization into a graph problem first and an LLM problem second.
What Siemens is actually building
The architectural idea is straightforward but consequential. Knowledge Fabric maps code, documentation, and domain knowledge into a graph that encodes relationships the model can reason over. Spanner Graph provides the underlying graph database substrate, giving the system a way to store and query those relationships at enterprise scale.
That graph layer is what makes the system more than a wrapper around a model API. Instead of asking an LLM to infer context from a prompt or a narrow retrieval set, the system can traverse explicit links among code modules, dependencies, documents, and likely business domains. That is the foundation for agentic behavior: the AI is not just answering questions about the codebase, it is using the graph to decide what to inspect next, what change is likely to ripple elsewhere, and which supporting artifacts need to stay aligned.
The stack Siemens and Google Cloud describe includes Gemini, ADK, and Claude Code as execution layers. In practice, that suggests a multi-agent workflow in which models are not acting alone. They are being orchestrated against a structured representation of the system they are changing. For industrial software, that distinction is essential. A large-scale modernization task often depends less on raw code generation than on sequencing: identify the relevant service, understand the domain boundary, update dependent logic, revise documentation, and verify that the change fits the larger system.
A graph-centric architecture is well suited to that kind of work because it preserves context instead of flattening it. The more legacy and interdependent the software, the more valuable that preserved context becomes.
From assistive coding to agentic SDLC automation
The most important shift here is conceptual. Traditional AI coding tools are mostly assistive: they autocomplete, summarize, explain, and sometimes generate a function or test. Knowledge Fabric is aimed at orchestrating the software development lifecycle, which is a different class of problem.
In an industrial setting, that means AI can be asked to participate in tasks such as modernization, documentation alignment, and dependency-aware changes across large code surfaces. The system’s promise is not that it can replace engineers, but that it can reduce the amount of manual coordination required when a change touches many layers of a complex application.
That is why Siemens’ framing around “slicing the elephant” is apt. The challenge is not one large codebase in the abstract; it is the need to decompose an enormous modernization problem into tractable pieces without losing system-level intent. A graph-driven agent can, in theory, help partition the work: which components are in scope, what upstream or downstream references matter, what documents define the desired behavior, and what checks need to run before a change can be trusted.
The evidence so far points to a system that is engineered for that orchestration problem. It is not just retrieving snippets. It is building a machine-readable representation of industrial knowledge and then using model-driven agents to act on that representation.
Why the timing matters now
The timing is as important as the architecture.
This announcement landed in mid-June 2026 with immediate press and analyst attention, and that matters because enterprise AI has been moving through a predictable arc. First came copilots for individual developers. Then came retrieval-augmented tools for internal knowledge bases. The next question has been whether AI can actually participate in systems work that spans multiple repositories, documentation sets, and business domains.
Siemens and Google Cloud are signaling that the market is ready to test that leap.
There are a few reasons this moment is different. Enterprises now have more confidence in foundation models, more vendor options for orchestration, and better primitives for building controlled agent systems. At the same time, the cost of legacy modernization remains acute, especially in industrial environments where software is tied to physical operations and long-lived assets. If a system can safely reduce the labor involved in understanding and updating that software, the business case is no longer speculative.
Just as important, the market has started to distinguish between AI that demonstrates novelty and AI that fits operational reality. Knowledge Fabric is relevant because it is targeted at the latter. It is designed around codebases that are too large, too old, and too domain-specific for generic assistants to handle well. That is the kind of problem enterprise buyers recognize immediately.
What adopters should actually evaluate
For customers, the question is not whether this looks impressive. It is whether the architecture changes the economics and risk profile of software delivery.
The first procurement question is tooling strategy. If a graph-backed agentic system becomes part of the SDLC, teams will need to decide where it sits relative to existing IDEs, CI/CD pipelines, code review workflows, and documentation systems. A solution like Knowledge Fabric should not be evaluated as a standalone assistant. It should be judged on how well it integrates with the systems engineers already trust and how cleanly it hands control back to humans when a task becomes ambiguous or high risk.
The second is governance. A domain-aware graph improves context, but it also creates a new asset that must be curated. Enterprises will need policies for what gets encoded into the graph, how changes are versioned, which agents are allowed to act on which classes of artifacts, and how outputs are audited. In industrial software, where errors can affect factories, grids, or transport systems, governance is not a compliance afterthought; it is part of the product architecture.
The third is cost and ROI. Agentic workflows can reduce time spent on modernization and alignment, but they also introduce new operating costs: graph construction, model inference, orchestration, evaluation, and ongoing maintenance of the knowledge layer. Buyers should be skeptical of claims that assume unlimited automation. The more useful question is where the system removes bottlenecks that are currently expensive, repetitive, and measurable.
A practical pilot should therefore focus on narrow but high-friction workflows. Examples might include legacy module dependency mapping, documentation synchronization after code changes, or guided modernization of a bounded application domain. Those are the kinds of tasks where graph context and agent orchestration can be benchmarked against human effort.
The longer arc for industrial software delivery
If Knowledge Fabric proves durable outside a demo, it could reshape how industrial software teams think about modernization.
Instead of treating legacy systems as monoliths that only specialists can safely touch, enterprises could increasingly manage them as graph-structured assets with AI agents operating on top. That would affect not just development speed, but the way teams are organized, how knowledge is transferred, and how vendors position their tooling.
It would also raise the bar for competitors. Coding assistants alone will not be enough in domains where the real challenge is not generating code, but understanding consequences across a complex operational stack. Vendors will need stronger answers on graph modeling, policy enforcement, auditability, and integration with enterprise SDLC systems.
The broader implication is that industrial AI may be entering a phase where the winning systems are the ones that can combine domain knowledge with controlled autonomy. Siemens and Google Cloud are not claiming to have solved that problem universally. But they are showing what a credible version of the answer looks like: not a chatbot on top of a codebase, but a graph-aware operating layer for software change.
That is a meaningful shift. And if it scales, it will change what enterprises expect AI to do inside the software lifecycle.
