Why digital twins need memory as much as AI agents

A 2024 Hexagon survey of C-suite executives found 62% get immense value from digital twins, but the bottleneck has shifted to making them trustworthy enough for autonomy, which requires a robust memory architecture for AI agents operating within them. The article argues that digital twins need a unified data backbone to support long-running agent processes, as fragmented context across multiple stores undermines decision-making.

Digital twins https://www.cio.com/article/301522/what-is-a-digital-twin-a-real-time-virtual-representation.html began as virtual counterparts to physical systems. In aerospace, manufacturing, and other high-stakes environments, they gave engineers a safe way to observe behaviour, test scenarios, and reduce risk before making real-world changes. That framing now feels incomplete. Across supply chains, in energy networks and healthcare institutions, inside infrastructure, and in operations, digital twins are starting to look less like passive mirrors and more like decision environments. To that point, a 2024 survey of C-suite executives by Hexagon https://aliresources.hexagon.com/smart-digital-reality/three-key-findings-from-the-digital-twin-trends-report found nearly two-thirds 62% get immense value from digital twins. The bottleneck has shifted from whether to deploy them to how to make them trustworthy enough for autonomy. That shift matters because the moment a twin becomes a place where software makes recommendations, tests strategies, or guides action, the technical center of gravity changes. Visualization still matters. Simulation still matters. The harder problem sits underneath. A serious digital twin has to hold together current state, historical state, relationships, constraints, external inputs, and, increasingly, the context and reasoning that underpins all this. For developers and architects, that makes the data backbone far more consequential than it has ever been. AI agents quickly sharpen that problem. A human operator can tolerate a degree of architectural mess. While comparing dashboards, we can skim logs, open a maintenance note, all the while remembering that one source tends to lag — and mentally stitch the rest together. An AI agent, operating within a twin, is far less forgiving. If it is trying to understand why a cooling loop is underperforming, or whether a maintenance intervention should be delayed until after a production peak, the layers of data needed to make that decision are huge. Live sensor data, equipment dependencies, work-order history, and a lot more — all in the same decision path. Some of that information is relational. Some is document-shaped. Some is graph-shaped. Some is temporal. Some may arrive as embeddings or unstructured operator notes. If that context is fragmented across too many stores and too many APIs, the application layer ends up rebuilding meaning every time the agent asks a serious question. That is the point where digital twins gain a memory problem as well as a modeling one. A useful agent inside a digital twin is not a single prompt-response interaction. It is a long-running, multi-faceted process. It observes the twin over time — receives instructions from operators, forms working assumptions, sees the consequences of previous actions — and is asked related questions again hours, days, or weeks later. At that point, “what does the agent remember?” stops being an implementation detail and becomes part of the architecture. There are several ways teams can handle that today. The quickest is to keep stuffing more context into the prompt window. That works for demos but fails under sustained operational use. Context windows fill up and, with that, provenance gets muddy. Where stale facts linger, older reasoning quietly drops off the edge. A second option is to bolt on a separate memory layer, perhaps with a vector database https://www.infoworld.com/article/2335281/vector-databases-in-llms-and-search.html for retrieval https://www.infoworld.com/article/2335814/what-is-retrieval-augmented-generation-more-accurate-and-reliable-llms.html , a key-value store for session state, and maybe a graph store https://www.infoworld.com/article/2265778/what-is-a-graph-database-a-better-way-to-store-connected-data.html for learned entities and relationships. That can work too, but it recreates the same polyglot persistence problem many twin architectures already struggle with. The twin lives in one place, the agent’s memory in another, the document layer somewhere else, and there is no single moment of agreement across them. The more durable approach is to treat agent memory as first-class twin data. In practice, that means the memory layer follows many of the same rules as the twin itself. Facts need sources. Beliefs need history. Conflicts need to be explicit. Uncertainty needs to be represented rather than smoothed over. The architecture not only has to accurately report where a fact came from and when it was learned, it also must understand when the fact was true in the world, what superseded it, and what earlier decisions depended on it. That last point deserves more attention than it usually gets. In an operational setting, overwrite is a dangerous verb. If an agent learns something new that contradicts an earlier assumption, the old belief should rarely disappear without a trace. It should be superseded. The system should retain the earlier fact, record the source of the newer one, and preserve the chain between them. That matters for debugging, governance, and trust. When an operator asks why the system changed its recommendation on turbine maintenance, or why a supplier-risk score moved, the answer should come from queryable data, not from forensic reconstruction across log files. As such, durable agent memory with provenance increasingly becomes an intermediate decision layer where AI can be tested before touching live infrastructure, and that layer is what makes that governance defensible. Time becomes much more nuanced here, too. Most digital systems are built around a linear idea of time — in effect, when a record was written. Twins operating with AI agents often need at least three distinct views. There is the state of the system at a given instant, then there is the point at which the agent came to believe something. Lastly, there is the time period in the real world for which that belief was actually valid. Those clocks do not always align. An engineering document ingested today may describe a condition that was held last month. A shift handover may create a new operational belief before that belief is confirmed. A later inspection may revise it again. Developers building trustworthy twins will need architectures that can query those timelines separately rather than collapsing them into one hazy notion of “history.” This is true provenance. In a twin that hosts AI agents, provenance cannot be an afterthought. It is not enough to know that a recommendation was generated. Teams need to know which facts informed it, where those facts came from, and how much confidence the system attached to each. When authoritative sources and experiential sources disagree, the right outcome is often an explicit uncertainty record, not a quiet overwrite. That may feel slower than simply picking a winner. In production systems, it is usually safer. This is also why traces matter. Enterprises are comfortable with audit trails for transactions. They are much less prepared for audit trails of reasoning. If an agent retrieves five documents, traverses a set of dependencies, weighs a prior intervention, and then recommends delaying a shutdown by six hours, the ideal outcome is a trace that links that recommendation to the facts and relationships it touched. In a strong twin architecture, that becomes a graph walk. In a weak one, it becomes a painful trawl across application logs, retrieval logs, model outputs, and half-correlated identifiers. Scale makes the challenge even harder. Many digital twins are already moving beyond single assets. A machine connects to a line, the line connects to a plant, the plant connects to a supply chain, a workforce model, a financial exposure model, and an energy model. The industry likes to call this a system-of-systems view. It is a useful phrase because it captures how quickly context spills beyond one neat boundary. The same supplier may matter at site level and group level. The same maintenance event may matter to production planning and insurance modelling. The same agent may operate locally while drawing on organization-wide knowledge. Memory in that environment cannot simply be shared everywhere by default. It needs scopes, policies, and a clear sense of what should stay local, what can be promoted, and what must remain partitioned. All of this has implications for the underlying data layer. Digital twin stacks already tend to accumulate specialized systems for distinct tasks — one for transactions, one for graph modeling, another for documents, telemetry, vector search — with several layers of integration and synchronization on top. That approach can be justified in narrow cases. At larger scale it becomes fragile. Every boundary introduces latency, governance overhead, and one more opportunity for the twin’s operational picture to drift. Once agent memory is added as yet another side system, the seams multiply again. That is why unified, multi-model, data backbones are getting a second look. The real attraction is not fashion; it is a reduction of failure surfaces. Keeping graph relationships, documents, vectors, temporal state, and structured records closer together reduces the amount of meaning the application layer has to reconstruct on the fly. It also makes it easier to keep the twin’s state and the agent’s state under the same transactional and governance policy. Newer database technologies are rethinking architectural conventions, allowing a twin and an agent reasoning over that twin to share the same substrate, the same query language, and the same transaction boundary. Even readers who never adopt that stack should take the design principle seriously, because it speaks directly to the failure modes many teams are heading towards. Digital twins are often discussed as if the hard part were building the model. Increasingly, the hard part is building the memory around the model. As AI agents move deeper into operational environments, the question is no longer limited to what the system can see right now. It extends to what it knew, when it knew it, where that knowledge came from, which assumptions changed, and whether a human can inspect the reasoning path after the fact. That is a much higher bar than the dashboard era ever demanded. It is also the bar that next-generation digital twin architectures will have to clear. The winners are unlikely to be the systems that produce the prettiest mirror of the physical world. They will be the systems that preserve context well enough for humans and machines to act with confidence when the stakes rise. — New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug dineley@foundryco.com .