Agent Platforms: The Model Is Rarely Why You Pick One

Every time a new agent platform launches from a model lab, the pitch is the same: our model, our runtime, one bill. And every time I look at how teams actually decide, the model barely comes up. It comes up in the demo. It does not come up in the postmortem.

A recent VentureBeat survey puts a rough number on what I've seen in my own orchestration work. Let me use it carefully, then explain what actually decides these projects.

What the survey says, and what it doesn't

In VentureBeat's August 2026 VB Pulse, only 2% of platform users (3 respondents out of 162) named the model behind their platform as the main reason they chose it. The big drivers, according to the same survey, were flexibility across models and tools (22%), production reliability (20%), ease of development (19%) and control over agent execution (18%). Together with those four, the report says, they drove 78% of platform choices. Security and permissions got 10%, total cost of ownership 9%.

Now the caveats, because they matter. The sample was self-selected from VentureBeat readers, not a probability sample. 221 responses came in, 166 survived screening. And the numbers move between waves: a September follow-up of 107 platform users had 7% naming alignment with a state-of-the-art base model, up from 2%, and VentureBeat calls that change statistically significant. Different respondents each wave. So I would not read "2%" as a market constant, and I would not claim model gravity is declining.

What I would take from it is the shape. Across waves, the buying criteria cluster around flexibility, reliability and control, not benchmark scores. That matches what I see when I'm the one on the hook for the system at 3 a.m.

Why the model is the easiest thing to change

The model is the most swappable layer in an agent system, at least in principle. Prompts, tool schemas, retry logic, state, permissions and logging are where the engineering lives. The model is one parameter in a config.

In practice it's less clean. The September Pulse found that 59% of enterprises that switched AI models in a live app had to rework the app or switch back, and only 19% called switching almost effortless. That's the real lesson: the model is not sticky because of the model. It's sticky because of everything you wrapped around it. Prompts tuned to one model's quirks, tool-call formats, structured output assumptions, eval baselines.

So if you're picking a platform, the question is not "which model is best today." It's "how much will it hurt when the best model changes, which it will." Reportedly 81% of consultants said their main client had switched models in the past year, against 51% of in-house respondents (September Pulse). Consultants see more churn because they see more clients. That should tell you something about the pace you're planning against.

The four things I actually evaluate

When I assess an orchestration layer, I run through the same four questions. None of them is about the model.

1. Observability: can I reconstruct a bad run?

In the August data, 22% of respondents named limited visibility and observability as the top risk of keeping orchestration control inside a model provider's platform. I'd have put that number higher, because it's the thing that hurts most when it's missing.

My test is simple. Take a run that went wrong last week. Can I answer, from logs alone: which step failed, what the model saw at that step, which tool was called with what arguments, what it returned, and how long each hop took? If the platform gives me a dashboard summary but not the raw trace I can export and query myself, that's a yellow flag. I want traces in my own storage, in a format I control, so I can build evals and replays from real failures.

This is the same lesson I learned running scheduled workers that operate with no human in the loop. When nobody is watching, the logs are the only witness. If the witness is a vendor's UI with a retention window, you have a problem.

2. Cost controls: what stops a runaway agent?

This one scares me most. The August Pulse found that 23% of enterprises using agent orchestration tracked agent spending only after the fact, with no real-time way to stop a runaway agent. The other 77% used native platform controls, custom gateways or low-cost model routing. In September, 21% had no automated spending stop (11% monitoring after the fact, 10% no specific controls), and another 12% didn't know how spending was controlled.

Treat those as survey snapshots from different respondent pools, not a trend. But the existence of a quarter-ish of users with no brake is the finding. An agent in a retry loop with a tool that returns an error it can't parse will happily burn budget all night. I've seen that failure shape enough to design against it by default.

My baseline, regardless of platform:

• A per-run budget. Max tokens, max tool calls, max wall-clock time. Hard stops, not warnings.
• A per-day budget per agent identity. When it's exhausted, the agent stops and pages a human, not retries.
• A gateway in front of model calls. Even a thin proxy that counts tokens and enforces limits beats trusting the platform's after-the-fact billing page.
• Loop detection. Same tool, same arguments, N times in a row, kill the run.

Here is the sketch of the guard I put around an agent loop. It's illustrative, not tied to any vendor SDK:

