Salesforce Validated the Execution Layer. Its Perimeter Proves Why Enforcement Must Be Neutral.

Salesforce recently launched Agentforce Operations. The framing in VentureBeat is sharp, and worth quoting back:
"Workflow execution control planes that impose deterministic structure on processes agents are expected to run."
Translation: enterprise AI teams aren't failing because models can't reason. They're failing because the layer underneath the agent was never built for agents.
This is one of the clearest category signals so far in 2026. Not because of the product. Because of what it admits.
Three concrete examples of what's missing
Before unpacking the announcement, three situations every Head of AI is already living through:
- A finance agent (running on Anthropic's API) proposes to release an underwriting decision that violates a freshly-updated capital adequacy rule. Nothing in the workflow knows the rule changed yesterday.
- A support agent (running inside Salesforce) proposes a $14,000 refund to a customer whose account history breaches the merchant's exception policy. The workflow has no reason to challenge it. The action looks routine.
- An engineering agent (running in Cursor with Claude) proposes a destructive migration against a production database during business hours. The agent is doing exactly what the workflow asked.
In each case, the orchestration ran correctly. The agent did its job. What was missing was something operating outside the workflow: an infrastructure that evaluates the proposed action itself, runtime-agnostic, and blocks or allows it before it fires.
That layer is the subject of this post.
Reasoning is no longer the primary bottleneck
Three years ago, the conversation was "can agents reason well enough?" For many enterprise use cases, reasoning is no longer the primary bottleneck.
Two years ago, "can we trust them with real systems?" Still being answered, but the direction is clear.
Today, the conversation Salesforce just made official is "what infrastructure enforces the decisions agents make before they hit production?"
That's the category. And it's about to split.
Four terms, four jobs
The space has accumulated overlapping vocabulary. Let me fix the terms for the rest of this post:
- Harness: the scaffolding that equips an agent to act, including tools, memory, context, and framework. Upstream of the decision.
- Orchestration: deciding which agent does what in a process. Workflow logic.
- Execution control plane: a runtime that imposes deterministic structure on the orchestration. Agentforce Operations sits here.
- Decision runtime: the infrastructure that intercepts proposed actions from any agent, evaluates them against deterministic rules, regulatory constraints, and contextual policies, and blocks, allows, routes to human review, or proposes an alternative, before the action fires. Every decision produces an auditable record. Runtime-agnostic by construction.
Mental model in one line: Agent β proposes action β Decision runtime validates, blocks, or routes β Tool / system executes.
Agentforce Operations is an execution control plane. It is not a decision runtime. The distinction is not academic. It is the entire thesis of this post.
Why enforcement must sit outside the workflow
This is the technical and political core of the argument.
If pre-execution enforcement lives inside the workflow that produced the action, three things break:
- The agent and its arbiter share assumptions. Both were configured by the same team, against the same context, with the same blind spots. The arbiter inherits the failure modes of the workflow it lives inside.
- Cross-vendor decisions cannot be evaluated. When the same enterprise runs agents from five different vendors, an enforcement layer embedded inside one of them cannot arbitrate the others.
- Audit independence collapses. Regulators and risk functions need a system of record for agent decisions that is not owned by the team operating the agents. Enforcement inside the workflow fails this test by construction.
Enforcement must be a separate plane. Not a feature of the workflow. A control point the workflow passes through.
The thesis: one category, two archetypes
The agent execution space will split in two, and every enterprise will need both.
Workflow-bound execution control planes sit inside a vendor's stack. They orchestrate agents through pre-defined steps. Strong fit for processes that live entirely inside one perimeter. Agentforce Operations is the canonical example, and a strong one.
Runtime-agnostic neutral enforcement layers sit between any agent and any production system. They validate, block, or route proposed actions, regardless of which framework, model, or vendor produced them. Rippletide is building in this category, alongside the work we describe in Context without enforcement is not infrastructure.
These solve adjacent but different problems. No vendor-bound orchestration layer can consistently arbitrate decisions made by competing vendors' agents, not because of capability, but because of position.
The proof from history
Two analogies are sufficient.
Observability split between bundled monitoring (AWS CloudWatch, Azure Monitor) and horizontal observability (Datadog, Grafana). Multi-cloud forced the horizontal layer to win the strategic budget.
Identity split between platform-native IAM and cross-vendor identity providers (Okta). Microsoft, despite owning Active Directory and the largest enterprise software footprint in the world, never won the cross-cloud identity layer. Not because they lacked the technology. Because of where they sit in the buyer's mental model.
The pattern repeats: vertical layers usually win adoption first; horizontal layers win governance later. Adoption is driven by speed and bundled value. Governance is driven by neutrality and accountability. They are different buying motions, and they tend to land in different infrastructure.
The proof from the present
The enterprise reality of 2026 is already multi-vendor. Gartner forecasts that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025 (Gartner, August 2025). Those agents will not all run on the same vendor.
Sales runs on one stack. Engineering runs Claude Code or Cursor. Support runs on Salesforce. Finance pilots something on Anthropic's API. Procurement just bought a vertical agent from a startup nobody had heard of six months ago.
Vertical execution control planes are useful within their vendor and accessible across vendors via APIs and connectors, but they are insufficient as the strategic governance infrastructure for an enterprise's full agent estate. Each vendor optimizes for its own perimeter. Few will be accepted as the arbiter of decisions made by competing vendors' agents.
The Salesforce counter-argument, taken seriously
Could Salesforce horizontalize via AgentExchange, MCP support, Slack, and Data 360? It is the strongest version of the case against this post's thesis.
The vectors are real. AgentExchange has 30+ partners. Slack is becoming the universal interaction surface. MCP support means external agents can plug in. Data 360 strengthens Salesforce's claim to the data plane.
Three reasons the bet against horizontalization is defensible:
-
Concentration of decision authority. Many serious enterprises will hesitate to let Salesforce arbitrate whether agents from SAP, ServiceNow, Databricks, or GitHub can execute critical actions. Risk and compliance functions tend to flag this kind of consolidation early in procurement.
-
Structural conflict of interest. Salesforce sells Salesforce agents. Asking a vendor to enforce decisions made by competing vendors' agents creates a conflict of interest that procurement teams will identify in the first review cycle.
-
Historical pattern. No application vendor has cleanly become the neutral horizontal governance layer for the rest of the enterprise stack. Microsoft tried with Active Directory and lost cross-cloud identity to Okta. The pattern is consistent enough to be the base case.
The bet, and it is a bet, is that institutional neutrality is structurally difficult for vendors with billion-dollar app businesses. History has favored that bet before. It could break this time. Anyone working in this category needs to be honest about that.
This does not diminish Agentforce Operations. It positions it. Agentforce Operations becomes the vertical proof point: when you build the execution layer for agents inside your own perimeter, this is what it should look like. The neutral version sits next to it, not against it.
What this means for the buyer
The neutral enforcement layer is bought by a different person than the orchestration layer.
Today, the most active buyer is the Head of AI or Chief AI Officer, the role that owns agent strategy across functions and is accountable when agents misfire. Tomorrow, as the category matures, three roles will be involved:
- CIO (budget owner): platform consolidation, total cost of ownership.
- Head of AI / CAIO (daily user): runtime coverage, framework support, integration breadth.
- CISO / Head of Risk (risk owner): auditability, provability of pre-execution control, regulatory defensibility.
Budget owner β daily user β risk owner. A serious pre-execution control layer must speak all three languages. That is harder than it sounds, and it is the reason this category will mature slowly even as urgency grows.
The hardest layer to replace
Once a neutral enforcement layer is embedded in an enterprise's governance, audit trails, and execution policies, replacing it requires re-validating every agent against a new arbiter, re-auditing every decision history, and re-aligning every compliance artifact.
Models will be swapped. Frameworks will be replaced. Workflow tools will rise and fall. The infrastructure that decides what agents can actually do, once it is the system of record for those decisions, is the hardest piece to remove without breaking everything above it.
That property is what makes this archetype strategic. It is also what makes it slow to adopt. Buyers know they are picking a long-term arbiter, and they will deliberate.
What comes next
Salesforce just confirmed the category exists. The same announcement, read carefully, also explains why the neutral version must exist alongside it.
The next 24 months will answer who occupies the neutral enforcement layer, and whether application vendors find a credible path to horizontalize despite the structural headwinds. Both questions are open. Both matter.
The execution layer for agents is no longer a question of whether. It is a question of which one, where, bought by whom, and accountable to whom.
The workflow decides what should happen next. The decision runtime decides whether it is allowed to happen at all. Enterprises that recognize the difference early will architect for both.
Disclosure: Rippletide is building in the runtime-agnostic enforcement category. This piece reflects how we read the market today. Every claim about competitor positioning is based on publicly available product information. We may be wrong on timing, and we welcome corrections from any vendor named.
Further reading on this blog
Frequently Asked Questions
An execution control plane (such as Salesforce Agentforce Operations) orchestrates agents through pre-defined steps inside a vendor's perimeter. A decision runtime sits outside any single workflow, intercepts proposed actions from any agent, validates them against deterministic rules and policies, and blocks, allows, or routes them to human review before they fire. The execution control plane decides what should happen next. The decision runtime decides whether it is allowed to happen at all.
Agentforce Operations confirms enterprises need a deterministic layer underneath their agents. But by living inside Salesforce's perimeter, it cannot arbitrate decisions made by agents built on Anthropic, Cursor, ServiceNow, Databricks, or any other vendor. The same announcement that admits the layer is necessary is the announcement that admits a neutral, runtime-agnostic version must exist alongside it.
Three reasons. First, when the agent and its arbiter share assumptions, the arbiter inherits the failure modes of the workflow. Second, an enforcement layer embedded inside one vendor cannot arbitrate agents from competing vendors. Third, regulators and risk functions need a system of record for agent decisions that is not owned by the team operating the agents. Enforcement inside the workflow fails this test by construction.
Three roles, increasingly involved together. The CIO owns budget and platform consolidation. The Head of AI or Chief AI Officer is the daily user, focused on runtime coverage, framework support, and integration breadth. The CISO or Head of Risk owns auditability, provability of pre-execution control, and regulatory defensibility. A serious pre-execution control layer must speak all three languages.
Rippletide is building in the runtime-agnostic enforcement category. The Rippletide Decision Context Graph intercepts proposed actions from any agent, evaluates them deterministically against the operative rules of the organization, and produces a verifiable record of every decision before any action reaches production systems.