Agentic Digital Twins: AI-Driven Twins in 2026

A classical digital twin is a very good mirror. It reflects a pump, a production line or a wind farm in near real time, and it waits for a person to look into it and decide. Agentic digital twins change the contract: a reasoning agent sits on top of the replica, notices a deviation, plans a response, tests that response against the twin, and, inside hard limits, writes the change back to the physical asset. The mirror starts to act.

That is a bigger claim than it sounds, and in October 2026 it is half true. Some of it is shipping in narrow, well-bounded processes. Much of it is still a conference slide, and the gap is almost entirely about one engineering question: what stands between a language model’s proposal and a valve actuator? Teams that answer it with a better prompt tend to fail. Teams that answer it with architecture tend to ship.

This article gives you a working definition, a reference architecture, the tool-use plumbing (MCP and OPC UA), a guardrail design you can audit, a maturity ladder to climb without skipping rungs, and an honest list of failure modes.

What this covers: agentic versus classical twins, the observe-simulate-decide-act loop, the four-block reference architecture, tool use through MCP and OPC UA, simulation-in-the-loop validation, autonomy tiers and human-in-the-loop design, governance and audit, failure modes, and a rollout checklist.

Context and Background

The word “twin” has been stretched for a decade, so start with a precise baseline. ISO 23247, the multi-part standard for a digital twin framework for manufacturing, describes an observable manufacturing element, a digital representation of it, and a data flow that keeps the two synchronized. Nothing in that framing requires intelligence. A synchronized 3D model with a trend chart qualifies. Maturity, in the sense we cover in our digital twin maturity model and fidelity levels guide, mostly measures how faithful the model is and how tightly it is coupled to the asset, not how much it decides.

Three trends converged to make “agentic” a live term this year. First, the data substrate matured. Industrial teams spent 2022 to 2025 building unified namespaces, semantic information models and historian pipelines, a story we walk through in OPC UA historian to digital twin ingestion. An agent is only as useful as the context it can read, and a contextualized twin is the best context source a plant has.

Second, tool-calling language models became dependable enough to chain multi-step work. The Model Context Protocol (MCP) turned “give the model a tool” into a standard interface. The 2026-07-28 revision made the protocol stateless and moved long-running work into an official tasks extension, changes we cover in the MCP 2026-07-28 migration guide. For a twin, that means an agent can call “read tag history”, “run a what-if” and “request a setpoint change” as discrete, typed, loggable operations.

Third, the standards bodies noticed. On 20 April 2026 the OPC Foundation announced that it plans to convert all of its 430-plus Companion Specifications into formats suited to retrieval-augmented generation, MCP and AI-assisted engineering, building on a prototype repository that already exposes MCP and REST query interfaces, according to the OPC Foundation press release. Read that carefully: it is a plan and a prototype for making specifications machine-readable, not a certified agent-control profile. It does, however, signal where the semantic layer for agents will be grounded.

On the analyst side, the forecasts point the same way but at a distance. Gartner’s manufacturing predictions describe closed-loop digital twins and semi-autonomous agents reshaping manufacturing toward 2030 (a forecast, not a deployment census). Vendors from Siemens to AVEVA to NVIDIA now market “agentic” or “AI agent” capabilities around twins. We label those as vendor claims throughout, because a press release tells you what a company intends to sell, not what a plant has validated.

The practical upshot: the ingredients are real, the integration pattern is converging, and the safety engineering is where the work is.

What “Agentic” Actually Means for a Twin

An agentic digital twin is a digital twin in which an AI agent can perceive state from the twin, reason about goals, call tools including the twin’s own simulator, and propose or execute actions on the physical asset through a governed interface. Two properties separate it from a predictive twin: goal-directed multi-step planning, and a write path back to the asset.

Be wary of the definitional creep. A twin with an LLM chat panel that summarizes alarms is a copilot, not an agent. A twin whose anomaly model pages an engineer is predictive. The test is simple: does the system choose among actions, test them, and then act or hand off, across more than one step, without a human composing each step? If yes, it is agentic. If a human composes the steps, it is assisted.

Classical, predictive and agentic twins compared

