Enterprises like their agent platforms, and still refuse to bet on just one
Enterprise teams give their orchestration platforms an overall satisfaction score of 4.17 out of 5, yet the median enterprise runs three platforms at once. That tension matters for architecture planning because satisfaction with a product does not determine whether an enterprise will make it the sole place where agents are controlled. VB Pulse/VB Intelligence’s ongoing analysis of 107 enterprises shows that multiple orchestration tools are already the norm.
| Number of orchestration tools used | Share of enterprises |
|---|---|
| At least two | 85% |
| Three | 64% |
| One | 15% |
The people making those choices include software and machine learning engineers, product and program managers, and data/AI/analytics VPs and directors. Their ratings show where the experience is weaker even though commercial orchestration remains heavily used.
| Platform rating | Score out of 5 |
|---|---|
| Overall satisfaction | 4.17 |
| Ease of implementation | 3.91 |
| Value for money | 3.63 |
Those ratings matter because favorable views of current platforms coexist with plans to keep changing the stack. VB Pulse/VB Intelligence found that more than two-thirds of respondents expect to change platforms within a year, with the timing spread across the next 12 months.
| Expected timing of platform change | Share |
|---|---|
| Within the next three months or sooner | 15% |
| Within three to six months | 24% |
| Within six to 12 months | 28% |
Those near-term plans turn platform plurality into an architecture issue. Enterprises commonly combine commercial orchestration products, so they need to decide how control will work across the resulting stack. As products change, the question becomes where that control should reside.
Plurality is becoming an architectural choice
Current stacks show how much overlap already exists. VB Pulse/VB Intelligence found Microsoft AI Foundry/Copilot Studio and OpenAI’s Agents SDK each in more than two-thirds of the enterprises studied, while Anthropic’s Claude Platform also has substantial deployment. Custom in-house orchestration adds enterprise-owned components alongside vendor systems that remain in use.
| Component in current stacks | Share |
|---|---|
| Microsoft AI Foundry/Copilot Studio | 70% |
| OpenAI’s Agents SDK | 68% |
| Anthropic’s Claude Platform | 47% |
| Custom in-house orchestration | 22% |
Those stacks also include Google’s Enterprise Agent Platform, LangChain/LangGraph, Salesforce Agentforce, Amazon Bedrock, and LlamaIndex. Their coexistence matters because orchestration determines how models, tools and agents connect and how execution is managed. Once several orchestration systems participate, the enterprise has to decide which controls belong inside each platform and which need to work across them.
That decision creates a role for a control plane, the layer that governs execution across the systems involved. A hybrid control plane can span several platforms, models and agents while adding custom controls where the enterprise needs them. Separating selected responsibilities from an individual workflow platform lets the organization keep those responsibilities stable as its stack changes.
VB Pulse/VB Intelligence’s expectations for the end of 2026 make that direction more explicit. A majority, 53%, expect their primary control plane to be hybrid, while smaller groups expect provider-managed, custom, or externally abstracted arrangements.
| Expected primary control plane by end of 2026 | Share |
|---|---|
| Hybrid | 53% |
| Provider-managed | 14% |
| Custom in-house | 13% |
| External platform abstracted from model providers | 11% |
The range of expected arrangements shows that enterprises are actively choosing where orchestration authority should sit. A provider-managed control plane appeals to some organizations, while others plan to own theirs or use an external layer separated from model providers. Hybrid is the largest expected arrangement, but several control models remain in active use.
Current evaluations widen that choice because enterprises are considering new options while several products already overlap in deployed stacks. Consideration can lead to an addition, the replacement of one component, or a broader architecture change.
| Platform or approach under evaluation | Share |
|---|---|
| Claude Agent SDK | 43% |
| Google’s Enterprise Agent Platform | Roughly one-third |
| Custom in-house orchestration | 31% |
| OpenAI options | 25% |
The custom component makes the boundary question especially concrete. Enterprises that add in-house orchestration to vendor platforms take ownership of selected responsibilities while continuing to rely on commercial products. For an engineering or platform team, the practical question is which functions need to remain stable when the underlying model, orchestration service or vendor changes.
A project in mind?
Schedule a 30-minute meeting with us.
Senior experts helping you move faster across product, engineering, cloud & AI.
The strongest reason to keep control portable is what enterprises optimize for
That boundary question leads directly to buying criteria because VB Pulse/VB Intelligence found that buyers give the greatest weight to flexibility. Security and permissions, production reliability, and control over agent execution follow, while model gravity means native alignment with a leading base model.
| Buying consideration | Share |
|---|---|
| Flexibility | 29% |
| Security and permissions | 17% |
| Production reliability | 15% |
| Control over agent execution | 15% |
| Model gravity | 10% |
| Ease of development | 8% |
| Total cost of ownership | 4% |
| Latency and memory performance | 2% |
Those priorities become more specific when teams identify problems during platform selection. Security and permissioning limitations lead the concerns, followed by vendor lock-in, limited visibility and observability, and model or tool inflexibility.
| Platform-selection concern | Share |
|---|---|
| Security and permissioning limitations | 37% |
| Vendor lock-in | 23% |
| Limited visibility and observability | 22% |
| Model or tool inflexibility | 16% |
Observability means being able to inspect what agents are doing as they execute, so teams can diagnose behavior or intervene. That capability connects selection concerns to the architecture question because enterprise policies for security, permissions and execution visibility may need to survive when workloads move between platforms. Portable controls give teams a way to preserve those policies across a changing stack.
VB Pulse/VB Intelligence found spending shifting toward the same requirements. Monitoring and debugging now take 31% of orchestration spending, security and permissions enforcement take 30%, and workflow tooling takes 19%. In VentureBeat’s prior wave one month earlier, workflow tooling had led orchestration spending outright. The shift shows investment moving from connecting workflow steps toward seeing and constraining what happens as those steps execute.
Optimization priorities show where teams are applying that investment. VB Pulse/VB Intelligence found task-completion reliability leads at 30%, multi-step workflow management at 27%, developer productivity at 23%, operational stability at 13%, and end-user experience at 7%. A successful agent workflow currently depends heavily on getting a multi-step job through to completion reliably. Development simplicity and user experience may gain weight as these systems settle, but today’s engineering effort is concentrated deeper in execution.
Those choices turn platform plurality into an execution problem as well as a purchasing choice. Teams have to enforce permissions, inspect execution and keep workflows reliable when several platforms participate. A well-rated platform can remain in the stack while the enterprise keeps selected controls portable across the wider system.
Runaway-agent spending turns architectural control into an operational requirement
Execution control becomes immediate when an agent can spend money while it runs. VB Pulse/VB Intelligence found that one in five enterprises cannot stop a runaway agent’s spending in real time. Because an agent can keep consuming tokens and invoking models before a human reviews the resulting cost, fiscal safeguards need to operate in the execution path and interrupt that behavior.
Enterprises use several mechanisms to make that intervention possible. Built-in budget caps or throttling let a platform impose a ceiling or slow activity, while custom gateway or proxy middleware can intercept an agent as requests pass through it. Dynamic routing can send heavy or expensive work to lower-cost models as conditions change, making model choice part of live fiscal control.
| Agent-spending control | Share |
|---|---|
| Native platform budget caps or throttling | 30% |
| Custom gateway/proxy middleware | 25% |
| Dynamic routing to lower-cost models | 25% |
| Reactive monitoring/post-hoc logs only | 21% |
Reactive monitoring defines the remaining control gap. Teams relying solely on post-hoc logs can inspect spending after execution, but they have no real-time kill switch to stop costs while they accumulate. That limitation makes fiscal control an architecture requirement because observation after execution cannot perform the same function as intervention during execution.
The control methods also separate purchase economics from runtime economics. Total cost of ownership ranks at 4% among buying considerations, while enterprises are still putting engineering effort into caps, throttles, gateways, routing and monitoring. Runtime spending can change dynamically as an agent executes, so it calls for controls that can respond on the same timescale.
Native safeguards remain important within that broader design. Built-in budget limits lead the individual spending-control methods at 30%, showing that enterprises use provider functionality alongside custom layers. A native limit can protect execution within its platform, while gateways, routing and other controls can cover boundaries the enterprise has chosen to manage itself.
Company size does little to remove the intervention problem. VB Pulse/VB Intelligence found that among enterprises with at least 10,000 employees, 18% still have only reactive fiscal control, compared with 23% of smaller organizations. More staff and organizational resources do not by themselves provide the ability to interrupt agent spending in real time, so large enterprises still have to design and instrument that capability explicitly.
The spending mechanisms show that these controls are already attached to running workloads. Teams are building proxy middleware specifically to intercept runaway agents, directing expensive work toward cheaper models, and reviewing post-hoc logs where live controls have yet to be implemented. Fiscal governance therefore belongs in the execution architecture, where it can act while an agent is consuming resources.
Enterprises are building the control plane ahead of agent autonomy
Those execution controls are arriving while advanced agent autonomy remains uncommon. Respondents describe deployments at several levels, from chatbots and basic assistants through true orchestration, complex multi-agent pipelines, and systems that are advanced and largely autonomous.
| Reported deployment maturity | Share |
|---|---|
| 76% to 100% of systems are advanced and largely autonomous | 2% |
| 51% to 75% are complex multi-agent pipelines | 14% |
| 26% to 50% have reached true orchestration | 47% |
| 1% to 25% are true orchestration, with most deployments still basic assistants | 35% |
| Deploying only chatbots | 3% |
That distribution gives the term “agent” limited value as a measure of operational maturity because systems carrying the label can perform very different amounts of independent multi-step work. The progression runs from chatbots and basic assistants through systems that genuinely orchestrate work, then complex multi-agent pipelines and largely autonomous systems. Control-plane requirements consequently have to reflect what deployed systems actually do.
VB’s June Pulse survey found the same maturity gap from another direction. Some 71% said a quarter or fewer of their deployed “agents” could autonomously complete multi-step work, and only one-tenth said they had deployed agents at scale. Those findings place current control-plane investment ahead of widespread high autonomy, as teams prepare infrastructure for greater execution complexity and broader deployment.
That timing changes how teams should judge near-term infrastructure choices. Cross-platform visibility, permissions and fiscal intervention can exceed what assistant-heavy deployments currently demand, but those foundations become harder to change after autonomous workflows spread across several products. The 53% expecting hybrid primary control planes by the end of 2026 shows enterprises putting those boundaries in place while agent maturity is still developing.
Those boundaries determine which responsibilities move with an orchestration platform and which remain enforceable across platform changes. Some responsibilities can live inside a provider, others can be enforced through custom infrastructure, and still others can span providers through a hybrid control plane. High satisfaction with commercial products can coexist with independent visibility, permissions, portability, execution controls and real-time spending safeguards, while widespread use of native fiscal controls keeps vendor-managed functions as an important layer.
For teams planning the next platform change, that division of responsibility is the durable architecture decision. The required controls have to remain enforceable when the product or model beneath them changes, which makes their placement part of platform design itself.
Key takeaways for leaders
- Design for platform plurality: The median enterprise already runs three orchestration platforms, and more than two-thirds expect a platform change within a year. Architecture teams can keep critical controls portable so vendor or model changes do not force a governance redesign.
- Define the control-plane boundary: Hybrid control planes are the leading expected model for the end of 2026, at 53%. Platform teams can decide which permissions, visibility and execution controls belong inside provider platforms and which need to span the stack.
- Prioritize portable execution controls: Flexibility leads buying criteria at 29%, while security, vendor lock-in and observability feature prominently in platform concerns. Enterprises can preserve these capabilities across changing platforms through shared security, monitoring and execution policies.
- Put fiscal safeguards in the execution path: One in five enterprises cannot stop runaway agent spending in real time. Engineering and FinOps teams can use budget caps, throttling, gateway controls and dynamic model routing to intervene while costs accumulate.
- Build controls ahead of greater autonomy: Only 2% report that 76% to 100% of their systems are advanced and largely autonomous, while most deployments remain at earlier maturity stages. Enterprises can establish cross-platform governance now before autonomous workflows become more complex and widespread.
A project in mind?
Schedule a 30-minute meeting with us.
Senior experts helping you move faster across product, engineering, cloud & AI.


