Microsoft's CodeAct Reframes the Agent Bottleneck as Orchestration, Not the Model
Microsoft's CodeAct lets an agent write one program that calls its tools instead of looping one tool at a time. The package is alpha; the more durable idea is that agents are slowed by orchestration, not model quality.
For about two years the dominant way to build an AI agent has rested on one quiet assumption: the model reasons, picks a single tool, the framework runs it, the result is handed back, and the loop turns again until the task is finished. Every popular agent stack — function calling, the Model Context Protocol, the newer browser-side WebMCP — has been an effort to make that one step, the model choosing and calling a tool, cleaner and more standard. At Build 2026 Microsoft added a piece to its Agent Framework that argues the step was never the expensive part. The interesting claim is about plumbing. A large share of what makes agents slow and costly, Microsoft argues, comes from the orchestration around the model and has little to do with model quality at all.
The feature is called CodeAct, and the mechanism is a genuine departure from the round-by-round loop. Instead of having the model select one tool, wait for the result, then decide on the next call, CodeAct has the model — in Microsoft's words — "write a single short Python program that calls your tools via call_tool(...), runs it once in a sandbox, and returns a consolidated result." A task that would have taken several model turns, each with its own prompt, its own tokens, and its own network round-trip, collapses into one. The generated program runs in a fresh, locally isolated Hyperlight micro-VM for each call, shipped in an alpha package called agent-framework-hyperlight, so the isolation that would normally make "let the model run code" sound reckless is, as Microsoft puts it, "essentially free at the granularity of a single tool call."
The pitch is explicitly about plumbing. "Many agents aren't bottlenecked by model quality, they're bottlenecked by orchestration overhead," the announcement says, and the numbers it offers are framed around that overhead rather than around smarter answers. On a multi-step benchmark Microsoft reports a 52.4% drop in execution time, from 27.81 seconds to 13.23, and a 63.9% drop in token use, from 6,890 to 2,489. Those are Microsoft's own figures on Microsoft's own workload — a vendor benchmark that deserves the usual skepticism. But the direction is the point: the gains come from cutting round-trips, an orchestration change the model in the loop never sees.
This is why CodeAct is more interesting as a signal than as a package. The idea underneath it — letting a model express its actions as executable code rather than as a sequence of structured tool calls — is not new, and Microsoft did not invent it. What is notable is a major vendor folding that idea into a framework that only reached 1.0 a couple of months earlier, and pitching it as the answer to a problem the rest of the industry has mostly been routing around. For two years the agent ecosystem has spent its standardization energy on the calling convention: how a model names a tool, describes its arguments, and receives a result, first through provider-specific function calling and then through the shared plumbing of MCP and WebMCP. CodeAct points the other way. Rather than narrate the orchestration one call at a time through the framework, let the model write the orchestration as code and run it once. It fits a broader drift across 2026, in which the model keeps becoming the interchangeable piece — the same logic that let Apple open its on-device framework to swap in third-party models with about one line of code — while the engineering that decides whether a system is fast or slow migrates to the orchestration wrapped around it.
The restraint belongs in the same breath as the enthusiasm. CodeAct ships as alpha, it lives on Microsoft's stack alongside the rest of the Build 2026 additions — an Agent Harness that bundles context compaction, session memory, and background sub-agents, and Foundry Hosted Agents for managed deployment — and the only performance evidence so far is the vendor's. A model that writes and runs code at runtime also raises review and safety questions a plain JSON tool call never does — questions that stopped being hypothetical the week the Miasma npm worm turned the configuration files AI coding agents execute on opening a repository into a malware trigger. Prototype against it if it looks useful. Hold off on betting a production agent on it until the package and the numbers have spent time outside Microsoft.
What survives the alpha label is the reframe, and that is the part worth carrying into whatever framework you actually use. The reflex, when an agent feels slow, is to reach for a bigger or newer model. CodeAct is a well-argued reminder that the round-trips are often the cost — that batching calls, collapsing turns, and treating orchestration as the thing to optimize can buy more than a model upgrade will. You do not need agent-framework-hyperlight to apply that lens, and most teams won't. The package is alpha and tied to one vendor. The idea it productizes is the durable part: an agent's speed is usually decided by its orchestration, and the model in the loop tends to take more blame than it deserves. That is the lens worth keeping the next time an agent is too slow to ship.