Dimension	Classical twin	Predictive twin	Agentic twin
Core function	Mirror and visualize	Forecast and alert	Plan, test, act or escalate
Decision owner	Human	Human, informed by model	Agent within policy, human above threshold
Write path to asset	None	None	Governed control API
Simulation role	Offline design checks	Forecast engine	Online safety gate for each action
Typical interface	Dashboard	Alerts and reports	Tool calls (MCP, OPC UA methods)
Main failure mode	Stale model	False alarms	Wrong action executed
Verification burden	Moderate	Moderate	High, model is in the control path

The last row is the one that matters. Once the twin is in the control path rather than only the reporting path, its accuracy stops being a quality metric and becomes a safety property. That is why our coverage of digital twin verification, validation and uncertainty quantification is a prerequisite reading for anyone building toward the right-hand column.

The original thesis: the twin is the referee, not the advisor

Most writing on this topic frames the twin as the agent’s data source and the agent as the intelligence. We think that is backwards for anything touching a physical process. Language models are strong at proposing plausible actions and weak at predicting physical consequences. Physics-based or data-driven twins are the opposite: poor at open-ended proposing, strong at consequence prediction within their validated envelope.

So the defensible role split is: the agent proposes, the twin judges. The agent should never grade its own plan. Every design decision later in this article, from the simulation gate to the fidelity check, follows from that inversion.

Reference Architecture: Agent, Twin, Tools, Governance

The credible reference architecture has four blocks: a twin core that holds live state and a simulator, an agent orchestrator that plans, a tool layer that exposes typed operations, and a governance layer that decides whether a proposed action may touch the asset. The agent reaches the physical world only through governance.

Figure 1: Reference architecture for agentic digital twins. The agent reads and simulates through the tool layer, and every write passes the governance gate.

Read the figure from the asset upward. Telemetry flows from PLCs, sensors and drives through an edge gateway (OPC UA or MQTT) into a contextualized data layer, which gives raw tags meaning: this is the discharge pressure of pump P-101 in unit 2, with these engineering units and these limits. The twin core consumes that context and maintains state. The orchestrator reasons over the twin through tools. The only arrow from agent to asset passes through the governance gate and a write allow-list. Every edge from the gate also lands in an audit log.

The twin core: state plus a runnable model

The twin core needs two things that are easy to conflate. The first is a state model: what the asset looks like right now, including derived quantities such as remaining useful life estimates or hydraulic balances. The second is a simulator that can be rolled forward from that state under a hypothetical action. A dashboard twin has the first and not the second, which makes it unusable as a referee.

The simulator can take many forms. First-principles models (Modelica, Simulink, FMI-based co-simulation, discrete-event models) are interpretable and extrapolate physically but are slow to calibrate. Data-driven surrogates and reduced-order models are fast enough for dozens of what-ifs per second but only valid inside the data they were trained on. We cover that trade in reduced order and surrogate models for real-time twins. Agentic use favours a hybrid: a fast surrogate for broad search, a slower high-fidelity model to confirm the single chosen action.

The agent orchestrator: reasoning without reach

The orchestrator hosts the LLM planner, short-term memory for the current incident, and long-term memory of past incidents and their outcomes. It may be one agent or several specialists (a diagnosis agent, a scheduling agent, an energy agent) coordinated by a supervisor. Its toolbox is deliberately narrow and typed.

The design rule we recommend: the orchestrator holds no credentials to the control network. It holds credentials to the tool layer, and the tool layer holds the narrower, audited path to the control APIs. A compromised or confused planner therefore inherits the tool layer’s allow-list, not the plant’s.

The tool layer: MCP servers over the twin and the plant

The tool layer is where MCP earns its place. Each capability becomes an MCP tool with a JSON Schema for inputs and outputs: get_tag_history, get_asset_context, run_what_if, propose_setpoint_change, open_work_order. Read-only tools and write-proposing tools live in separate servers with separate credentials, so that granting an agent diagnosis access does not silently grant control access.

Two details matter in practice. First, tool descriptions are an attack surface: the model reads them, so a tampered description can steer behaviour. Pin and review tool manifests like code. Second, the long-running nature of industrial work (a what-if that takes ninety seconds, an approval that takes ten minutes) fits the tasks extension in the current MCP specification better than a blocking call. We unpack that in MCP tasks versus streaming versus webhooks for long-running tools.

