Pieter Van Schalkwyk

CEO at XMPRO

True agency requires causal understanding. Not just knowing what happened, but why it happened and what could happen next. This is what separates genuine AI agents from workflows with chatbot interfaces.

I've written before about Arthur Kordon's axioms for industrial AI, which Michael Carroll highlighted in his work on "agent-washing": Can it learn and evolve? Can it predict with causal understanding? Can it reason autonomously? Most marketed "agents" fail all three tests because they lack the foundation that makes causal reasoning possible.

That foundation is operational memory. The accumulated decision traces that capture not just what actions were taken, but what reasoning justified them.

Your historians capture what happened. Your CMMS captures what work was done. Nothing captures why your experienced operators made the calls they made. That reasoning walks out the door every time someone retires.

Jamin Ball wrote in Clouded Judgement that "agents are raising the standards for what a good system of record looks like." Agents need explicit rules, conflict resolution baked into the data model, and clear precedence for which definition wins in which context.

Jaya Gupta and Ashu Garg at Foundation Capital pushed back in their piece on context graphs. Ball's framing assumes the data agents need already lives somewhere. That's half the picture.

The other half is the missing layer that actually runs operations: decision traces.

What Systems of Record Don't Capture

Ball uses the ARR example well. Ask sales, finance, accounting, and legal for "what is our ARR" and you get four different answers. Agents need to know which definition applies for which purpose.

But even if you solve the semantic problem (which ARR definition to use), you still don't have the reasoning that connects data to action.

Gupta and Garg identify what's actually missing:

• Exception logic that lives in people's heads. "We always give healthcare companies extra flexibility because their procurement cycles are brutal." That's not in the CRM. It's tribal knowledge passed through onboarding and side conversations.
• Precedent from past decisions. "We structured a similar deal for Company X last quarter. We should be consistent." No system links those decisions or records why the structure was chosen.
• Cross-system synthesis. The reliability engineer checks vibration trends in the historian, sees two recent work orders in the CMMS, reads a shift log noting unusual noise, and decides to escalate. That synthesis happens in their head. The work order just says "inspection requested."
• Approval chains that happen outside systems. An operations manager approves a temporary setpoint change on a phone call. The historian shows the new value. It doesn't show who approved the deviation or why.

This is the decision trace problem. The data isn't dirty or siloed. The reasoning connecting data to action was never treated as data in the first place.

Rules vs. Decision Traces

Gupta and Garg make a distinction that matters enormously for industrial operations:

Rules tell an agent what should happen in general. "Escalate to maintenance when vibration exceeds 7.1 mm/s."

Decision traces capture what happened in this specific case. "We escalated at 6.8 mm/s because the bearing was replaced three months ago under warranty, the similar unit in Train B failed at 6.9 last quarter, and the operations supervisor approved early intervention based on production schedule."

Agents don't just need rules. They need access to the decision traces showing how rules were applied in the past, where exceptions were granted, how conflicts were resolved, and which precedents actually govern reality.

For industrial operations, this is where decades of tacit knowledge live. The experienced operator knows that "when this pump sounds like that, we have about six hours before it fails, regardless of what the vibration sensors say." The reliability engineer remembers that "we tried that fix on Unit 3 in 2019 and it made things worse." The maintenance planner knows which contractors actually deliver quality work versus which ones just check boxes.

This knowledge has never been systematically captured. It lives in people's heads, in hallway conversations, in the judgment calls that happen between what the system recommends and what actually gets done.

The Context Graph for Industrial Operations

Gupta and Garg introduce the concept of a "context graph": a living record of decision traces stitched across entities and time so precedent becomes searchable.

For enterprise software, this captures how discount approvals, exception routing, and escalation decisions actually happened.

For industrial operations, the context graph captures something more valuable: the causal reasoning that keeps physical systems running safely.

Consider what a properly instrumented decision trace would capture for a maintenance decision:

• What triggered the evaluation. Not just "high vibration alert" but the specific pattern, the rate of change, the correlation with other variables.
• What context was gathered. Equipment history, similar failures on related assets, current production schedule, parts availability, contractor capacity, weather forecast for outdoor work.
• What rules were evaluated. OEM recommendations, internal standards, regulatory requirements, and where they conflicted.
• What exceptions were considered. Why the standard response didn't apply. What precedent supported the deviation.
• Who approved and why. The human judgment that connected all these inputs to a specific action.
• What actually happened. Did the intervention work? Was the diagnosis correct? What would we do differently?

This isn't just audit trail. It's the operational memory that experienced engineers carry in their heads. The knowledge that walks out the door when they retire.

Why This Matters for Industrial Operations

Gupta and Garg argue that "systems of agents startups have a structural advantage because they sit in the orchestration path." They see full context at decision time: what inputs were gathered, what policies applied, what exceptions were granted.

For enterprise software, this creates competitive advantage against incumbent SaaS providers.

For industrial operations, the stakes are different. Decision traces aren't just about business logic. They encode the causal reasoning that prevents equipment failures, safety incidents, and environmental releases.

Consider the difference:

Enterprise software decision: Approve a 20% discount. If the reasoning is wrong, you lose margin.

Industrial operations decision: Defer maintenance for 72 hours based on condition assessment. If the reasoning is wrong, you might lose the asset. Or worse.

The context graph for industrial operations must capture not just what decision was made, but the causal model that justified it. What failure modes were considered? What leading indicators were weighted? What risk tradeoffs were accepted? What would invalidate the decision if conditions change?

