The Agent Loop Is Moving Out of Your Codebase

The plan-act-observe loop you hand-wrote is turning into a managed runtime feature, confirmed by a cluster of launches in the week of July 16: AWS AgentCore reached general availability, Microsoft shipped its Agent Harness at BUILD, and the coordinated SDK updates from OpenAI, Anthropic, and Google made declarative loops first-class.

The loop was never the hard part. What is hard is everything the loop touches, the stopping condition, when to gate a human, the custom retry, the domain-specific meaning of "done." Managed runtimes standardize the easy eighty percent and hand you a fixed set of hooks for the difficult twenty.

Microsoft's CodeAct pattern, where the model writes one short program that calls your tools and runs once in a sandbox, cut latency by 52 percent and token use by 64 percent in their own numbers. Once the runtime owns the loop, it can change what "loop" even means, which is not something you can do from application code.

For about two years, building an agent meant writing the same forty lines. Call the model. Read the tool call it returned. Run that tool. Feed the result back. Check whether the model thinks it is finished. If not, go around again. Somewhere in there you added a token counter so the context window did not overflow, a try-except so one failed tool call did not kill the run, and a hard cap on iterations so a confused model did not loop forever.

Everyone wrote that loop. It looked nearly identical in every codebase. And in the week of July 16, several of the largest vendors shipped the same message at once: you do not have to write it anymore.

What actually shipped

AWS made AgentCore generally available on July 23. The pitch is a declarative runtime that takes your models, tools, and instructions and handles orchestration, memory, error recovery, and managed knowledge bases, so you stop hand-building the loop that ties them together.

Microsoft landed the Agent Harness at BUILD 2026. It ships automatic context compaction that watches token usage and trims chat history mid-loop before the window overflows, built-in providers for memory, file access, and task tracking, and middleware for tool approval and tracing. The same framework added Hosted Agents that scale to zero and resume with filesystem state intact, each session in its own sandbox.

The July 16 SDK wave from OpenAI, Anthropic, and Google pointed the same direction. Agent workflows became first-class objects. Instead of orchestrating separate plan and execute calls by hand, you declare tools, memory, and event handlers, and the SDK runs the loop. JSON schema mode started enforcing that every tool call is valid before it fires, which quietly removes one of the most common reasons hand-rolled loops broke.

Five vendors, one direction. The while-loop around your model is becoming a service you configure rather than code you own.

The loop was never the hard part

The loop itself was easy. You could write it in an afternoon, and once written it rarely changed. That is exactly why it was ripe for a runtime to absorb. No team was shipping a competitive advantage in its retry logic.

The hard parts live one layer in, and they do not go away because the loop moved. Which tools does this agent get, and which does it never touch. What is the actual stopping condition, because "the model says it is done" is not always the right answer when the model is wrong and confident. When does a step need a human to approve it before it executes. What counts as a failure worth retrying versus a failure worth aborting. Those decisions are your product. The runtime cannot make them for you, and the good ones do not pretend to.

So the honest read on this shift is not that agents got easy. It is that the boring, repeated scaffolding got commoditized, which is a good thing, and the interesting decisions stayed exactly where they were. If you were hoping the runtime would decide your stopping conditions, you were hoping to outsource the part that is actually your job.

What you give up when the runtime owns the loop

When the loop is your code, you can reach into any step. You can add a side effect between the tool call and the observation. You can rewrite the model's plan on the fly. You can invent a stopping condition that no framework author anticipated. That freedom is the reason a lot of production agents still run on a hand-written loop today.

When the loop is the runtime's, you get the hooks the runtime exposes and nothing else. Middleware, event handlers, approval rules. For most agents that is plenty, and you come out ahead by deleting orchestration code you never wanted to maintain. But there is a real tail, call it the difficult twenty percent, where an agent needs a weird stopping rule, a mid-loop write to an external system, or a retry policy tuned to one specific tool. In that tail you stop writing ten lines of Python and start fighting the framework, filing feature requests for a hook that does not exist yet.

That tradeoff is not a reason to avoid managed runtimes. It is a reason to know which bucket each agent falls in before you delete the code. Standard agent, mostly reading and summarizing, calling a handful of well-behaved tools, take the runtime and never look back. Agent that touches money, mutates production state, or has a stopping condition your compliance team wrote, keep your hands on the loop until the runtime's hooks clearly cover what you need.

CodeAct changes what a loop even is

The most interesting piece in the batch is Microsoft's CodeAct, because it does not just move the loop, it questions whether there should be a loop at all.

The classic agent loop is a conversation. The model asks for a tool, the runtime runs it, the result goes back, the model asks for the next tool, over and over across many round trips. Each round trip costs a full model call and adds the entire growing history to the next prompt. CodeAct collapses that. Instead of stepping through tools one message at a time, the model writes a single short program that calls your tools through a call_tool function, and the runtime runs that program once in a sandboxed micro-VM.

Microsoft's numbers on multi-step workloads were a 52 percent latency drop, from roughly 28 seconds to 13, and a 64 percent token drop, from about 6,900 to 2,500. The reason is simple. One program instead of eight round trips means one model call instead of eight, and the tool results never have to be pushed back through the model to decide the next step, because the program already knows the next step.

You could not do this from application code, because from application code you do not control what a "step" is. The model hands you one tool call at a time and you react. Once the runtime owns the loop, it can offer the model a different contract entirely, write the whole plan as code, run it once. That is the kind of change that only becomes possible after the loop stops being yours.

What to do about it

Do not rewrite everything this week. The migration cost is real and the runtimes are days old.

Do audit your agents into two piles. The ones whose loop is genuinely generic, plan, call, observe, repeat, with ordinary tools and an ordinary stopping condition, are candidates to move onto a managed runtime the next time you touch them. You will delete code and gain context compaction, tracing, and error recovery you were half-implementing anyway.

The ones with a custom stopping condition, a human gate in the middle, or a tool that needs special handling, keep on your own loop and watch whether the runtime hooks catch up. When AgentCore or the Agent Harness ships the exact hook you were hand-coding, that is your signal to move.

The loop leaving your codebase is a good thing, the same way you stopped writing your own HTTP server and your own connection pool. Just be clear-eyed that what left was the easy part, and the decisions that make your agent yours are still sitting right where you left them.