The governance layer: policy, approval and audit

Governance is not one component but a chain of checks, covered in depth below. For architecture purposes, note its position: it is a separate process, owned by the controls or OT security team rather than the AI team, with its own deployment cycle and the authority to say no. If the same team writes the planner and the policy that restrains it, the restraint will erode under delivery pressure.

The Agent Loop in Practice: Observe, Simulate, Decide, Act

The agent loop has four phases. Observe: ingest an event with context. Simulate: roll candidate actions forward in the twin. Decide: choose, reject or escalate based on predicted outcomes and policy. Act: execute a bounded write, then observe the result to close the loop and update memory.

Figure 2: One pass of the agent loop. Simulation precedes every write, and a human approval branch sits inside the gate for high-risk actions.

The loop is deliberately boring. Boring is the goal: each step is a typed call whose input and output can be logged and replayed.

Observe: from alarm to situation

A raw alarm (“PT-204 high”) is a poor prompt. The observe phase enriches it before the model sees it: asset hierarchy, recent trends, active work orders, operating mode, related alarms in the last ten minutes, and the relevant limits. The enrichment is deterministic code, not a model call, so it is cheap and testable. This is where the semantic information model pays off. If tag names are cryptic and units are implicit, the agent will reason about numbers without meaning, and it will do so fluently.

Event selection matters too. Do not wake the agent on every sample. Trigger on anomaly detector output, on a threshold crossing, on a schedule for optimization tasks, or on an operator request. A twin streaming at one hertz across ten thousand tags cannot afford a model call per tick, and should not want one.

Simulate: candidate actions meet the referee

The agent generates a small set of candidate actions, typically two to five, each with a stated hypothesis. A cooling loop trending hot might yield: raise the pump speed setpoint by a bounded step, switch to the standby pump, or reduce upstream throughput. The agent calls run_what_if for each against the twin and receives predicted trajectories with uncertainty.

Two requirements make this phase trustworthy. The simulation horizon must exceed the process dynamics, otherwise the twin will report that things look fine because it did not run long enough to see the overshoot. And the result must carry an uncertainty or validity flag: is the proposed operating point inside the region where the model was calibrated? A surrogate asked about an operating point far from its training data should say so, and the gate should treat “out of envelope” as a rejection reason.

Research supports this pattern at least in prototype form. Published work on LLM agents paired with a process-plant digital twin reports using the twin to validate corrective control actions before they reach the plant, and related work frames the twin as an online simulator in a closed-loop architecture with an LLM agent (see the arXiv preprints 2505.02076 and 2507.07115). Treat these as evidence that the pattern is technically viable on benchmark processes, not as proof of plant-scale readiness; the preprints test specific setups.

Decide: choose, reject or escalate

The decision step has three outcomes, not two. Choose an action and pass it to the gate; reject all candidates and recommend a human investigation; or escalate with a ranked shortlist. Systems that only know “act” and “alert” force the model to bluff when no candidate is good. Giving the agent an explicit, rewarded “I do not know, here is what I checked” path is among the cheapest reliability improvements available.

The agent should output a structured decision record, not free text: the chosen action, the evidence cited (tool call identifiers), the predicted effect, the confidence, and the rollback plan. The governance layer consumes that record. A plan without a rollback plan does not pass.

Act: bounded writes and closing the loop

Execution is a narrow write: a setpoint within an allowed range, a mode change from an allow-list, a work order created, a schedule adjusted. After the write, the loop watches the telemetry. If the observed effect departs from the simulated prediction by more than a tolerance, the system rolls back or escalates, and the discrepancy is recorded as a twin-fidelity signal. That feedback is also how long-term memory gets useful: the agent learns which of its predictions the plant confirmed.

Tool Use Through MCP and OPC UA

Agents reach the plant through two complementary layers. OPC UA supplies the semantic model and the authenticated, authorized method and variable access on the OT side. MCP supplies a model-friendly tool interface on the AI side. A thin, audited adapter translates between them, and policy lives in the adapter, not in the prompt.

