9 min read Agent orchestration

A monthly cap does not stop an agent stuck in a loop

A monthly cap does not stop an agent stuck in a loop

Among 107 enterprises of 100 employees or more surveyed in July 2026 by VentureBeat Pulse Research, 85% run at least two agent orchestration platforms, 64% run at least three, and the average sits at 3.1 per organization. In the same survey, 21% say they track agent spend only through after-the-fact logs, with no real-time way to interrupt a run that has gone into a loop. Another 30% rely on the caps and limits built into their primary platform.

Those two populations are almost always added together to produce a coverage figure, 51% with no internally controlled stop mechanism, and the addition misses the point. The 30% relying on native caps do not have a weakened version of the stop button. They are using an instrument built for something else. A vendor spend cap is a monthly billing control, scoped to an organization, whose enforcement the vendor itself explicitly describes as non-instant. An agent loop is an event lasting minutes, on one service, inside one project. The two never meet.

The July 11 article on token budgeting for production agents treated spend control as an optimization problem. The July 23 article on governing AI agent risk treated it as security policy. This subject is different from both: it is neither the amount nor the rule, it is the mechanism that executes the stop, and the fact that it has to work across three platforms nobody chose to have at once.

A long segmented bar standing for a month sits above a tiny orange bar standing for an agent loop
The vendor cap and the agent loop operate on neither the same timescale nor the same scope.

What a vendor cap actually stops

The public documentation of the two main API vendors is explicit, and it is worth reading as a contract rather than as a settings page.

At OpenAI, a hard spend cap is set at the organization or project level, over a monthly period. When it is reached, the affected requests return a 429 error and the block holds until the monthly cycle resets, unless an administrator raises or removes the limit. The documentation warns that these caps can interrupt production traffic, and states that enforcement is not instant: the platform may process some additional usage while the limit state propagates, so recorded spend can exceed the configured amount.

At Anthropic, the spend limits API applies per organization member, resolved hierarchically from an individual override, then the group, then the seat level, then the organizational default. The only supported period is the month, resetting at midnight UTC on the first. The feature is restricted to Claude Enterprise organizations and is not available on Claude Platform organizations. One detail from the documentation deserves quoting as is: current spend can read zero when the value is temporarily unavailable, and the page asks that it be treated as informational, not transactional.

The vocabulary of control

Control plane: the layer that decides and administers, as opposed to the execution plane that does the work. For agents, this is where the inventory, the permissions, the budgets and the stop order live.

Deterministic stop mechanism: a mechanism whose activation always produces the same effect, within a bounded and known delay, without depending on a third party's cooperation or on asynchronous propagation.

Spend cap: a billing limit evaluated over a period, usually the calendar month, at the scale of an organization, a project or a user.

Gateway: an intermediary you operate, through which every outbound call to model vendors passes, and which can therefore count, refuse and cut.

Neither mechanism is broken. Both answer correctly the question they were asked, which is how to bound a monthly invoice. Neither answers the question an engineering organization believes it is asking them, which is how to stop one identified agent, in one identified run, before it consumes a quarter's budget. The granularity does not match, the time window does not match, and the side effect of an organizational cap being reached is that all traffic from all teams stops, not the traffic of the offending agent.

Why the plurality of orchestrators makes the problem structural

The July survey describes an orchestration layer that has become plural by construction. Microsoft AI Foundry and Copilot Studio appear in 70% of stacks, OpenAI's Agents SDK and Responses API in 68%, Anthropic's Claude platform in 47%, Google's agent platform in 32%. Those shares overlap rather than split a market: the median is three platforms and one organization in six runs five or more. Asked to name their primary platform, 46 respondents out of 107 checked several answers to a question that expected one.

This plurality is not an integration accident, it is the result of a deliberate preference. Flexibility across models and tools is the top buying criterion at 29%, nearly three times the share citing native alignment with a frontier model, at 10%. Enterprises buy the orchestration environment that does not commit them. They get exactly what they asked for, and with it a visibility and permissions problem that follows mechanically from the number of control planes in play.

The most instructive cross-tabulation in the survey is the maturity one. Enterprises reporting that a quarter or fewer of their agents do genuine multi-step work run 2.8 platforms on average; those reporting between a quarter and a half run 3.5. Organization size, by contrast, makes no difference to that maturity. In other words, it is not the least mature portfolios that accumulate orchestrators, it is the most advanced ones. The number of platforms is not a debt to pay down before building the control layer, it is the condition under which that layer will have to work.

Four ways to control agent spend compared by time to effect, the gateway being the only immediate one
Agent spend can be controlled four ways, and only one of the four assumes no propagation delay.

The limits of this sample have to be stated, because they change the scope of the reasoning. It is a single wave from July 2026, on a self-selected panel of 107 respondents, of whom 53% come from technology and software and more than half work in organizations of 10,000 employees or more. These figures describe a population already engaged with the subject, not the market. They read as a direction, not as a measurement.