The Architecture That Enables Decision Traces

Gupta and Garg argue that incumbents can't build context graphs because they're not in the orchestration path. Warehouses receive data via ETL after decisions are made. By the time data lands, the decision context is gone.

For industrial operations, this has specific implications.

Historians capture what happened, not why. The historian records that setpoint SP-2047 changed from 340 to 355 at 14:32:07. It doesn't record who approved the change, what conditions justified it, or what would trigger reverting to the original value.

CMMS captures work completed, not reasoning applied. The work order shows "bearing replaced" with labor hours and parts used. It doesn't capture the diagnostic reasoning, the alternative approaches considered, or the tradeoffs accepted.

Control systems capture actions taken, not judgments made. The control system log shows the sequence of operator actions. It doesn't capture why those actions were chosen over alternatives.

The decision trace layer must sit in the orchestration path where human and agent reasoning actually occurs.

Organizations implementing this architecture have achieved extended autonomous operations with full decision lineage, enabling both operational learning and regulatory audit compliance.

The agent architecture itself must emit decision traces. Not as an afterthought or logging function, but as a first-class output of every reasoning cycle:

• What was observed (with full context, not just triggering values)
• What reflection occurred (patterns recognized, precedents retrieved, hypotheses considered)
• What plan was formed (options evaluated, tradeoffs weighed, recommendation justified)
• What action was taken or recommended (with explicit reasoning chain)
• What approval was obtained (human oversight captured as part of the trace)
• What outcome resulted (feedback loop closure)

The XMPro MAGS ORPA cycle (Observe, Reflect, Plan, Act) is a natural structure for decision traces. Each cycle produces a trace. Traces accumulate into the context graph. The context graph becomes queryable operational memory. We call it the "BrainGraph".

This is why decision traces belong in the 90% of process intelligence, not the 10% that handles language. I've written before about how true multi-agent systems are 90% business process intelligence. The coordination, memory management, and decision-making capabilities that create genuine intelligence have nothing to do with text generation. Decision traces are part of that 90%. They're captured through cognitive architecture and business process logic, not through better language models.

The Feedback Loop That Compounds

Gupta and Garg describe a feedback loop that makes decision traces compound. Captured traces become searchable precedent. Every automated decision adds another trace to the graph.

For industrial operations, this loop matters.

Every time an agent diagnoses an equipment issue, the reasoning becomes searchable. The next similar situation benefits from that precedent. Over time, the organization develops institutional memory that doesn't depend on specific experts being available.

Every time a human overrides an agent recommendation, that override becomes a learning signal. Why did the human decide differently? What did they see that the agent missed? The context graph captures these corrections as training data for improved reasoning.

Every time a decision outcome becomes known (the maintenance worked, the failure was prevented, the diagnosis was correct), that outcome links back to the reasoning that produced it. Good decisions become validated patterns. Bad decisions become documented lessons.

This is how tacit knowledge becomes explicit. Not through documentation projects that capture a fraction of what experts know. Through continuous instrumentation of the decision-making process itself.

The New System of Record

Gupta and Garg ask whether "entirely new systems of record emerge, systems of record for decisions, not just objects."

For industrial operations, yes. The system of record for operational decisions will become as valuable as the system of record for operational data.

Consider what becomes possible when decision traces accumulate:

Auditable autonomy. When a regulator asks "why did you defer that inspection," the answer isn't "the algorithm recommended it." The answer is a complete reasoning chain with precedent, policy evaluation, exception approval, and outcome tracking.

Transferable expertise. When an experienced operator retires, their judgment doesn't disappear. The decision traces from thousands of situations they handled become searchable precedent for their successors.

Continuous improvement. When an incident occurs, root cause analysis doesn't start from scratch. The context graph shows what reasoning led to the decisions preceding the incident. This enables systematic learning rather than blame assignment.

Validated patterns. When a diagnostic approach works repeatedly, that pattern becomes codified. Not through manual procedure writing. Through accumulated evidence of successful application.

This is the trillion-dollar opportunity for industrial operations. Not just automating tasks. Capturing the decision intelligence that currently lives only in human heads.

Building Operational Memory

Experienced operators don't just follow rules. They carry decades of decision traces in their heads.

Agentic Operations that capture this reasoning, compound it over time, and make it accessible to human and artificial agents will outperform those that don't.

Industrial organizations building these capabilities should consider:

Instrument the orchestration path. Decision traces must be captured where reasoning occurs. Reconstructing them after the fact from system logs doesn't work.

Design for precedent retrieval. Agents need access to similar past decisions, not just current rules. The context graph must be queryable at decision time.

Capture human overrides as learning signals. When humans modify agent recommendations, that modification contains information. Capture it systematically.

Close the outcome loop. Decision quality can only be evaluated against results. Connect decisions to their outcomes so the system learns which reasoning patterns actually work.

Start with high-stakes decisions. Not every operational action needs full decision trace capture. Focus on decisions where precedent matters, exceptions are common, and poor reasoning carries significant consequences.

The technology is ready. The architecture exists. The question is whether organizations will invest in capturing the decision intelligence that walks out the door with every retiring expert.

Pieter van Schalkwyk is the CEO of XMPro, specializing in industrial AI agent orchestration and governance. XMPro MAGS with APEX provides cognitive architecture and decision trace capabilities for agent networks operating on existing industrial systems.

Our GitHub Repo has more technical information. You can also contact myself or Gavin Green for more information.

Read more on MAGS at The Digital Engineer