OPC UA is a strong foundation because it already encodes what an agent needs and a raw Modbus register does not: typed variables, engineering units, ranges, method signatures, role-based access and signed, encrypted sessions. The Companion Specifications give domain vocabularies for machinery, robotics and more. The OPC Foundation’s April 2026 announcement about making those specifications retrievable by AI is aimed squarely at grounding agents in this vocabulary, though, again, as a plan and a prototype. For hardening the underlying channel, see our OPC UA security, certificates and GDS hardening guide.

A minimal MCP tool surface

A sensible starting tool surface for a pump-station twin looks like this. The design principle: reads are cheap and broad, writes are rare and narrow.

# Sketch of an MCP server exposing a twin to an agent (FastMCP-style).
# Read tools are unrestricted within the agent's scope; the write tool only
# creates a PROPOSAL that the governance service evaluates.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("pump-station-twin")

@mcp.tool()
def get_asset_context(asset_id: str) -> dict:
    """Return hierarchy, operating mode, limits and open work orders."""
    return twin.context(asset_id)

@mcp.tool()
def run_what_if(asset_id: str, tag: str, new_value: float,
                horizon_s: int = 600) -> dict:
    """Simulate a setpoint change. Returns trajectory, bounds, validity flag."""
    return twin.simulate(asset_id, {tag: new_value}, horizon_s)

@mcp.tool()
def propose_setpoint_change(asset_id: str, tag: str, new_value: float,
                            rationale: str, sim_run_id: str) -> dict:
    """Create a proposal. Does NOT write to the plant."""
    return governance.submit(asset_id, tag, new_value, rationale, sim_run_id)

Notice that propose_setpoint_change requires a sim_run_id. The governance service rejects any proposal whose simulation run does not exist, is stale, or does not match the proposed value. That one argument turns “the agent should simulate first” from a prompt instruction into a mechanical requirement.

Why the adapter, not the model, enforces limits

Never put limits only in the system prompt. A prompt is a request; an allow-list is a wall. The adapter should enforce engineering limits (minimum, maximum, rate of change), mode interlocks (no changes while the unit is in startup or in a safety trip state), and rate limits (no more than N writes per hour per asset). OPC UA role-based permissions on the target nodes add a second wall: the service account used for writes can only write the nodes on the allow-list.

Remember that the safety instrumented system and the basic process control system retain their own authority. An agentic twin sits in the supervisory layer. Nothing in this architecture lets it override a safety function, and IEC 61511 and IEC 62443 thinking applies: independent protection layers must not depend on the agent being right. The same logic applies to AI-written control logic, which we treat in LLM PLC code generation and safety verification.

Security of the agent surface

Agent tooling adds new attack paths to an OT environment. Prompt injection can arrive through data the agent reads: a maintenance note, a vendor PDF, a free-text alarm comment. If a tool result can contain instructions the model might follow, the model must be unable to turn those instructions into writes without passing the gate. Treat all tool outputs as untrusted data and keep write authority outside the model.

Authentication deserves care too. The 2026-07-28 MCP revision tightens authorization details, including validation of the issuer parameter defined in RFC 9207 and a deprecation of dynamic client registration in favour of client ID metadata documents, per the specification changelog. Whatever the protocol does, the OT-side rule stands: agent identities are distinct, least-privilege, individually revocable service identities with full logging, not a shared engineer login.

Simulation-in-the-Loop Validation and Autonomy Tiers

Simulation-in-the-loop means no action reaches the asset unless a validated twin predicts a safe outcome. How strict that gate is should depend on the autonomy tier. The mistake is to apply one policy to everything: too loose for a boiler feed pump, too tight for a lighting schedule.

Figure 3: An autonomy ladder for agentic digital twins. Each rung demands stronger evidence from the gate, and L5 is not a 2026 product.

The ladder, rung by rung

At L0 the twin monitors. At L1 it predicts and alerts. At L2 an agent diagnoses and recommends, and a human acts: the value is faster diagnosis and fewer missed patterns. At L3 the agent prepares and submits changes that a human approves: this is supervised action. At L4 the agent writes automatically inside a narrow, pre-approved envelope for a well-understood process. L5 would be open-ended autonomy over a whole facility, which nobody should claim as a shipping product in 2026.