class RunBudget:
    def __init__(self, max_tokens, max_tool_calls, max_seconds):
        self.max_tokens = max_tokens
        self.max_tool_calls = max_tool_calls
        self.deadline = time.monotonic() + max_seconds
        self.tokens = 0
        self.tool_calls = 0
        self.recent = deque(maxlen=4)

    def charge(self, tokens, tool_signature=None):
        self.tokens += tokens
        if tool_signature:
            self.tool_calls += 1
            self.recent.append(tool_signature)
        if self.tokens > self.max_tokens:
            raise BudgetExceeded("token cap")
        if self.tool_calls > self.max_tool_calls:
            raise BudgetExceeded("tool-call cap")
        if time.monotonic() > self.deadline:
            raise BudgetExceeded("time cap")
        if len(self.recent) == 4 and len(set(self.recent)) == 1:
            raise BudgetExceeded("loop detected")

Twenty lines, and it has saved me more than any clever prompt. The point is that it lives in my code, so it works the same on any platform. If the vendor's native controls are good, great, I use both. I just don't make them the only line of defense.

3. Portability: where does the control plane live?

The August survey found that 67% of respondents expected the agent control plane to sit at least partly outside a provider-managed service by the end of 2026, while 27% expected a provider-managed agent service. The September follow-up put it at 72% keeping at least some control outside the model providers' platforms by 2027, with only 28% relying on the provider's platform alone. Top risk of putting control inside a provider's platform: inflexibility across models and tools, at 28%.

I'd read that as people who've been burned, or who've watched colleagues get burned. The architecture I default to keeps four things on my side of the line:

The provider's runtime can still do the heavy lifting for the parts where it's genuinely better. But the contract between my system and the model is something I own. This is the same instinct I apply on serverless AWS work: keep the glue and state in services I control, treat the expensive, fast-moving component as a replaceable dependency.

4. Reliability under real load: does it survive Tuesday?

Production reliability was the second-biggest driver in the August data (20%). It's also the least glamorous to evaluate. I look at: how does it behave on partial failures, can I resume a half-finished run rather than restart it, are tool calls idempotent or at least safely retryable, and what happens at a rate limit. The honest answer from a demo is always "it works." The honest answer from a failure-injection test tells you the truth. I kill a tool mid-run and see what state the agent is left in.

The vendor-lock angle, stated fairly

Model makers building platforms is not sinister. A lab that controls both the model and the runtime can ship tighter integrations, better tool-use behavior and fewer glue-code headaches. In the August data, 45% of all respondents used OpenAI's Agents SDK or Responses API, and 69% of those users named it their primary platform. Among Anthropic Claude Platform users, 38% named it primary and 62% named another platform. In September, 43% ran OpenAI's platform, 22% Anthropic's and 21% Google's. People use these. Many are happy.

But note that the same survey shows 60% of respondents planned a new, additional or replacement orchestration platform within 12 months, 28% within three months. Even the happy users are shopping. The market is not settled, and your platform choice is a bet on a moving target. That's the case for keeping the expensive-to-move parts (state, traces, permissions, budgets) in your own hands.

It also lines up with where budgets are going: 34% named agent workflow tooling as the orchestration investment that will grow most next year, 25% security and permissions enforcement, 20% monitoring and debugging, and only 5% said their budget wasn't increasing. Money is flowing into exactly the control-and-visibility layer, not into model selection.

What I'd do

If I were advising a team picking an agent platform this quarter, this is the order I'd work in:

1. Write the exit plan first. Before committing, document what it would take to move to a different model or runtime. If the answer is "rewrite," price that in.
2. Put a budget guard and a gateway in front of model calls on day one. Per-run and per-day caps, loop detection, and a kill switch that doesn't depend on the vendor.
3. Export traces to your own store. Build a small replay and eval harness from real failures before you need it.
4. Keep state and permissions on your side. Use the platform's runtime where it's strong, but don't let it become the system of record.
5. Treat the model as a config value, tested by evals. Switch models by running your own eval set on your own traffic, not by trusting a leaderboard.
6. Re-evaluate every quarter. The survey data swings between waves; so does the vendor landscape.

Notice that the model choice isn't on the list as its own step. It falls out of step 5. That's the point.

A last caution on the data: this is one publication's reader survey, small bases, shifting respondents. Use it as a sanity check on your own instincts, not as proof of a market trend. Mine matched it. Yours might not, and your own incident history is a better guide than any survey.

If you're weighing an agent platform and want a second pair of eyes on the architecture, the budget controls or the exit plan, you can reach me at lazar-milicevic.com/#contact. Or keep reading on the blog, where I write about what actually breaks when these systems run unattended.

Source for survey figures: VentureBeat, August 2026 VB Pulse and VB Pulse Agentic Orchestration Report, September 2026.