Managed Agent Architectures: Why Frontier Labs Are Rebuilding the Agent Loop

Recently, OpenAI released the Agents API, giving developers API access to the managed Codex harness. One of the strongest agent harnesses out there is now available as infrastructure developers can build applications around.

There is an important architectural idea behind the launch. OpenAI says taking advantage of new model capabilities often requires changes to the harness, so it plans to maintain and improve the Codex harness alongside its models. Anthropic makes a similar argument with Claude Managed Agents.

The frontier labs are building the model and harness together. And, more importantly, they are claiming they can build better harnesses because they control the models, and perhaps better models because they control the harnesses.

OpenAI and Anthropic are not the only companies offering managed agent infrastructure. AWS has AgentCore Harness, and Microsoft has Foundry Agent Service. Vercel is approaching the same part of the stack from another direction with AI SDK and infrastructure designed to run around agent harnesses. Unlike OpenAI and Anthropic, AWS and Microsoft can provide the managed harness without requiring the model underneath it to come from the same provider.

This gives agent builders two related architectural questions. How much of the agent loop should you still own, and does the harness need to come from the company building the model?

Understanding what these platforms put inside the managed harness can help decide how much of your agent stack you want to hand over.

1. The Agent As a Declarative Resource

One of the clearest patterns is treating the agent itself as a declarative resource. OpenAI’s Agents API can create a Codex agent in a single API call by specifying the task, model, tools, environment, and multi-agent settings. OpenAI operates the harness underneath that declaration rather than requiring developers to implement the loop themselves.

AWS AgentCore Harness takes the same idea even further. AWS lets developers override the model or tools for an individual invocation without changing the underlying harness definition. If the managed abstraction gets too restrictive, the harness can be exported to Strands code and run through AgentCore Runtime instead.

Microsoft has a similar split in Foundry Agent Service, where prompt agents run from a declaration and hosted agents let developers provide the implementation.

The managed harness moves orchestration from application code into configuration, similar to the shift Kubernetes and Helm brought to infrastructure. Developers only need to own the agent loop when they need behavior the managed harness can’t express.

2. Release Engineering, But For Agents

As agents graduate from local experiments to actual production use, they need their own release process. AWS gives AgentCore harnesses immutable versions and named endpoints, so updating the model, a tool, or a skill creates a new version rather than mutating the existing one.

AgentCore also supports A/B testing between agent versions using production traffic. One test might compare two prompts. Another might compare different models or completely different agent configurations.

Microsoft is building similar deployment primitives into Foundry Agent Service, where agents can be versioned and published behind stable endpoints instead of exposing a mutable development configuration directly to an application.

OpenAI is handling versioning at a slightly different boundary. The Agents API gives developers versioned access to Codex harness capabilities with model launches while OpenAI maintains and updates the harness itself. That is not the same as AWS giving developers immutable versions of their own agent configuration, but it establishes a separate release lifecycle for the harness underneath the application.

3. Model Selection Can Happen Inside the Session

Conventionally, agent architectures attach a model to an agent, so changing the model means changing the agent configuration. Some managed harnesses are starting to separate the two, allowing the agent session to stay fixed while the model changes underneath it.

AgentCore Harness allows a single harness to use Bedrock models, OpenAI, Gemini, or other compatible providers. AWS also lets developers switch models between turns of the same session without losing the conversation. One example would be to do planning with one model and execution with another.

Microsoft is taking a similar approach in Foundry Agent Service. Its model router can select a different model for each request inside the same conversation, routing simpler turns to cheaper models and more complex work to stronger ones.

In both cases, model selection is becoming less tightly coupled to the agent definition. The runtime can choose which model handles the next piece of work without rebuilding the conversation or changing the application interface.

That opens up routing based on task type, price, latency, or measured performance. A single agent session can use several models for different jobs without changing its identity or application interface.

4. Tools Are Moving Outside the Agent

The new Codex Agents API already treats tools as resources that can be discovered and loaded independently from the harness. Agents can connect to MCP servers, custom functions, and built-in tools, while OpenAI’s tool search loads the relevant tool definitions only when they are needed rather than putting the entire tool surface into context.