Most credible production deployments we are aware of in public material sit at L2 and L3, with L4 limited to narrow loops such as energy optimization, scheduling, or comfort control where the downside is bounded. We cannot quantify the share precisely because no neutral census exists, so treat any vendor statistic on “autonomous twins in production” with caution.

The maturity point echoes our digital twin maturity model: you cannot skip fidelity. An L4 claim on top of an L1 quality model is not ambition, it is a hazard.

Setting risk tiers per action, not per system

Autonomy is best decided per action class. Define a catalogue where each action carries a consequence class. Creating a work order or changing a report schedule is low consequence and can auto-execute at L4. Adjusting a setpoint inside a 5 percent band on a non-critical loop might auto-execute after simulation. Starting or stopping rotating equipment, changing a recipe parameter that affects product quality, or anything near a safety limit requires approval. Anything that touches a safety function is simply out of scope for the agent.

Write the catalogue down with the controls engineers and the safety lead, version it, and load it into the governance service. The point of writing it down is that nobody, including the model, can negotiate it at 3 a.m.

Fidelity as a runtime input

A subtle but vital idea: the gate should treat twin fidelity as a live signal, not a one-time acceptance test. If the twin’s one-step prediction error against telemetry has drifted beyond a tolerance, if a sensor feeding it has failed, or if the operating regime is outside the calibrated envelope, the gate demotes the agent automatically, from L4 to L3 or from L3 to L2. State estimation techniques, such as the Kalman and particle filters discussed in our piece on digital twin state estimation, provide exactly the innovation and residual statistics a gate can monitor.

This demotion is the difference between a twin that is trusted and a twin that is trusted blindly. When the referee is unwell, the match pauses.

Guardrails, Human-in-the-Loop and Governance

A defensible governance layer is a short chain of independent checks, each cheap to audit: the safety envelope, twin fidelity, the simulation outcome, the risk tier, optional human approval, and a post-write monitor with automatic rollback. Every branch, including rejections, ends in an audit log.

Figure 4: The governance gate as a decision flow. Failing any check rejects or escalates, and all paths end in the audit log.

The checks, in order

The order is by cost and by severity. The envelope check is a pure function over limits and is evaluated first, because a proposal outside hard limits should never consume simulation time. The fidelity check follows, because a simulation from an unreliable twin is worthless. The simulation check confirms predicted trajectories stay inside bounds across the horizon, with the uncertainty band, not just the mean. The risk tier decides whether a human must approve. After execution, a monitor compares reality to prediction and rolls back on breach.

Human in the loop that stays meaningful

A human approval step fails in a predictable way: by the fiftieth request it is a reflex. Design against that. Present the proposed change, the evidence, the predicted effect with uncertainty, and the alternatives that were rejected and why, in a form that takes under a minute to assess. Make approval slightly costly for high-risk actions by requiring a reason code. Sample low-risk auto-approved actions for retrospective review so humans stay calibrated on what the agent actually does.

Also decide what happens when no human responds. Default to the safe state, which usually means no action and an escalation, never an auto-approve on timeout.

Audit, identity and evidence

Every decision record should be reconstructible: which model version, which prompt and tool manifest versions, which tool calls with which arguments and results, which policy version, who approved, and what the plant did afterwards. The logging patterns for agent traces are covered in OpenTelemetry GenAI semantic conventions for agent observability, and the identity and audit lessons from a recent public-sector incident are in AI agent audit logging and identity lessons.

Regulatory framing helps. The NIST AI Risk Management Framework organizes the work into govern, map, measure and manage functions, and the EU AI Act places obligations on high-risk systems, including AI used as safety components in certain regulated products. Whether a given agentic twin falls under those obligations is a legal determination for your jurisdiction and use case; the engineering takeaway is that traceability, human oversight and robustness testing are becoming expected rather than optional.

Evaluating the agent before it earns write access

Treat agent evaluation like commissioning. Build a replay harness that feeds historical incidents, including near misses and sensor faults, into the agent against the twin, and score decisions against what experienced operators chose. Measure not just accuracy but calibration: does the agent escalate when it should? Our agent evaluation harness architecture covers trajectory-level evaluation. Run the agent in shadow mode, producing recommendations with no write path, for weeks, and compare with what the operators actually did. Promotion from L2 to L3 should require a written result, not a vibe.

