Foreword
I started thinking about this problem because I ran into it in the most practical way possible: I was building agents that were supposed to act, not just answer.
The system was an agentic commerce platform. Agents made decisions about purchasing, pricing, inventory, promotions, and customer treatment. The stack looked familiar: large language models for interpretation and planning, retrieval over a vector store for context, tool calls into transactional systems, and an orchestration layer holding the workflow together.
It worked well enough for demos. It did not hold up as a foundation for production decisions.
The failures were not model failures in the usual sense. The models were capable. The retrieval layer often found the right context. The tools did what they were asked to do. The failures were structural.
When a customer preference changed, prior decisions that depended on the old preference did not know they were now standing on weaker ground. When two agents read the same underlying information, they could derive different conclusions and neither could tell which conclusion the system should believe. When a decision was challenged, the system could produce a fluent explanation, but not a faithful account of the actual premises and rules that led to the decision. When a fact became false, there was no general mechanism for finding and re-evaluating everything that had depended on it.
These were not problems that could be fixed by a better prompt. They were not solved by a larger model. They were not solved by adding another vector index or another workflow step. The missing piece was lower in the stack.
The system needed a layer that could maintain the consequences of changing facts.
A database could store authoritative records. A retrieval system could find relevant context. An LLM could interpret ambiguous language and propose actions. A workflow engine could sequence the steps. But none of these provided the one capability the system needed most: a live, inspectable, retractable model of what had been derived from what.
This paper is about that missing layer.
I call it a live reasoning layer: a knowledge substrate beneath agents and applications that records not only facts, but the support structure behind derived facts; not only decisions, but the reasons those decisions currently stand; not only what the system believes now, but what it believed at a previous time and why.
In market-facing language, this is ALIVE reasoning: Active Logic in Variable Environments. In this paper, I use the stricter architectural term, live reasoning layer, because the important claim is not the name. The important claim is that consequential AI systems need active logic over facts that change.
The argument is simple:
As AI systems move from producing answers to making commitments, they need a substrate that can maintain truth under change.
Without that substrate, consequential AI systems will continue to be built on a stack that is excellent at producing outputs but structurally weak at maintaining the correctness, auditability, and coordination of the beliefs those outputs depend on.
Executive Summary
The current AI stack is optimized for generation. It can summarize, classify, retrieve, draft, plan, and call tools with remarkable fluency. That makes it powerful for assistance. It is not sufficient for consequential automation.
A consequential AI system is one whose outputs become commitments: a discount is granted, a claim is denied, an authorization is approved, a supplier is cleared, a shipment is rerouted, a fraud hold is released, a trade is executed, a benefit is awarded, a report is filed.
In these systems, the important question is not only whether the agent produced a plausible answer at the time. The important question is whether the conclusion remains defensible as the world changes.
That requires capabilities the standard AI architecture does not provide:
- Stable fact identity: a way to refer to the same fact across agents, processes, and time.
- Support-aware provenance: a structural record of why a fact or decision is believed, including multiple independent supports.
- Retraction: the ability to remove a premise and automatically re-evaluate every conclusion that depended on it.
- Coordination: a shared model of derived truth that multiple agents can observe consistently.
- Durability: a system of record for derived state, not a transient cache or prompt artifact.
- Time-travel audit: the ability to ask what the system believed at a prior time, and why.
These capabilities are not just features. They are architectural properties.
They cannot be added reliably by prompt engineering. They are not provided by vector retrieval. They are not the same as conversational memory. They are not guaranteed by a message bus. They are not solved by simply writing more application-specific listeners and cleanup jobs.
The missing layer is a live reasoning layer: a substrate that maintains derived facts and their supports as first-class state.
This layer does not replace language models, retrieval systems, databases, workflow engines, or event streams. It sits between them. It lets models interpret the world, lets systems of record provide authoritative inputs, and lets applications act — while preserving the structure required to explain, retract, recompute, and audit the conclusions that follow.
The techniques required to build this layer are not science fiction. Rule-based derivation, logic programming, incremental view maintenance, event sourcing, provenance tracking, content-addressed identity, and temporal query systems have all existed in different forms for decades. What has been missing is their composition into a general-purpose primitive for consequential AI systems.
That composition is now becoming necessary.
The next generation of trustworthy AI systems will not be defined only by more capable models. They will be defined by whether the surrounding architecture can answer a harder question:
When the facts change, what else must change with them?
Part 1 — From Vector Search to Knowledge Layers
For much of the first wave of AI application development, retrieval looked like the missing piece.
Language models were powerful but bounded by context. They needed access to private data, operational documents, product catalogs, support histories, policies, contracts, and domain knowledge. Vector databases became the default answer: embed the corpus, retrieve the nearest chunks, pass them into the model, and let the model generate.
That architecture unlocked a great deal. It made enterprise data usable by language models. It made retrieval-augmented generation the default pattern for serious AI applications. It gave developers a practical way to ground model outputs in private information.
But as agents move closer to action, the industry is discovering that vector search is not the knowledge layer. It is one component inside a knowledge layer.
The next layer emerging above vector search is a governed context layer: retrieval that understands the task, the user, the policy boundary, the provenance requirement, and the cost of context. An agent does not merely need semantically similar text. It needs the right information for the task, filtered by what the actor is allowed to see, traceable to its source, and assembled within the operating limits of the system.
This is an important step. It reflects a real maturation of the market. Retrieval systems are being forced to carry operating rules:
- Intent: what the agent is trying to do.
- Policy: who or what is allowed to see which information.
- Provenance: where the information came from.
- Budget: how much context, latency, and cost the system can spend.
That is a better architecture than naïve vector search. But it is still not enough for consequential systems.
A governed retrieval layer helps the agent decide what to look at next. A live reasoning layer helps the system maintain what follows from what it has already accepted as true.
That distinction matters.
Retrieval answers: what context should the model see?
Reasoning answers: what conclusions currently follow, why do they follow, and what stops following when the facts change?
The market is beginning to move beyond vector databases because agents need more than similarity search. But the deeper shift is still ahead. Consequential AI systems do not only need better context construction. They need maintained derived truth.
They need to know which facts support which conclusions. They need to distinguish one support from another. They need to retract derived state when premises disappear. They need to coordinate multiple agents around the same model of what is believed. They need to answer historical questions about what was believed at a prior time and why.
The first move beyond vector search is the knowledge/context layer.
The next move is the live reasoning layer.
A useful way to see the progression is:
- Vector database — find semantically similar material.
- Governed knowledge layer — retrieve task-relevant, permission-aware, source-traceable context.
- Live reasoning layer — maintain derived facts, supports, retractions, and audit over time.
- Consequential agent substrate — coordinate agents around shared, explainable, retractable truth.
The industry is now validating the need for layer 2. The harder and more defensible opportunity is layer 3.
The central claim of this paper is that consequential AI systems cannot stop at retrieving better context. They need a substrate that maintains the consequences of changing facts.
Part 2 — From Answers to Commitments
Most of the first wave of generative AI adoption has been built around assistance. The model drafts a document. The model summarizes a meeting. The model answers a question. The model helps a human explore a corpus. Mistakes matter, but the output is usually mediated by a person before it becomes an operational commitment.
The second wave is different.
AI systems are increasingly being connected to tools, workflows, transaction systems, approval paths, and external services. They are no longer only producing language. They are making or recommending decisions that change the state of the world.
A system crosses an important boundary when its output becomes something another system relies on.
A customer is marked eligible. A payment is flagged. A supplier is approved. A patient is routed. A route is committed. A trade is executed. A claim is escalated. A benefit is denied. A compliance report is filed. A security alert is suppressed. An account is locked. A target is classified. A field asset is rerouted. A rules-of-engagement review is triggered.
Once that happens, the output is no longer merely an answer. It is a commitment.
Commitments have a different architecture than answers.
An answer can be evaluated at the moment it is produced. A commitment must remain defensible after the world changes. An answer can be copied into a transcript. A commitment needs an audit trail. An answer can be regenerated. A commitment may have triggered actions that cannot be cleanly undone. An answer can be explained after the fact with a summary. A commitment requires a faithful account of the premises that supported it.
The consequence is that the stack that is adequate for assistance is not necessarily adequate for agency.
This is the architectural shift that many teams discover only after they have already built the first version of their agentic system. The problem is not that the agent cannot decide. The problem is that the system around the agent cannot maintain the meaning of the decision.
Part 3 — What Makes a Decision Consequential
A consequential decision is not defined by industry. It is defined by the properties of the decision.
A recommendation engine in commerce can be consequential if it commits inventory or changes pricing. A healthcare system can be non-consequential if it only drafts a note for human review. The boundary is not the domain. The boundary is what happens after the output is produced.
A decision becomes consequential when one or more of the following conditions holds.
1. The action has a cost to reverse
Some actions cannot be cleanly undone.
Sending a notification reaches a person. Granting access exposes information. Approving a claim releases money. Dispatching a vehicle consumes time and fuel. Committing inventory changes availability for other customers. Executing a trade moves capital. Denying a benefit changes a person's options.
In these cases, the system cannot treat the decision as a disposable output. It needs to know what the decision rested on, because reversing or defending the decision later requires more than knowing that it happened.
It requires knowing why it happened.
2. The decision must be justified
Some decisions invite challenge.
A customer asks why they were denied. A regulator asks what rule was applied. A reviewer asks whether the decision was consistent with policy at the time. Another agent asks whether it can safely rely on the output.
A language model can always generate an explanation. That is not the same as justification.
A justification must be structurally faithful. It must identify the actual premises, the actual rules, and the actual chain of derivation that produced the conclusion. It must be inspectable. It must be reproducible. It must distinguish between what was known, what was inferred, what was assumed, and what has since changed.
The harder the domain, the less acceptable it is to substitute a fluent rationale for a faithful one.
3. The premises can change
Many decisions are made from facts that later change.
A diagnosis is corrected. A customer tier is downgraded. A payment is confirmed. A supplier enters sanctions review. A policy is amended. A warehouse count is corrected. A fraud graph is recomputed. A market signal moves. A document is superseded.
The question is not simply whether future decisions should use the new fact. Of course they should.
The harder question is what should happen to conclusions that were already derived from the old fact.
Some should remain valid because they had other independent supports. Some should be retracted. Some should be flagged for review because their basis has materially changed. Some should be recomputed as of the original decision time using a corrected input.
That cannot be done unless the system knows which conclusions depended on which premises.
4. Multiple agents must coordinate
As agentic systems grow, they tend to become multi-agent systems. One agent extracts facts. Another evaluates eligibility. Another handles exceptions. Another communicates with a customer. Another monitors compliance.
If each agent reconstructs the state of the world from retrieval, memory, and local context, the system does not have a shared model of truth. It has a set of private interpretations.
Two agents can read the same underlying data and derive different intermediate beliefs. One agent can act on a premise another agent has invalidated. A downstream agent can rely on an upstream conclusion without knowing which supports still hold.
Coordination is not only a messaging problem. A message bus can deliver events reliably and still leave every consumer with a different derived understanding.
The deeper problem is semantic coordination: making sure that agents share the same model of what is believed, why it is believed, and when it stops being believed.
Part 4 — The Standard AI Stack Does Not Maintain Derived Truth
The dominant architecture for agentic systems combines several powerful components:
- Language models for interpretation, reasoning, and generation.
- Retrieval systems for finding relevant context.
- Vector stores for semantic search over unstructured material.
- Tool interfaces for interacting with external systems.
- Orchestration frameworks for sequencing workflows.
- Memory layers for preserving conversational or task context.
- Databases and event streams for operational state.
Each component solves a real problem. None of them, by itself, maintains derived truth under change.
Models generate; they do not preserve provenance
A model can infer, summarize, classify, and explain. But unless the surrounding system records the structure of the inference, the model's output becomes an opaque artifact.
The model may have considered the right evidence. It may even have produced a correct conclusion. But if the system does not separately record which premises supported the conclusion, which rule or policy connected them, and which other conclusions depended on it, the knowledge is not operationally maintainable.
The explanation can be regenerated later, but regeneration is not provenance.
Retrieval finds context; it does not maintain state
A retrieval system answers the question: what material seems relevant to this query?
That is not the same as answering: what does the system currently believe, and what follows from those beliefs?
Retrieval is approximate, context-dependent, and order-sensitive. It is excellent for surfacing unstructured material. It is not a system of record for derived facts. It does not guarantee that two agents will retrieve the same supporting material. It does not track which conclusions were derived from which retrieved passages. It does not automatically retract conclusions when a passage is superseded.
Retrieval is necessary. It is not sufficient.
Databases store records; they do not usually store consequences
Databases are excellent systems of record. They store authoritative facts, transactions, and state.
But most application databases do not record the full dependency structure of derived conclusions. They can tell you that a decision was written. They may tell you what fields existed at the time. They generally cannot tell you every derived fact that depended on a now-corrected premise, which supports remain valid, and what the system believed as of a prior time unless the application explicitly built that machinery.
A database remembers what was stored. A live reasoning layer remembers what followed from what was stored.
Rules engines fire rules; they do not necessarily maintain support
Traditional rules engines are useful for encoding policy and triggering actions. But many are built around firing conditions, not maintaining the support structure of derived facts over time.
In a consequential system, the question is not only whether a rule fired. The question is whether the conclusion produced by that rule is still supported after its premises change, whether another rule independently supports the same conclusion, and what downstream conclusions depended on it.
A rule firing is an event. A derived fact with support is state.
Event streams deliver change; they do not define meaning
Event streams can give every consumer the same ordered sequence of events. That is valuable and often necessary.
But delivering the same events does not guarantee that every consumer will derive the same conclusions from them. The consumers must also share the rules of derivation, the identity of facts, the support structure, and the retraction semantics.
An event stream can coordinate delivery. A live reasoning layer coordinates derived meaning.
Part 5 — The Missing Layer
The missing layer is a live reasoning layer.
A live reasoning layer is a substrate that stores, derives, updates, retracts, and explains facts as the world changes.
It is not just a database, because it does not merely store facts. It maintains the consequences of facts.
It is not just a rules engine, because it does not merely fire actions. It preserves derived facts and their supports.
It is not just a knowledge graph, because it is not primarily a static map of entities and relationships. It is a dynamic system for maintaining derived state under change.
It is not just an event stream, because it does not only order events. It gives semantic structure to how events change what the system believes.
It is not an LLM memory layer, because it is not private conversational context. It is shared operational knowledge.
A live reasoning layer provides six core properties.
1. Identity
A fact must be something the system can refer to stably.
If two agents encounter the same logical fact, they need to know they are talking about the same thing. If a decision depends on a fact, the system needs a durable reference to that fact. If the fact is later corrected or retracted, the system needs to find everything that depended on it.
Without identity, knowledge remains text. With identity, knowledge becomes addressable.
2. Provenance
A consequential system must know why a fact is believed.
Some facts are authoritative inputs: a customer statement, a lab result, a contract clause, a policy document, a transaction record, a market feed update. Other facts are derived: eligibility, risk, priority, approval, denial, obligation, exposure.
A live reasoning layer records the chain from derived facts back to their supports. It records not only that a conclusion exists, but which facts and rules produced it.
Provenance is not a log message. It is part of the structure of the fact.
3. Support
Many conclusions have more than one reason to be true.
A customer may be eligible for a benefit because of loyalty tier and also because of a retention offer. A fraud flag may stand because of location mismatch, merchant risk, and spending anomaly. A supplier may be approved because it passed security review and also because it is covered by an existing master agreement.
If one support disappears, the conclusion should not necessarily disappear.
This is where support-aware reasoning matters. The system must distinguish the logical fact from the independent supports that currently justify it. A conclusion with three supports that loses one support is different from a conclusion that loses its only support.
Without support tracking, systems either retract too aggressively or fail to retract at all.
4. Retraction
When a premise becomes false, the system must propagate the consequences.
Retraction is not deletion. It is re-evaluation.
If a supporting fact is invalidated, every derived fact that depended on it must be checked. If a derived fact has other supports, it remains valid with narrower provenance. If it has no remaining support, it is retracted. If other facts depended on that derived fact, the process continues.
This is the difference between a system that stores conclusions and a system that maintains conclusions.
5. Coordination
Multiple agents and services need to share the same derived state.
A live reasoning layer gives agents a common substrate for committed facts and derived conclusions. Agents may still use models to interpret inputs and generate outputs, but the conclusions they commit to become part of shared state.
When one agent asserts a fact, other agents can observe the consequences. When a fact is retracted, every dependent conclusion changes according to the same semantics. When a decision is challenged, the system does not ask each agent to reconstruct its private reasoning; it queries the shared support structure.
Coordination requires shared meaning, not just shared messages.
6. Time-travel audit
A consequential system must answer questions about the past.
What did the system believe on the date of the decision? Which facts had arrived by then? Which rule version was in force? Which supports justified the conclusion? What changed afterward? Would the conclusion have differed if a corrected input had been available at the time?
These are not forensic questions that should require stitching together logs, prompts, database snapshots, and human guesses. They should be native queries against the substrate.
Audit is not an afterthought. It is a core property of consequential systems.
Part 6 — Five Failure Stories
The easiest way to understand the missing layer is to look at the failure pattern that appears across different domains.
The data exists. The events exist. The logs exist. The system still cannot answer the structural question.
1. Promotion eligibility with surviving support
A commerce platform runs agents that personalize promotions and customer treatment.
A customer receives free expedited shipping. The benefit is granted because the customer is a gold-tier member. Separately, the customer also qualifies for the same benefit through a temporary retention campaign after a support incident.
Operationally, the system now has one conclusion:
The customer is eligible for free expedited shipping.
But the conclusion has two independent supports:
- The customer is gold tier.
- The customer is in the retention campaign.
A month later, the customer's tier is recalculated. They are no longer gold.
A naive implementation has two common failure modes.
The first is over-retraction: the system removes the benefit because the gold-tier support disappeared, even though the retention-campaign support still holds.
The second is under-retraction: the system leaves the benefit in place but cannot explain why, because it has lost the distinction between the original support and the surviving support.
Both are failures of support structure.
A live reasoning layer treats the eligibility conclusion as a derived fact with multiple supports. When the gold-tier fact is retracted, only that support is removed. The eligibility fact remains because the retention-campaign support still justifies it. The system can explain the change precisely: the customer is no longer eligible by tier, but remains eligible by campaign.
This is a simple example, but it reveals the deeper requirement. Consequential systems do not only need to know whether a conclusion is true. They need to know why it is still true.
2. Multi-agent fraud disposition
A payment processor runs two cooperating agents.
Agent A raises fraud holds. Agent B releases, escalates, or routes those holds after additional information arrives.
A cardholder makes a high-value purchase abroad. Agent A flags the transaction as suspicious. The flag rests on three supports:
- The transaction location differs from the cardholder's recent activity.
- The merchant belongs to a cluster associated with prior fraud.
- The amount exceeds the cardholder's normal spending pattern.
The cardholder's spouse contacts support and confirms the cardholder is traveling. The support agent records the travel confirmation.
The location-mismatch support is now weakened or invalidated. The merchant-risk and spending-pattern supports remain.
In a conventional architecture, Agent B may receive two pieces of information: the transaction is flagged, and a travel confirmation exists. But it may not know which support of the flag has changed. From Agent B's perspective, the fraud flag is a single opaque assertion.
That forces bad choices.
Release the hold, and the system may underreact because two fraud supports remain. Keep the hold, and the system may overreact because the travel explanation resolved the original location concern. Rerun the entire fraud workflow, and the new result may differ for unrelated reasons, without explaining what changed.
A live reasoning layer represents the fraud flag as a derived fact with named supports. When the travel confirmation is added, the system can remove or mark the location support while preserving the other supports. Agent B now sees not merely that the flag exists, but that it exists on a narrower basis.
That enables better disposition logic:
- A flag supported only by location mismatch may be released after travel confirmation.
- A flag still supported by merchant-cluster and spending-pattern evidence may be escalated.
- A flag whose support changed materially may be routed for human review.
The agents coordinate through shared reasoning state, not through opaque messages about each other's outputs.
4. Security operations under changing threat intelligence
A security operations platform uses agents to triage alerts across identity logs, endpoint telemetry, cloud audit events, vulnerability data, and threat intelligence feeds.
An agent suppresses an alert because it appears to be benign administrative activity. The suppression rests on several supports:
- The user is a member of the infrastructure administration group.
- The source IP address is associated with the corporate VPN.
- The accessed system is within the user's normal operating scope.
- The activity matches a known maintenance window.
Later, a threat intelligence update reclassifies the source IP range. What was believed to be normal VPN egress is now associated with compromised credentials and suspicious proxy behavior. At the same time, an identity governance update shows that the user was removed from the infrastructure administration group before the activity occurred, but the change had not propagated to the alerting system when the original suppression happened.
In a conventional architecture, the original suppression remains buried in the case history. The threat intelligence update exists in one system. The identity correction exists in another. The alert suppression exists as a past workflow decision. Unless a team has built custom reprocessing logic for this exact relationship, the system may not know that a previously suppressed alert now deserves escalation.
A live reasoning layer treats the suppression as a derived fact with explicit supports. When the IP classification and group-membership facts change, the system can identify every suppression, closure, or risk score that depended on those supports. Some alerts may remain suppressed because other supports still justify them. Others may be reopened because their only benign explanation disappeared. Others may be escalated because the support structure changed in a high-risk direction.
The value is not merely better alert retrieval. It is the ability to maintain the consequences of threat intelligence as intelligence changes.
Security is full of this pattern. Indicators are reclassified. Accounts change privilege. Vulnerabilities are rescored. Assets move between environments. Exceptions expire. A finding that was low priority yesterday can become urgent tomorrow because one of its supports changed.
A consequential security system needs to know not only what it sees now, but which prior conclusions must be revisited.
5. Intelligence and defense decisions under contested evidence
In intelligence and defense contexts, the stakes are even higher. AI systems may assist with entity resolution, threat assessment, logistics prioritization, force protection, targeting workflows, or rules-of-engagement review. In these environments, automated systems should not replace lawful human command and judgment. But even as decision-support systems, they must preserve the structure of what they claim and why.
Consider an intelligence workflow that classifies a location as a hostile logistics node. The classification may rest on multiple supports:
- Signals intelligence suggesting repeated communications with a hostile unit.
- Imagery analysis identifying vehicles associated with prior hostile logistics activity.
- Human intelligence reporting that a named facilitator uses the site.
- Pattern-of-life analysis showing unusual nighttime movement.
- Absence of protected-site indicators in the available records.
Later, one support is weakened. A new human report disputes the facilitator's association with the site. Or a protected-status registry is updated. Or imagery analysts reclassify the vehicles as civilian commercial trucks. Or signals intelligence is found to have been misattributed because two entities shared an identifier.
A conventional AI architecture may preserve the original report, the later update, and the generated summary. But the critical question is structural: which downstream assessments, watchlist entries, operational recommendations, or review packets depended on the weakened support?
In high-stakes national security contexts, that question cannot be answered by a model-generated explanation after the fact. It requires a faithful derivation chain. The system must distinguish between evidence, inference, confidence, source, policy constraint, and decision. It must show which supports remain, which were retracted, which conclusions are now invalid, and which require renewed human review.
This is why the live reasoning layer matters in domains currently dominated by large proprietary ontology and intelligence platforms. Those platforms are valuable because they do more than store data. They organize operational knowledge, connect evidence to assessments, and support institutional decision-making. But the same need is broader than any one vendor or vertical system.
As agentic systems enter security, intelligence, and defense workflows, the requirement becomes unavoidable: the system must maintain a shared, auditable model of derived claims under changing and contested evidence.
The purpose of such a substrate is not to automate irreversible war decisions. It is to make any AI-assisted recommendation more inspectable, more constrained, more reviewable, and more accountable before humans act on it.
Part 7 — The Pattern Beneath the Examples
The same pattern appears in every example.
The authoritative facts are usually stored somewhere.
The customer tier is in the commerce system. The campaign membership is in the marketing system. The travel confirmation is in the support system. The merchant risk is in the fraud graph. The diagnosis is in the clinical record. The formulary policy is in a policy document.
The missing information is not the source fact.
The missing information is the structure connecting source facts to derived conclusions.
Which conclusions depended on this fact? Which supports remain if this fact is removed? Which downstream decisions are now invalid? Which are still valid but on a narrower basis? Which require review because their basis changed? What did the system believe at the time of the original decision? What would it have believed if a corrected fact had been available then?
These are structural questions.
A system that stores only records cannot answer them. A system that retrieves context cannot answer them reliably. A system that logs prompts cannot answer them faithfully. A system that fires rules but does not preserve supports cannot answer them completely.
The missing substrate is the layer that makes those questions answerable by construction.
Part 8 — Why This Becomes Urgent Now
The need for a live reasoning layer is not new in theory. Many of the underlying ideas are old and well understood.
Logic programming has long studied derivation. Databases have long studied incremental view maintenance. Event-sourced systems have long preserved ordered histories of change. Version-control systems have long used content-addressed identity. Temporal databases have long supported time-oriented queries. Provenance research has long examined how data products depend on source data.
What is new is the deployment context.
AI systems are being asked to operate in domains where these properties are no longer academic niceties. They are becoming production requirements.
Three shifts make the problem urgent.
1. Agents are moving closer to action
When AI systems only drafted text, the human user absorbed much of the responsibility for validation. As agents move into workflows, tools, and transaction systems, their outputs become part of operational state.
The closer an agent gets to action, the more important it becomes to maintain the structure behind its conclusions.
2. Enterprises are discovering that logs are not enough
Many teams assume they can audit agent behavior by storing prompts, responses, retrieved documents, and tool calls.
Those logs are useful. They are not enough.
Logs can show what happened. They do not automatically show which facts supported which conclusions, which conclusions depended on a retracted premise, or what the system believed under the rules and facts in force at a prior time.
For consequential systems, audit requires reasoning structure, not just activity history.
3. Multi-agent systems amplify inconsistency
A single agent can sometimes hide architectural weakness behind a narrow workflow. Multi-agent systems make the weakness visible.
As soon as multiple agents derive, consume, and act on shared conclusions, the system needs a coherent substrate for derived truth. Otherwise each agent becomes a private interpreter of a shared but unstable world.
The more agents there are, the more expensive inconsistency becomes.
Part 9 — What the Live Reasoning Layer Is Not
The live reasoning layer is easiest to misunderstand if it is described only by analogy. It overlaps with several familiar categories, but it is not identical to any of them.
It is not a replacement for language models
Language models remain essential. They interpret unstructured inputs, classify ambiguous material, generate language, help users explore information, and reason in domains where formal representation is impractical.
The live reasoning layer does not replace that. It gives the system a place to commit the structured facts and conclusions that must survive beyond a single model invocation.
It is not a replacement for retrieval
Retrieval remains the right tool for finding relevant documents, passages, examples, and context.
The live reasoning layer complements retrieval by representing the facts and derived conclusions the system is willing to stand behind.
Retrieval helps the system find evidence. The live reasoning layer helps the system maintain what follows from accepted evidence.
It is not merely a knowledge graph
Knowledge graphs represent entities and relationships. They are useful and often complementary.
But many knowledge graphs are relatively static, curated, and read-oriented. A live reasoning layer is dynamic and change-oriented. It is concerned with how derived facts appear, remain supported, lose support, and disappear as the underlying world changes.
The central primitive is not just relationship. It is supported derivation over time.
It is not merely a rules engine
Rules engines encode conditions and actions. They are useful for policy automation.
A live reasoning layer must do more than fire rules. It must preserve the derived facts produced by rules, track their independent supports, propagate retractions, coordinate consumers, and support historical questions.
The distinction is subtle but important: the goal is not only to execute logic. The goal is to maintain the state implied by logic.
It is not merely a database
Databases store source facts and transactions. A live reasoning layer may use databases and may expose database-like queries, but its role is different.
It maintains the consequences of facts, not only the facts themselves.
It is not merely an event log
Event logs preserve ordered change. A live reasoning layer may rely on an event log, but the event log alone does not define the derivation semantics.
The live reasoning layer uses ordered change to maintain a coherent model of derived truth.
Part 10 — The Required Primitives
A credible live reasoning layer needs more than a slogan. It needs specific primitives.
Facts as first-class entities
Facts must be represented as addressable objects, not just strings in a prompt or rows without semantic identity. The system must be able to refer to the same fact across derivations, agents, time, and audit queries.
Rules as inspectable derivation logic
The system must know how derived facts are produced. The rules do not need to cover every aspect of cognition; language models will still handle ambiguity and interpretation. But once a system commits to a derived operational fact, the derivation path must be inspectable.
Supports as independent reasons
A derived fact can have multiple independent supports. The system must track them separately. This prevents both premature retraction and unjustified persistence.
Retraction as a native operation
Removing a fact must not be treated as an application-specific cleanup problem. It must trigger structural re-evaluation of derived state.
Materialized derived state
Important derived facts should be maintained live, not recomputed from scratch for every question. Materialization makes the reasoning layer operationally useful: agents and services can subscribe to derived changes, query current conclusions, and react when conclusions change.
Ordered change propagation
Consumers need a consistent view of how facts and supports changed. Ordered propagation lets agents coordinate on the same sequence of semantic changes.
Historical reconstruction
The substrate must answer questions about the past: what was believed, why it was believed, which supports existed, and what changed later.
Operational durability
The reasoning layer must behave like infrastructure. It must survive restarts, recover from failures, bound resource use, expose observability, and provide predictable semantics under load.
Without operational durability, the idea remains a research pattern rather than a production primitive.
Part 11 — Where This Layer Fits
The live reasoning layer sits between systems of record, AI agents, and application workflows.
Systems of record provide authoritative inputs: customers, policies, contracts, transactions, medical records, support events, market feeds, inventory counts, identity records, regulatory documents.
Language models and other AI components interpret ambiguous material, extract candidate facts, classify events, draft responses, and propose actions.
The live reasoning layer receives accepted facts, applies inspectable derivation logic, maintains derived conclusions, tracks supports, propagates changes, and exposes current and historical views.
Applications and agents consume the maintained conclusions: eligibility, approval, risk, priority, obligation, exposure, recommendation, exception, denial, escalation.
This separation matters.
It lets models remain probabilistic where probabilistic interpretation is appropriate. It lets operational conclusions become structured where structure is required. It lets agents act without turning every agent into its own private database, rules engine, memory system, and audit system.
The result is not less AI. It is AI with a stronger foundation.
Part 12 — The Strategic Consequence
Every major software architecture eventually discovers the layer it was missing.
Relational databases emerged because applications needed a common way to store and query structured data. Message queues and event streams emerged because distributed systems needed a common way to communicate change. Search indexes emerged because users needed a common way to retrieve unstructured information. Vector databases emerged because AI applications needed a common way to retrieve semantically similar context.
Consequential AI systems are now discovering a different missing layer.
They need a common way to maintain derived truth under change.
Without that layer, every team building consequential agents will recreate fragments of it inside application code: ad hoc provenance tables, brittle listeners, custom re-evaluation jobs, partial audit logs, duplicated policy logic, and workflow-specific cleanup handlers.
Some of those systems will work for a while. Many will fail at the edges: when facts are corrected, when multiple supports exist, when rules change, when auditors ask historical questions, when agents disagree, when the system needs to explain not only what it did but why it still believes what it believes.
The cost of not having a substrate will be paid repeatedly in every serious deployment.
A live reasoning layer changes the economics. It turns provenance, retraction, coordination, and audit from bespoke application work into inherited infrastructure properties.
That is what makes it a category, not just a feature.
Closing
The current AI stack is extraordinary at producing answers. But consequential systems need more than answers.
They need commitments that can be defended. They need conclusions that update when their premises change. They need agents that coordinate on shared derived truth. They need audit trails that are structural, not reconstructed. They need to know not only what is believed, but why it is believed, when it became believed, and what would cause it to stop being believed.
That requires a live reasoning layer.
The central problem of consequential AI is not only generation. It is maintenance: maintaining the consequences of facts as the world changes.
The organizations that recognize this will build agentic systems that are more reliable, more explainable, and more governable. The organizations that do not will continue to discover, one deployment at a time, that a fluent agent is not the same thing as a trustworthy system.
The missing substrate is the layer that turns agentic outputs into maintainable knowledge.
It does not replace the AI stack. It completes it.
Appendix: Technical Concepts in Plain Terms
Identity
Identity means the system has a stable way to refer to a fact. Without identity, two agents may talk about the same logical fact in different words and never know they mean the same thing. With identity, facts become addressable and traceable.
Provenance
Provenance means the system records why a fact is believed. For a source fact, that may be an external record or event. For a derived fact, it is the rule and supporting facts that produced it.
Support
Support means an independent reason a derived fact is true. A fact can have one support or many. Losing one support does not necessarily mean the fact is false.
Retraction
Retraction means removing a premise and propagating the consequences through derived state. It is not just deleting a row. It is recomputing what still follows.
Incremental View Maintenance
Incremental view maintenance is the technical discipline of keeping derived views up to date as source data changes, without recomputing everything from scratch. In a live reasoning layer, this idea is applied to derived facts and their supports.
Time-travel audit
Time-travel audit means the system can answer historical questions: what was believed at a given time, which supports existed then, and what changed afterward.
Live reasoning layer
A live reasoning layer is a production substrate that combines these ideas so consequential AI systems can maintain derived truth under change.