Enterprises built what was easy

A second wave of the same survey, published the same day and covering 116 security-side respondents, gives the finding its sharpest form. In July, 65% of enterprises enforced permissions on agents at runtime, but only 18% isolated their most sensitive agents, and 8% did both. Forty-nine percent had given each agent its own identity, up from 32% a month earlier, the steepest monthly gain in the series; of those 57 enterprises, only 11 also isolated.

The comparison with forecasts is the real result. In April and May, 109 enterprises had been asked how they expected to control agent behavior by the end of 2026: 30% cited runtime permission enforcement, 14% sandboxed execution. By July, permission enforcement had reached 65%, more than double the forecast, while isolation stood at 18%, roughly what had been predicted. Enterprises built what was easy twice as fast as expected, and what was hard at the expected pace. The two are not comparable in cost: a permission rule is written and deployed, a containment mechanism is designed, operated and tested.

The price of that trade-off shows up in incidents. Fifty-three enterprises enforced permissions without isolating; 31 of them had already had an agent-related security incident or near-miss, or 58%, five points above the sample average. The population living precisely in that gap is the one that gets hit most often.

There is a contradiction worth naming, and it sits at the heart of the subject. Seventy-eight percent of enterprises want to keep the control plane at least partly outside the vendor, and the reason they give is not commercial lock-in, cited by 23%, but the vendor's security and permission limits, cited by 37%. At the same time, 92% of those naming a primary security layer name one belonging to an infrastructure or model vendor. The intent is vendor-independent, the installation is at the vendor.

In the field, that gap takes a recognizable shape. An engineering organization announces a cross-cutting control plane, the budget is approved under the observability line, and the stop mechanism stays a box on the architecture diagram that nobody has ever triggered under real conditions. The question that settles it is not whether the button exists. It is who pressed it, when, and how many seconds passed before the agent actually stopped.

Buying does not solve the problem yet either. Microsoft made Agent 365 generally available on May 1, 2026, at 15 dollars per user per month, presenting it as the control plane for observing, governing and securing agents. Registry synchronization with AWS Bedrock and Google Cloud is announced in public preview, and the announcement specifies that basic lifecycle governance on those platforms, meaning starting, stopping and deleting an agent, is coming soon. The vendor furthest along on this ground writes itself that cross-platform stopping has not shipped.

The stop layer left to build

Five elements make up a stop mechanism a team controls. Each is testable through an acceptance question, and a layer whose acceptance question cannot be answered does not exist yet.

An inventory of agents by platform, held somewhere other than each vendor's console. Acceptance: produce in one command the list of active agents across the three orchestrators, with their owner and their environment.

A shared gateway through which every outbound model call passes. It is the only place where a stop order can be both immediate and vendor-independent. Acceptance: verify that no production service holds an API key that lets it bypass the gateway.

A per-run budget, distinct from the monthly budget, with interruption on breach. The vendor cap stays useful as a last net; it cannot serve as the first. Acceptance: launch a deliberately looping run in pre-production and verify that it stops at the threshold, not at the invoice.

Permissions enforced at your level and not only at the vendor's. That is the lesson of the 58%: per-agent identity bounds who acts, it does not bound what happens when that identity is hijacked. Acceptance: revoke an agent's access to a tool and measure the delay before the revocation takes effect on an already-open session.

A unified trace that follows one run across the three platforms. Without it, an incident is reconstructed from three clocks and three formats. Acceptance: retrieve one complete end-to-end run from a single identifier.

What to start this week

Count the orchestrators actually in production, not the ones on the architecture diagram. The survey average is 3.1 and 46 respondents out of 107 could not name just one. The number to obtain is the one in your gateway logs and your active API keys, not the one in the architecture deck.

Test the stop. Pick a non-critical agent, put it deliberately into a loop in pre-production, trigger the stop procedure exactly as documented, and time it. The result of that test is the only data point that tells you whether you are in the 21%, in the 30%, or somewhere else.

Read the spend limits page of each of your vendors and note three things: the period, the enforcement scope and the stated propagation delay. Then compare those three values to the real duration of an agent loop at your organization. The gap is your exposure.

Check whether your agent permissions are enforced by your vendor or by you. The answer is in this follow-up question: if you switch vendors next month, how many of your permission rules leave with them.

Treat the unified trace as an incident prerequisite rather than an observability convenience. A team that cannot reconstruct a complete run also cannot demonstrate, after the fact, that the stop worked.

Conclusion

Agent governance settled into enterprises as a matter of policy, and the policies were written: identities, permissions, caps, committees. What did not follow is the mechanism that executes a stop decision in seconds, on the right run, across platforms no leadership team chose to have in that number. As long as that mechanism belongs to the vendor, the question is not whether the enterprise controls its agents, but over what period and with what delay it will find out that it did not.

Sources: As of August 2026

Godwin AVODAGBE