Reading Vendor Claims and Where This Works Today

Vendor material in 2026 uses “agentic” liberally. A useful habit is to translate every claim into the ladder and the architecture: which rung, which tools, which gate, and whose evidence. Our own coverage of Siemens Digital Twin Composer with OpenUSD and Omniverse and the AVEVA and Snowflake IT/OT data architecture applies that lens to specific announcements, and we label them as vendor positioning there as well.

A claim-to-evidence checklist

Ask five questions of any agentic twin pitch. Which autonomy level is deployed today, and which is roadmap? What is the write path, and who owns the allow-list? Is simulation a mandatory gate or an optional tool? How is twin fidelity monitored at runtime? Where is the audit trail, and can the customer export it? A vendor who can answer all five with documentation has a product. A vendor who answers with a demo video has a prototype.

What is working with supervision

Predictive maintenance remains the strongest case: an agent watches condition indicators, correlates with maintenance history, drafts a diagnosis and opens a work order. The consequence of error is a wasted inspection, which is bounded. Energy and comfort optimization in buildings and utilities is another good fit, because the process is slow, the actuators are forgiving and there is a clear objective function. Scheduling and dispatch, such as routing work among assets or resequencing a production plan, is a third, since the agent’s output is a plan that existing systems validate.

Engineering assistance is a quiet fourth. Agents that answer “what does this alarm mean for this asset class” using a semantic model and the Companion Specifications save commissioning and troubleshooting time without any write path at all. That is L2 done well, and it is where most teams should start.

What remains aspirational

Unsupervised, plant-wide closed-loop control belongs on the roadmap, not the purchase order. General physical autonomy is limited by the reliability of the model itself: the International AI Safety Report 2026 documents that general-purpose AI systems still produce false statements and remain unreliable at some multi-step real-world tasks, which is the core reason physical consequences need a separate checker. An agent hallucinating inside a closed loop does not emit a wrong sentence; it emits a wrong action.

Regulated, high-consequence sectors such as pharmaceuticals, nuclear and aviation add validation burdens that make a staged approach mandatory. Public statements from large manufacturers about moving toward AI-agent-driven development and operations are directional intent, and should be read as such.

Trade-offs, Gotchas, and What Goes Wrong

The failure modes of an agentic twin are physical, and most are not model failures. They are integration, calibration and human-factors failures that a capable model amplifies.

A confident wrong action. The headline risk. A planner invents a plausible corrective step that the twin’s envelope does not cover, and a loose gate lets it through. Mitigation: out-of-envelope is a rejection, simulation is mandatory, and the write path is an allow-list.

Verification debt. Twins are built for dashboards and quietly drift. A calibration that was fine at commissioning stops matching after a retrofit, a fouled exchanger or a sensor replacement. If nobody owns fidelity monitoring, the referee is validating against a fantasy. Budget for continuous revalidation as a standing operating cost.

Simulation-reality gap exploited by the optimizer. An agent that searches for the best predicted outcome will find the model’s blind spots. This is optimizer’s curse in physical form: the action that looks best in the twin is disproportionately likely to be one where the twin is optimistic. Use uncertainty-aware scoring, prefer small steps, and verify with the high-fidelity model before execution.

Automation complacency. After weeks of correct proposals, approvers stop reading. Counter with calibrated sampling, reason codes and occasional drills where a deliberately flawed proposal is injected in a test environment.

Multi-agent conflicts. Two specialists optimizing locally can oscillate globally: an energy agent lowers a setpoint while a quality agent raises it. Give them a shared arbitration layer, a single writer per asset, and rate limits so oscillation cannot persist.

Prompt injection through plant data. Free-text fields in historians, work orders or imported documents are attacker-reachable in some environments. Keep write authority outside the model and strip or flag instruction-like content in tool results.

Latency and availability mismatch. Model calls take seconds and sometimes fail. Plant control cannot wait. The agent must live in the supervisory layer, with regulatory control continuing unaffected if the agent, the network or the model provider is unavailable. Design for graceful degradation to L2 and to manual operation, and test it.

Cost and sprawl. Waking a large model on every event is expensive and noisy. Pre-filter with deterministic rules and cheap detectors, cache context, and reserve the planner for situations where multi-step reasoning is the bottleneck.

