Streaming Intelligence

The Bottom Line

Grounded web agents can produce relevant answers without being controlled systems. Grounding constrains the information an agent sees. It does not reliably constrain what the agent spends, retries, or attempts after it has formed an answer. Production autonomy becomes defensible when the execution path, rather than the prompt alone, applies a budget, checks authority, and leaves a trace that can be reconstructed. A system that cannot deny an unauthorised tool call before it runs has described a policy, not enforced one.

‍

Grounding does not govern execution

Grounding addresses an epistemic problem. It gives a model current source material, defined terms, permissions, or an approved representation of the world before the model responds. That is a serious requirement. A system that cannot distinguish an authoritative record from a plausible text fragment has no basis for acting on either one.

Databricks makes a useful version of this distinction in its discussion of operationalizing Genie Ontology.

‍Governed assets, semantic definitions, and access permissions shape the context available to an agent. They improve the chance that the agent begins from the right facts. They do not determine the sequence of operations that follows.

The gap becomes clear once the agent has a tool. A relevant answer can lead to another search because the model wants corroboration. A failed request can lead to a retry. A tool that accepts both read and write verbs can turn a factual finding into an attempted change. Each step may look locally reasonable. Together they can create cost, operational exposure, or both.

This is not an objection to grounding. It is a boundary condition. A retrieved policy can tell an agent that a record may not be altered. It cannot, by itself, stop the downstream API call. That decision occurs where the tool request is assembled, authenticated, transmitted, and charged.

The distinction matters because relevance is easy to mistake for control. A demonstration that returns correct answers from approved data proves something about context quality. It does not prove that repeated tool calls stop at a spending limit, that a delegated identity survives across services, or that a consequential action will be denied. Those are properties of execution.

‍

Prompts end at the model boundary

Prompt instructions are valuable as guidance, but they are a weak enforcement point. They depend on a probabilistic system to follow language instructions while choosing among tools, handling errors, and responding to new context. The prompt is also not present in every place where work occurs. A credential broker, an MCP server, a search provider, and an operational API can each see a request without seeing the original instruction.

Consider a rule that says an agent may spend only a fixed amount on external search. If the model receives that rule as prose, it may intend to comply. But intention does not make the search service reject call number eleven. Only a component on the execution path can count calls against a limit and return a refusal before the next request leaves the system.

The same logic applies to identity. A statement that an agent acts "on behalf of" a user is not enough if every agent shares a broad service credential. After a disputed action, the record then shows that a credential acted. It does not reliably establish which delegated authority authorised that action or whether the operation was within scope.

This is consistent with the direction set by the NIST AI Risk Management Framework, which frames trustworthy AI as a matter of managing risks across the system, not merely improving model behaviour. NIST's Generative AI Profile places those risks in the context of generative systems rather than treating the model as an isolated component. NIST's Manage function further treats risk treatment as a continuing activity shaped by priorities, resources, monitoring, and documentation. A prompt can contribute to that discipline. It cannot substitute for it.

The important question is therefore not whether an agent has been told to behave. It is whether the systems that spend money and change state can independently decide that the agent is not permitted to proceed. If the answer is no, the control depends on the model doing the right thing at every turn. That is an unsuitable place to put the final boundary.

‍

A tool call needs an enforceable contract

Every tool invocation is a request to consume a resource or alter a system. Treating it as a contract makes the control problem concrete. Before execution, the runtime should be able to evaluate a small set of facts that the model cannot merely narrate into existence.

The five controls below are a design baseline, not a claim that one product can remove all agent risk.

‍

1. Budget sets the permitted amount of work for a defined purpose and period. The accounting must include more than model tokens. Retrieval, search, tool calls, retries, and paid downstream services all create work that an agent can multiply.
2. Principal identity carries both the acting agent and the authority delegated to it. The runtime should bind that identity to the request rather than infer it later from shared credentials.
3. Allowlist limits the tools, methods, and data domains available for the stated task. Access to a search endpoint does not imply access to an update endpoint.
4. Policy gate evaluates the proposed operation before it executes. It can allow read-only collection, require a checkpoint for a material action, or deny an action that crosses a defined boundary.
5. Trace preserves the evidence needed to inspect the chain. At minimum, it should join the request, delegated identity, tool name, arguments or a protected representation of them, policy decision, response class, cost signal, and retry count.

The difference is easiest to see in the request path itself.

‍

This contract is compatible with several implementation patterns. A gateway may enforce it. A workflow engine may enforce it. An MCP intermediary may enforce it. The architecture matters less than placement. The component must sit where it can observe and refuse the operation before the consequential work occurs.

‍

Hidden waste is an execution problem

The economics are not hypothetical. In a published analysis of defects across seven MCP servers, Databricks reported estimated annual waste from retries and failures of $499,000 in tokens and roughly 12,000 hours of agent wait time. Its estimate rose to $1.2 million after it included lost productivity. Those figures are specific to that analysis, not a general benchmark. Their value lies in showing the failure mode.

