Streaming Intelligence

The Bottom Line

AI fabric is the runtime that carries context, freshness, policy, lineage, and replay with an AI decision from evidence to action. It addresses the production problem that model demonstrations conceal: an answer may sound credible while relying on stale state, unapproved sources, or a record that cannot be reconstructed. The economic cost sits in rebuilding those conditions for every new use case, not simply in paying for inference. A system deserves operational trust only when a reviewer can establish what it knew, what it was allowed to do, and how its action can be corrected.

‍

A prototype can answer before it can account for itself

A prototype demonstrates that a model can produce a useful response under prepared conditions. It says little about whether the response remains valid after an account changes status, an inventory event arrives, a policy is amended, or an upstream service becomes unavailable. Those are not edge cases added after deployment. They are the ordinary conditions of an operational system.

The gap begins with what a demonstration leaves implicit. Its corpus is selected in advance. Its prompt often has a fixed shape. Access decisions are assumed or handled by a person outside the flow. A reviewer can retrace an answer because the materials are small, stable, and close at hand. The model appears to be the system because the rest of the system has not yet been asked to change.

Production reverses that arrangement. Evidence changes while an agent is deciding. The acceptable tool may depend on the case and the moment. A source can be factually plausible yet prohibited for the action under consideration. A later reviewer may need to distinguish an error in the model from an error in the data, a permission failure, or a missing event. If those facts were assembled as temporary inputs and discarded, the system cannot offer an explanation with the action.

That is the production boundary.

This is consistent with the NCSC guidance on secure AI system development, which treats secure design, development, deployment, and operation as distinct but connected responsibilities. It also places logging, monitoring, and update management in the operating phase. That framing matters because an AI system remains a system after its first answer. A response is one event in a longer chain of evidence, authorization, and consequence.

The difficult question is therefore not whether a model can reason over a document set. It is whether the surrounding runtime can preserve the conditions of reasoning while the world changes. The answer determines whether a prototype becomes a service or a recurring controls project.

‍

The prototyping tax is repeated context reconstruction

The term prototyping tax usefully names the work that accumulates after a promising demo. In its analysis of AI delivery, Databricks identifies fragmented context, siloed knowledge, and awkward API boundaries as obstacles to production. The diagnosis is broader than any one platform. Every disconnected boundary makes someone responsible for reconstructing the conditions under which an agent may act.

That reconstruction usually contains four separate obligations:

• Current data, so the decision refers to the present state rather than an old export.
• Permitted data and tools, so the system acts within the authority available at that time.
• Traceable evidence, so a reviewer can identify the source, transformation, and policy basis.
• A reversible record, so a mistaken action can be contained, examined, and replayed without guesswork.

‍

None of these obligations disappears when a team adopts a better model. They move. If they live in prompt templates, point-to-point integrations, periodic exports, and separate audit stores, each new agent needs its own arrangement. The model endpoint may be shared, but the operational facts around each call are rebuilt.

The cost is architectural as well as financial. Detached controls create separate release cycles and separate failure modes. A policy change must reach every tool wrapper. A new source requires another retrieval path. An incident investigation must join logs that were never designed to form one record. The delay is part of the cost because it limits which decisions can safely be automated.

This is why a useful economic test is not the price of a model call in isolation. It is the marginal work required to add a governed decision. When the next use case requires another export, permission mirror, vector index, and audit adapter, the architecture has priced reuse out of reach. An AI fabric seeks to make the evidence and control path reusable rather than making the prompt reusable alone.

‍

‍

What is AI fabric?

AI fabric is a production runtime that keeps the evidence, permissions, changing state, and replay record of an AI decision connected to that decision as it is made. This is an architectural definition, not a claim that the term has a single settled industry meaning. Its purpose is to draw a firm boundary between a system that merely supplies data to a model and a system that can account for an action.

The word runtime is important. A catalog, ontology, or shared semantic layer can improve discovery and interpretation. Those are useful capabilities. They do not by themselves establish that a decision used the latest permitted evidence, that a tool invocation was authorized, or that the action can be replayed against the event history. Those properties arise in the path where state is read, rules are evaluated, tools are called, and results are recorded.

An architecture that cannot retain that path has supplied information, not accountability.

In this design, context is not a static folder handed to a model. It is a time-bound assembly of facts with source and access conditions. Policy is not a document consulted during review. It is a constraint evaluated before a tool is used or an action is committed. Lineage is not an after-action report. It is the connection between the input events, transformations, retrieved material, model output, and effect. Replay is not an invitation to repeat a harmful action. It is the ability to reconstruct and test the decision path under controlled conditions.

That definition also explains why an AI fabric differs from a generic data fabric. Data abstraction reduces the friction of finding and accessing information across stores. An AI runtime must additionally carry changing operational state through the act of deciding. The distinction becomes material when a decision has consequences beyond a generated paragraph.

For a concrete articulation of this position, the Scalytics Sovereign Decision Fabric frames the design around keeping control and execution close to governed data rather than treating central extraction as the default. The claim is not that all data must remain in place. It is that copying evidence out of its operational setting creates a new burden of freshness, authorization, and proof.

‍

Freshness changes the economics of trust

Freshness is often described as a performance concern. For AI decisions, it is a validity concern. A model may apply a sound rule to an obsolete account state. It may select a permitted action under yesterday's policy. It may summarize an inventory position that was accurate when indexed but is wrong when the summary is used.

The relevant question is not whether every source needs millisecond updates. It is whether the system knows the freshness requirement for the decision at hand and can enforce it. A recommendation based on a quarterly planning dataset has a different tolerance from an action that consumes inventory or changes a case status. Treating both as generic retrieval problems loses the relationship between the fact and the consequence.