Skills and ownership gaps. Controls engineers, data scientists and platform engineers each own part of the stack, and the agent sits across all three. Name an accountable owner for the gate, one for the twin and one for the agent, and rehearse an incident with all three in the room.

Practical Recommendations

Start at the bottom and climb. Teams that begin with the semantic data layer and an advisory agent usually ship something useful within a quarter; teams that start with a closed-loop demo usually spend that quarter arguing about safety cases.

Concretely, treat the first release as an L2 assistant on one asset class, with read-only MCP tools and a shadow log of every recommendation. Use the shadow period to measure agreement with operators and to harvest failure cases for your replay harness. Only then add the proposal tool and the governance service for L3, and only for action classes with a documented consequence level. Move to L4 per action class, never per plant.

Keep the organisational boundary clean. The OT security or controls group should own the governance service and the allow-list, with veto power over the AI team. Align with IEC 62443 zones and conduits so that the agent’s tool layer sits in a defined zone with explicit conduits to the control network.

Finally, instrument everything from day one. If you cannot replay a decision, you cannot defend it, improve it or insure it.

Rollout checklist

Contextualize data first: asset hierarchy, units, limits and operating modes in a semantic model.
Build or validate a twin simulator with a documented validity envelope and an uncertainty output.
Expose read tools and what-if tools through MCP, with pinned and reviewed manifests.
Separate read and write credentials; the agent holds no control-network credentials.
Require a simulation run identifier on every proposal, and enforce it mechanically.
Maintain a versioned action catalogue with consequence classes and owners.
Monitor twin fidelity at runtime and demote autonomy automatically on drift.
Default to the safe state on approval timeout; never auto-approve.
Log every decision with model, prompt, tool and policy versions, and plant response.
Run shadow mode and replay evaluation before each promotion, and write the result down.
Rehearse degraded modes: model outage, twin outage, network partition.

Frequently Asked Questions

What is an agentic digital twin?

An agentic digital twin is a digital twin with an AI agent layered on top that can observe the twin’s state, plan multi-step responses, test candidate actions in the twin’s simulator, and then act on the physical asset through a governed interface or hand the decision to a human. The defining features are goal-directed planning and a write path back to the asset, not a chat interface.

How is an agentic twin different from a predictive twin?

A predictive twin forecasts states and raises alerts, and a human decides and acts. An agentic twin adds a planner, a simulation-based safety gate and a controlled action path, so it can recommend or execute corrective steps itself. On an autonomy ladder, predictive twins sit at L1, advisory agents at L2, supervised action at L3 and bounded autonomous action at L4.

Where do MCP and OPC UA fit in an agentic twin?

OPC UA supplies the semantic information model and secured access to variables and methods on the OT side. MCP supplies a typed tool interface that language-model agents can call. An audited adapter between them enforces limits, so the model calls tools like run_what_if or propose_setpoint_change while only the governance layer can write to OPC UA nodes. The OPC Foundation announced in April 2026 that it plans to make Companion Specifications available for MCP and retrieval-augmented generation.

Are agentic digital twins safe for physical operations?

They can be safe within a scoped design, but safety comes from architecture rather than trust in the model. Safe designs keep the agent in the supervisory layer, require a simulation run before every write, enforce engineering limits in an allow-list outside the model, require human approval above a risk threshold, monitor twin fidelity at runtime and keep independent safety systems untouched. Safety functions should never depend on the agent.

Is fully autonomous closed-loop control available in 2026?

Only for narrow, well-bounded processes where the downside of error is limited, such as energy optimization or scheduling. Whole-facility, unsupervised closed-loop control is a roadmap item, and analyst forecasts such as Gartner’s point toward 2030 rather than today. Most production agentic twins operate at advisory or supervised levels, and any vendor claiming more should show the write path, the gate and the audit evidence.

What should a team build first?

Build the contextualized data layer and an advisory agent with read-only tools on a single asset class, then run it in shadow mode against operator decisions. That yields value quickly, exposes data and model gaps safely, and produces the replay set you need to justify promoting the agent to supervised action. Add write capability only after the governance service, action catalogue and fidelity monitoring exist.