The system can continue to produce completed tasks while wasting work. An agent may retry until an unreliable service responds. It may choose a workaround that creates more calls. A model can spend tokens reasoning around an interface defect that should have been surfaced as an explicit operational failure. Completion alone therefore says little about the efficiency of the path.

Aggregate token totals can conceal that pattern. A rising total may indicate useful volume, repeated failure, or a mixture of both. Separating them needs request-level evidence. The source analysis traced tool invocations, errors, latency, and execution context closely enough to identify defects that a broad adoption metric would not explain.

That observation also clarifies the purpose of AgentOps as a production discipline. It is not simply an observability layer added after deployment. Databricks describes AgentOps as a production discipline that includes evaluation, monitoring, governance, and cost management. The relevant question is whether those signals can change the live request path, not merely report on it later.

Spend control should therefore be designed as a refusal capability. The runtime needs a defined response when an agent exceeds its allocation, repeats a failed operation, or requests a tool outside its declared purpose. The response may be a stop, a cheaper fallback, or an approval request. What it cannot be is silent continuation with a chart produced afterwards.

‍

Can grounded web agents act without centralising data?

Yes. Grounded web agents can operate against governed sources without first copying all data into a central platform, provided the execution boundary can preserve authority, policy, and evidence at the point of access.

Centralisation can make governance convenient because it concentrates identity, metadata, and audit records. Convenience is not the same as a control requirement. In many settings, copying data creates a new retention, access, and synchronization problem. The more useful question is whether a request can arrive at each source with a verifiable principal, a bounded purpose, and a policy decision that the source or an intermediary can enforce.

This is the reasoning behind a Sovereign Decision Fabric: an execution architecture that keeps decisions, authority, and evidence close to the systems where data and actions already reside. The term does not promise that every source behaves identically. It states where the governing boundary should be evaluated.

Distributed execution raises a harder tracing requirement. A search tool, a model service, a policy engine, and a record system may each generate separate logs. Without a shared context, those events describe fragments rather than an action. OpenTelemetry context propagation provides the standard mechanism for carrying trace and span identifiers across service and network boundaries, allowing signals to be correlated into causal information.

The trace should carry more than technical timing. For agent work, it should also connect the policy result to the delegation and the tool request. That is the difference between knowing that an API returned an error and knowing whether the runtime correctly rejected an unauthorised call, stopped a retry sequence, or allowed a request that later deserves review.

‍

Denial is only one form of governance

Governance is often described as a series of prohibitions. That framing misses its practical value. The best control boundary does not force every uncertain task into a binary choice between unrestricted autonomy and no automation. It separates evidence gathering from consequential action.

An agent can read approved records, compare alternatives, identify missing information, and prepare a proposed change without holding the authority to execute that change. A policy gate can then evaluate the proposed operation against the current scope and require an approval checkpoint where the action crosses a financial, operational, or regulatory threshold. The agent remains useful. Its authority remains bounded.

This division follows a familiar safety principle. Reversible actions can carry a broader tolerance for automation because their effects can be inspected and discarded. Irreversible or externally visible actions need a narrower tolerance because their effects cannot be treated as another draft. The threshold must be expressed as policy, not improvised by the model after it sees the result.

The NIST AI RMF playbook's guidance on managing risk supports this posture by linking treatment choices to risk tolerance, monitoring, and documentation. For an agent, that implies explicit handling for refusal, escalation, and review. A system that merely logs a dangerous action has documented a failure. A system that can hold the action pending review has governed it.

There is a real cost. Checkpoints slow some workflows. Fine-grained credentials require care. Traces can expose sensitive context if their fields are not designed with protection and retention in mind. A policy gate can also block useful work when the rule is crude. These are design obligations, not reasons to leave the boundary empty. The appropriate response is to make controls specific enough to support legitimate work and visible enough to be challenged.

‍

Bounded autonomy is the actual choice

Unlimited convenience is not the relevant alternative. The practical choice is between autonomy with stated limits and autonomy whose limits appear only after a bill, an incident, or a disputed action. A grounded web agent is fit for work when the organisation can say, before execution, what information it may access, what tools it may call, how much work it may consume, and which operations require another decision.

That standard is stricter than a prompt checklist and less restrictive than a blanket ban. It recognises that an agent can be trusted with read-only research while not being trusted with an update. It also recognises that trust may expire when the cost, target, or effect of an operation changes. The runtime should make those transitions explicit.

This also changes how a system should be reviewed. The review should follow an actual tool path from request to outcome, including denials and timeouts, rather than a diagram of intended components. It should ask what happens when a provider returns an ambiguous error, a budget reaches its limit halfway through a task, or a permitted read produces a proposed write. A design that has no clear answer has left its most important decisions to runtime improvisation.

Before allowing a web agent into a consequential path, defend these five answers: Who delegated this authority? What budget applies to this request? Which tool methods are permitted? What event causes the system to stop or seek approval? Can the full chain be reconstructed without guessing from disconnected logs?

If those answers reside only in prompt text, the system has not yet chosen bounded autonomy. It has chosen hope as a control mechanism. The policy question is simple: should an agent be allowed to act because it produced a relevant answer, or only after the runtime can prove that the action was within authority?