Microsoft pushes the separation further with Foundry Toolboxes. An organization can define a collection of tools independently from a particular agent and expose that collection through a managed MCP endpoint, with authentication and governance handled at the toolbox level.

AWS is taking a similar approach with AgentCore Gateway. APIs and MCP servers can sit behind shared infrastructure and be consumed by many different agents.

The agent can change without changing the tool layer, and the tool layer can change without redeploying every agent that uses it. Authentication and access policies can stay with the tools instead of being implemented separately inside each agent.

At scale, wiring the same systems into every agent separately gets wasteful. GitHub access should not need to be implemented 50 different times, and neither should Salesforce, internal databases, or company search. These platforms are moving common integrations into shared infrastructure that many agents can consume.

5. Skills Can Live Outside the Agent Definition

Unlike prompt text embedded directly inside an agent, skills can be maintained separately from the agent that uses them. The harness can discover and load these skills when they are needed rather than putting all of those instructions into the agent definition.

Codex has a concrete version of this pattern. OpenAI-hosted sandboxes for the Agents API can be configured with files, packages, skills, and plugins, and the API’s own example points the agent at a directory of skills as part of its environment configuration.

AWS AgentCore Skills package instructions and supporting resources into reusable units that can be attached to a harness. They can come from Git, S3, or AWS’s managed catalog.

This separates the procedure for doing a piece of work from the agent that performs it. A company could maintain one skill for competitive research and another for incident investigation, then make those skills available to many different agents.

With managed agent frameworks, the agent definition can stay relatively small while more of its capabilities are maintained separately.

6. The Optimization Loop Around the Agent Loop

Microsoft’s Agent Optimizer evaluates an existing agent and generates alternative configurations. It can change instructions, improve tool descriptions, modify skills, or recommend a different model.

The candidates are evaluated before a developer promotes one. AWS is assembling similar machinery in AgentCore, where production traces and evaluation results can produce recommendations for prompt or tool-description changes. Those changes can then be tested against the current version using live traffic.

In doing so, these frameworks are putting the agent loop inside a second loop that evaluates and changes the agent itself. The outer loop uses production behavior to generate a new agent configuration and test it against the current version. A human still approves the new configuration before promotion, but the platform can already generate and evaluate it.

OpenAI is not exposing this same customer-facing optimization loop in the Agents API, at least today. But it is doing a related form of optimization one level lower by continuously improving the Codex harness itself and shipping versioned harness capabilities alongside new models.

7. The Harness as an API Boundary

Anthropic makes an important design goal of Claude Managed Agents explicit: developers should program against stable interfaces while Anthropic retains the ability to change the implementation underneath them.

OpenAI is taking a similar approach with the Agents API. Developers call a managed service while OpenAI operates what it describes as an evolving Codex harness. OpenAI says it will maintain and continuously improve the harness alongside its models, with versioned access to new harness capabilities as models launch.

A managed harness puts much more than inference behind the provider’s API. It may make many model calls while working on a single task, call tools along the way, or use subagents without exposing every internal decision to the application. Codex also handles context compaction inside the harness, so an application can span multiple context windows without implementing that machinery itself.

OpenAI or Anthropic can then ship model and harness improvements together. For example, a new model capability can arrive with changes to context management or tool use without requiring every application developer to update their own orchestration.

Who Should Actually Own the Agent Loop?

Managed agent APIs move the developer boundary up from the model API to the agent harness. The provider now has room to change the machinery around the model as the model itself changes.

Frontier labs have a unique advantage here because they can build the model and harness together. Changes to context management, tool use, planning, and other parts of the loop can ship alongside the model capabilities they are designed to support.

That does not mean the provider will always build the best harness for your application. A harness designed around a specific product can take advantage of its workflows, tools, data, and constraints in ways a general-purpose managed harness cannot.

For some products, those optimizations may outweigh the advantage of having the harness developed alongside the model.