The Agent Stack Is Filling In. The Judgment Layer Is Still an Open Problem

Cloudflare has open-sourced Cloudflare OS, its internal platform for AI agents, which separates organizational context, skills, MCP-connected tools, isolated environments, and gatekeepers. However, a recent paper highlights a concurrency problem where agents can make decisions based on stale state, leading to violations. This points to an architectural shift where the industry is improving agent access and execution, but the judgment layer—deciding whether an action is justified under organizational rules—remains an open problem.

Over the last few days I have been looking at several developments around enterprise AI agents that initially seemed unrelated. Cloudflare open-sourced https://blog.cloudflare.com/cloudflare-os/ its internal agent workspace platform. Researchers published work https://arxiv.org/html/2608.02764v1 on what happens when an agent authorizes an action using state that changes before execution. Enterprise AI leaders are starting to talk https://www.reuters.com/commentary/breakingviews/corporate-ai-is-still-chasing-theoretical-benefits-2026-08-07/ less about how many agents they can deploy and more about whether those agents are producing measurable value. There is also growing infrastructure around agent identity, tool access, observability, security, and runtime isolation. Taken separately, these are different stories. Together, I think they point to a larger architectural shift. The ecosystem is getting much better at answering: What can this agent access and execute? But another question remains less well defined: Given the available evidence, what should this organization actually decide? Those are not the same question. Cloudflare recently open-sourced Cloudflare OS, the platform it uses internally for AI agents. The architecture is interesting because the model is not treated as the entire system. There is organizational context. There are skills. There are MCP-connected tools. There are isolated environments in which agents operate. And there are Gatekeepers that help control what an agent can do. This seems like a reasonable direction for enterprise agents. As agents move closer to production systems, companies need much more than an LLM and a collection of tools. But imagine using this architecture for vendor onboarding. An employee asks an agent to onboard Acme Corp. The employee has permission to make the request. The agent has permission to call the vendor-management API. The request passes the security gateway. Does that mean the vendor should be onboarded? Not necessarily. The decision might depend on facts such as sanctions screening, tax documentation, annual contract value, country of registration, personal-data handling, or an internal risk score. There may also be exceptions. A sanctions match could be a hard stop. A high contract value might require committee review. Missing evidence might mean that neither approval nor rejection is correct yet. The authorization layer can answer: Is this agent allowed to perform this operation? The business still needs an answer to: Under our rules, is this operation justified? That is the boundary I find interesting. A recent paper on stateful governance for concurrent agent systems describes another version of the problem. Suppose two agents share the same purchasing budget. Agent A checks the available budget and determines that a $30,000 purchase is allowed. Before Agent A executes the purchase, Agent B spends $40,000. The state has changed. Agent A may have made the correct decision using the facts it had at evaluation time. Executing that decision later can still violate the organization's rules. This is easy to miss when we think about agent governance only as a policy check performed immediately before a tool call. For deterministic judgment systems, I usually describe one useful property as: same facts + same judgment definition → same disposition That gives us reproducibility. But the concurrency problem suggests another requirement: the facts that justified the disposition must still be valid when the action commits Those are different guarantees. A production workflow might therefore need to look more like this: Acquire facts ↓ Evaluate judgment ↓ Record disposition + relevant state ↓ Validate state / re-evaluate if necessary ↓ Execute This is an area I want to experiment with because it sits directly between decision semantics and runtime enforcement. Another signal comes from enterprise adoption. Organizations are starting to discover that deploying agents is easier than understanding the full operational footprint afterward. One recent report described a company where the CIO believed roughly 40 agents were operating internally. An audit reportedly found more than 400. That number caught my attention because it changes the governance problem. If you have three experimental agents, reviewing their prompts and workflows manually may be perfectly reasonable. If you have hundreds of agents making decisions across finance, procurement, customer operations, HR, and IT, it becomes much harder to answer basic questions consistently. Which decisions are these agents allowed to make? What evidence must be available? Which exceptions apply? When must the agent abstain or escalate? Who approved the decision logic? Which version was active when a particular action happened? These questions do not disappear because the underlying model becomes more capable. Some of them become more important. This is the problem I am exploring with the open-source Judgment Pack Specification. A Judgment Pack represents organizational decision logic as a separate artifact. The goal is not to replace the agent. The agent can still gather information, interact with users, use tools, and reason where reasoning is useful. The difference is that the criteria governing a consequential business decision do not have to live entirely inside the agent's prompt. For a vendor-onboarding decision, for example, a pack might define the required evidence, thresholds, exceptions, treatment of missing facts, and possible outcomes. The agent supplies facts. The evaluator applies the reviewed judgment definition. The result can then be used by another layer responsible for execution. Conceptually: Agent ↓ Evidence acquisition ↓ Judgment Pack ↓ Disposition + evidence ↓ Gateway / policy enforcement ↓ Business system I think this distinction becomes clearer as the rest of the agent stack matures. MCP is solving connectivity. Agent platforms are solving orchestration and execution. Skills are helping models use systems correctly. Security layers are controlling identity and access. Observability platforms are helping companies understand what agents actually did. None of those necessarily owns the organization's definition of a correct business decision. A deterministic lookup does not need one. A simple permission check probably belongs in an authorization system. A low-risk conversational suggestion may be perfectly appropriate to leave to the model. The interesting cases are decisions where the organization expects consistent treatment of evidence, rules, exceptions, uncertainty, and escalation. That is where putting the judgment into a reviewable artifact starts to become useful. I am particularly interested in testing this boundary against real agent platforms rather than defining it only on paper. Cloudflare OS looks like one possible integration environment. Concurrent state changes are another area I want to test. And the larger question is whether this separation still makes sense when applied to real production workflows rather than clean examples. That is the part I am trying to learn now. If you are building enterprise agents and have a workflow where the difficult part is not tool access but deciding whether the action is justified , I would be interested in hearing what that decision looks like.