Databricks makes this point in operational terms in its account of sub-second feature serving. The value of a current feature is not its speed alone. It is that the value arrives when the model needs it. From the stream side, Confluent's AI update similarly argues for real-time, context-aware AI and managed access around the stream. These are signals of a shared constraint: decisions lose meaning when their inputs have no reliable relation to present conditions.

Export-into-the-lake patterns can be appropriate for analysis, training, or long-horizon reporting. They become harder to defend when the copied representation is expected to govern a live action. The copy must be synchronized, permissions must be reconciled, and provenance must survive the move. Each requirement may be solvable. Together, they create a second operational system whose only purpose is to make an old architectural separation appear current.

An AI fabric does not eliminate replication. It forces the replication decision into the open. What is copied, at what delay, under which policy, and with what evidence of consistency? When those questions are explicit, freshness becomes a stated property of a decision rather than an assumption hidden in a retrieval layer.

‍

Governance belongs in the act of execution

Governance fails when it is treated as a document that sits beside the system. A policy is meaningful only if it can affect the tool call, retrieval, or state transition to which it applies. Otherwise, compliance becomes a retrospective comparison between intended rules and recorded behavior.

The NIST AI Risk Management Framework frames AI risk management as a continuing organizational discipline. Its AI RMF Playbook connects governance to mapping context, measuring risk, and managing it over time. That is a useful correction to the idea that governance can be solved by model documentation at release. Context changes after release. So do data, threats, permissions, and the available actions.

In runtime terms, governance has a few irreducible jobs. It must decide which sources may enter the context. It must constrain which tools are reachable and which parameters are permitted. It must record enough of the chain to support investigation. It must provide a controlled route to reverse or compensate for an action. Those jobs may be distributed across services, but they cannot be absent from the execution path.

Logging illustrates the difference. A text log that says an agent called a service is useful but incomplete. A decision record should connect the authorization, source versions, policy result, tool invocation, response, and resulting event. The NCSC guidance on logging and monitoring emphasizes real-time monitoring, log integrity, and visibility into data movement. For AI actions, those concerns become part of explainability. Without a trustworthy record of movement and authorization, a post hoc explanation is an interpretation, not evidence.

Centralized-ontology platforms can create an orderly representation of an organization. Yet a representation can become another destination for copied evidence. As the distinction between event streams and centralized ontologies makes clear, a static abstraction can lose the live operational context that must govern a decision. If the operational system remains elsewhere, the central layer inherits a synchronization problem and then inherits the burden of proving which version governed the action. The issue is structural, not ideological. Centralization is justified when it improves control without severing the decision from the facts that authorize it. It is weak when it substitutes a reconstructed view for the operational record.

‍

Can AI agents run without centralizing data?

Yes. AI agents can run without centralizing data when the runtime can query or receive governed evidence in place, apply policy before action, and preserve an auditable record of the resulting decision. This does not mean every agent should reach every source directly. It means authority and evidence should travel through a controlled path rather than through an uncontrolled export.

Federation is often misunderstood as refusal to integrate. In practice, it is a choice about where control is exercised. A federated design may use event streams to carry changes, constrained interfaces to expose approved tools, and local policy enforcement near systems of record. The agent receives what it needs for the decision, with conditions attached. It does not need a universal copy of every source to be useful.

Integration is still required. The question is whether it preserves the evidence and authority that make the resulting action defensible.

This approach has limits. Cross-source queries can be slower or harder to coordinate. Local owners must expose reliable interfaces. Eventual consistency can be unacceptable for some actions. A central analytical store can remain the sensible choice for model training, broad reporting, or workloads that do not require live operational authority. The point is not to ban central stores. It is to stop confusing a central store with a decision runtime.

The trade-off should be made in terms of consequence. Where an agent merely drafts a low-impact summary, a cached corpus may be acceptable. Where it recommends, authorizes, changes, or initiates something, the architecture should be able to identify the current evidence and the rule that permitted the action. That standard can require more design discipline. It also prevents the false economy of a fast prototype that later needs a separate apparatus for control.

Protocols such as Kafka, MCP, and ACP are useful here because they can formalize movement and tool access. They do not supply governance merely by being present. The design still needs explicit identity, authorization, schemas, retention, error handling, and replay boundaries. Tools are part of the action surface. Treating them as neutral plumbing leaves the most consequential interface outside the policy model.

‍

The test is whether the system can defend one decision

An architecture review should begin with a single consequential decision, not a platform diagram. Select an action the system may take, then ask for the record that would let an independent reviewer defend or reject it. The test is demanding because it makes every detached assumption visible.

Ask five questions:

1. What evidence was available when the decision was made, and what was its freshness condition?
2. Which source, policy, and identity rules allowed that evidence and those tools to be used?
3. What transformations, retrieval steps, and model outputs connected the evidence to the action?
4. What event records the effect, and how can a reviewer determine whether it succeeded or failed?
5. Can the decision be reconstructed or compensated for without relying on a person's memory or a missing export?

‍

If the answers require stitching together screenshots, prompt versions, warehouse extracts, and service logs after an incident, the system may have AI components but it does not yet have an AI fabric. If the answers exist in the operational path, the organization has a defensible basis for expanding automation.

The policy choice is plain. Treat context, authorization, and replay as peripheral support for a model, and every new agent will recreate them at the margins. Treat them as the runtime of the decision itself, and model choice becomes one replaceable part of an accountable system. The position worth defending is not that all data should be centralized or that all data should stay put. It is that no consequential AI action should be separated from the evidence and authority required to explain it.