Last week, I shared what we’ve learned from three years of building agents. Getting an agent to complete a task is only the beginning. Making it work reliably means dealing with missing context, failed tools, inconsistent results, and costs that add up when you run it thousands of times.
That raises a practical question: how much of this should you have to build yourself?
OpenAI’s new Agents API joins Claude Managed Agents and a growing set of cloud platforms offering to take some of that work off your hands. You supply the task and tools; they operate the harness that keeps the agent working.
We’ve had to make this decision ourselves. We were early design partners for Claude Managed Agents, after using Claude Code for work beyond coding. We ultimately kept building our own system because we wanted to develop our own harness and keep improving how our agents plan, use tools, manage context, and check their work.
That comes with engineering and maintenance costs. Depending on what you’re building, a managed service could be the better choice.
This week, I’ll look at what these platforms handle for you, what remains your responsibility, and which decisions become harder to change once your agents are in production.
OpenAI Agents API
OpenAI’s Agents API gives you access to the Codex harness as a managed service. You supply the task, tools, and environment. OpenAI handles the running session, context compaction, orchestration, and recovery. Agents can execute code, edit files, use external tools through MCP, and produce artifacts. You can follow their progress, send additional instructions while they work, and resume the same session later. [source: Documentation]
Two capabilities stand out. First, programmatic tool calling lets an agent combine operations in code and filter large results before they enter its context. That matters when a task involves querying multiple systems or processing substantial amounts of data. Second, built-in subagents let it divide a task among specialists working in parallel, each with its own context, then combine their findings. OpenAI also publishes the underlying Codex harness, so you can inspect the machinery you’re relying on. [source: Launch announcement]
If you’re building agents into an existing product, you can preserve your application’s interface and business logic while handing over much of the execution infrastructure.
There is also flexibility over where the agent’s tools execute: OpenAI can host the sandbox, or you can supply your own environment. But self-hosting the sandbox does not move the entire service into your infrastructure. The API still maintains session state; its documentation currently specifies US-only data residency and no Zero Data Retention support, including when using a self-hosted sandbox. [source: Environment and data limitations]
The remaining work is at the application level. Your team still needs to decide how cases enter the system, which agent handles them, what counts as an acceptable result, and where exceptions go. Built-in subagent orchestration can help execute a task, but it doesn’t define that business process for you.
The tradeoff is control versus ownership. You retain control over the application and execution environment while adopting OpenAI’s managed runtime. An open-source foundation makes that runtime more inspectable; it doesn’t by itself make your deployed application portable. I would evaluate the cost of changing models, moving session state, and rebuilding integrations separately.
Claude Managed Agents
Claude Managed Agents covers similar ground: a hosted agent loop with tool execution, context management, and stateful sessions. Claude can run commands, work with files, search the web, and connect to external systems through MCP. You define reusable agents and environments, then launch sessions against them. The platform supports persistent conversation history and files, steering during execution, and scheduled runs. It also offers both managed and self-hosted sandbox environments. [source: Documentation]
Its Console makes the first experiment more accessible. You can configure an agent, attach tools and skills, and send it messages in an inline session runner. That gives you a browser-based place to inspect what it actually does before integrating it into an application. It would be misleading to describe the product as usable only through code, although connecting it to a production workflow can still require development. [source: Console onboarding]
The operational controls deserve attention. Session budgets let you bound spending on an individual run. There is an important qualification: the budget is checked between model calls, so a call already underway can take the total beyond the threshold. That is useful cost containment, but it should not be confused with an exact billing ceiling.[source: Session budgets]
You can also define an outcome with a rubric that the agent works toward. This gives it a more explicit completion standard than a loosely worded request. I would still evaluate the results independently: a rubric inside a run serves a different purpose from a regression suite that checks whether a new model or instruction change makes the agent worse across hundreds of representative cases. [source: Outcome definitions]
My read is that Claude’s combination of a Console, reusable configurations, scheduling, and session controls makes it a useful starting point for teams experimenting with recurring work. The challenge is carrying that experiment into the operating process. A successful Console session doesn’t establish who owns failed cases, how outputs are reviewed, or how the next batch gets assigned.
There are deployment constraints here too. Managed Agents is in beta, and Anthropic currently excludes it from Zero Data Retention and HIPAA BAA coverage. Those limitations matter independently of how well Claude performs the task. [source: Current limitations]
With either platform, I would test the same representative workload and compare completion quality, cost, human intervention, and recovery from failure. The better choice is the one that removes more work from your team, including the work required to operate the agents themselves.
The rest of the managed agent market
The cloud providers and enterprise software companies are approaching this from different starting points. Some offer infrastructure for almost any agent. Others put agents directly into the systems where a company’s work already happens.
Amazon Bedrock AgentCore
AWS offers both a runtime for hosting your own agent code and a managed harness that handles the agent loop for you. The harness supports models through Bedrock, OpenAI, Google Gemini, and other compatible providers. It includes isolated execution environments, persistent memory, browser and code tools, and connections to external systems through MCP. [source: AgentCore documentation]
That makes AWS worth considering if you want managed execution while retaining model choice. You can adopt its harness or bring your own framework, depending on how much control you need.
The dependency shifts toward infrastructure. Once your agent relies on AgentCore’s memory, identity, tool connections, and monitoring, moving elsewhere means replacing those services. I would distinguish the flexibility to change models inside AWS from the effort required to move the operation out of AWS.
Google Gemini Enterprise Agent Platform
Google’s offering has evolved from Vertex AI into Gemini Enterprise Agent Platform. It brings together a managed runtime, sessions, long-term memory, evaluations, agent identities, and tool governance. You can use its model-agnostic Agent Development Kit, while Agent Studio provides a visual approach to building agents. The broader platform supports Google, third-party, and open models. [source: Platform overview]
Google also has a more direct counterpart to the managed harness products: its Managed Agents API, powered by the Antigravity harness, can plan, execute code, use skills, search the web, and work with files inside a sandbox. Currently it’s only available for testing and non-commercial use.
I would evaluate Google as a broad platform for building and operating agents while checking the readiness of each component separately. The breadth is useful, but adopting several connected services also creates more dependencies to account for when moving.
Microsoft Foundry Agent Service
Foundry offers two paths. With prompt agents, you configure instructions, models, and tools, and Microsoft runs the agent. With hosted agents, you supply your own code and framework, while Foundry manages hosting, scaling, identity, and session persistence. It also provides tracing, evaluations, enterprise access controls, and publishing into Teams and Microsoft 365 Copilot. [source: Foundry documentation]
For a company already using Microsoft’s identity and collaboration systems, those connections could make deployment substantially easier. The tradeoff is how deeply the agent becomes integrated with Azure resources and Microsoft’s operating environment. Bringing your own framework preserves control over agent logic; it doesn’t automatically make the surrounding deployment portable.
Databricks Agent Bricks
Databricks approaches agents through enterprise data. Agent Bricks combines managed agent builders and custom agent deployment with access to multiple model providers, MCP tools, and governance through Unity Catalog. Its managed builders include Knowledge Assistant and Supervisor Agent, which coordinates agents and tools. [source: Agent Bricks overview]
I would put it on the shortlist when an agent’s usefulness depends heavily on data and permissions already managed in Databricks. That integration can remove substantial work. It also means the migration question extends beyond the agent: how much of its retrieval, authorization, and data access would need to be recreated elsewhere?
Salesforce Agentforce and ServiceNow AI Agents
These products bring agents into established business workflows. Salesforce lets teams turn existing workflows, Apex code, and APIs into agent actions, with natural-language configuration in Agent Builder. ServiceNow provides natural-language agent creation and an orchestrator for coordinating agents across workflows. [sources: Salesforce documentation, ServiceNow overview]
Their appeal is proximity to the work. If customer cases, employee requests, or sales processes already live in these systems, an agent can build on that existing setup. The corresponding dependency is the business process itself: moving the agent may mean rebuilding the actions and workflows around it.
Microsoft Copilot Studio, IBM Watson Orchestrate, and SAP Joule Studio are other enterprise-suite options to consider. Their fit should be judged against the records, processes, and deployment environment the business already uses.
These options make the portability question more concrete. A platform can give you considerable freedom over models while becoming deeply embedded in how your business operates. The useful question is what you can change independently and what you would have to rebuild.
Model flexibility
Suppose you’d built your workflows around Claude Managed Agents, then tested a new OpenAI model and found that it did your work substantially better. How quickly could you adopt it? Could you keep your integrations, workflow definitions, and evaluation process, or would you need to rebuild around another service?
The same problem applies in reverse when Anthropic ships a model you want.
I don’t want to make a long-term infrastructure bet on which lab will stay ahead. I want to use whichever model does the job best.
Often that will mean using different models within the same workflow. Routine classification may not need an expensive frontier model. Difficult exceptions might justify one. Document extraction may favor something else.
Models behave differently with the same instructions, tools, and context. Supporting several providers doesn’t make them interchangeable, and changing models can require adjustments and renewed evaluation.
But it should be possible to evaluate and roll out a better model without migrating the whole platform.
Own your context
The longer you run agents, the more you learn about the work: which instructions matter, where mistakes occur, what a reviewer needs to see, and which examples distinguish a good result from a plausible one.
That knowledge is worth preserving.
Consider an agent reviewing 1,000 venodor applications every month. Over time, you refine its criteria, connect internal records, and collect difficult cases to test against. Your team develops a process for resolving exceptions. Six months later, switching providers means preserving all of that work.
An export of conversation logs would help, but it wouldn’t establish that the replacement agent applies the same rules or knows when to ask for help.
Before adopting a platform, I’d check whether I can retain my evaluation datasets, export useful execution history, and reuse my instructions and integrations elsewhere. I’d also look at the permissions, cost controls, and review processes built around it. Model choice is one dependency. Saved state, cloud services, contracts, and team operating procedures can create others.
Shared tool interfaces such as MCP can reduce integration work. They don’t automatically transfer the rest of the operating system around the agent.
A practical test is to take one useful agent and try to reproduce it elsewhere. Record what transfers, what needs rebuilding, and whether the results hold up. That exercise tells you more than a checkmark next to “multi-model.”
Building our own system has also made me more careful about the word “portable.” We can give customers flexibility over models and still create dependencies on our own platform. The same questions should apply to us: can they take their instructions, evaluation cases, useful history, and workflow definitions elsewhere?
We know how much work goes into making agents useful. That is precisely why the knowledge accumulated along the way matters so much. A buyer should understand which parts they can carry forward when they decide to change providers.
How easy is it to put agents to work?
Imagine an operations manager with 1,000 cases to get through before Friday. They know which evidence matters, which rules apply, and when a case needs a second opinion. That expertise is essential to making an agent useful. Knowing how to configure its runtime shouldn’t be a prerequisite for contributing it.
Managed infrastructure removes some of the engineering burden. Someone still has to turn a working agent into a process the team can rely on: assign the cases, control access and spending, check the results, and handle exceptions.
The test comes the following week. Can the same agent handle the next 1,000 cases? Can the team see what failed and correct it? Does each run require less supervision, or has the work simply shifted from doing the task to watching the agent?
That’s how I’d judge these platforms. Look at how much work gets completed to an acceptable standard, how much human attention it takes, and what it costs.
A useful pilot should resemble the work you intend to hand over. Include incomplete inputs, unavailable tools, ambiguous cases, and tasks that should be escalated. A clean example shows what an agent can do. The awkward cases show how much responsibility you can give it.
Track cost per accepted result, including the time people spend checking and correcting it. A cheaper model can become the more expensive option if it creates more review work. A faster agent may offer little benefit if every result waits in the same approval queue.
Then run another batch. Keep enough of the evaluation set stable to compare changes, and add newly discovered failures to it. When you change a model, a tool, or the instructions, you need a way to tell whether you fixed one problem while creating another.
Why we built our own system
We understood why Claude Managed Agents needed to exist because we had spent so much time building the machinery around agents ourselves.
An “agent in a box” is a useful starting point: give it an environment, connect its tools, assign a task, and let it work. Once customers depend on it, the questions become more demanding.
Can it apply the same policy across thousands of cases?
Can someone inspect the evidence behind a decision?
What happens to unfinished work when a run fails?
How do you know whether changing the model or instructions actually improves the results?
Those questions shaped our own managed agent system.
For Grep AI, the product we wanted to build required control over more than a running agent. We wanted the person who understands a recurring job to be able to define it, run it across a list of inputs, inspect the results, and improve it. We also needed an agent that can reliably scale to thousands of jobs, run efficiently and not lose any accuracy.
That meant we needed control of how an agent plans its work, uses tools, manages context, checks its results, and recovers when something goes wrong, and keep improving those decisions against real workloads.
Model flexibility was part of that. So was the ability to change how the agent works around the model. We saw the harness as a core part of our product and wanted to develop it around the repetitive, high-stakes work our customers needed done.
Adopting a managed runtime would have transferred some engineering responsibility to a third party. We would still have been responsible for the quality of the completed work and the process our customers relied on. The decision was whether the infrastructure we could retire justified adapting the system we already had and accepting the dependencies that came with it.
Keeping our own system has a cost. We own more failures, more maintenance, and more decisions about infrastructure. Every hour spent on that work is an hour we could have spent improving something customers see.
A team starting today should make that calculation afresh. Three years of building gives us experience, but it also gives us an existing system. I wouldn’t assume that rebuilding everything we built is the right starting point for someone else.
What to test before choosing
I would begin with one recurring workload that matters enough to justify the effort. Run the same representative cases through the platforms you are considering. Include cases that should succeed, cases that should fail, and cases that should be escalated to a person.
Measure the cost per accepted result, the amount of human review required, recovery after failed tools or interrupted sessions, and the effort needed to understand why the agent made a decision. Then test portability directly. Change the model. Reproduce the workflow elsewhere. Export the useful history and see what can actually be reused.
The comparison should include the work around the agent as well as the work inside it. A managed runtime may remove a large amount of infrastructure while leaving your operating process untouched. A platform embedded in the system where your work already lives may solve more of that process while creating a deeper dependency.
Making the decision
Managed agents are becoming a legitimate alternative to building the entire harness yourself. For many teams, that is welcome. Running agents reliably is expensive, specialized work, and much of it will become infrastructure rather than product differentiation.
The difficult part is identifying which parts are actually generic for your use case.
If the value of your product comes from the harness itself, including how the agent plans, uses tools, manages context, verifies results, and recovers from failure, owning more of the system may be justified. That was our conclusion at Grep.
If your advantage lies elsewhere, a managed platform may let you reach customers faster and avoid years of infrastructure work. The important thing is to understand what you are outsourcing, what remains yours to operate, and what would have to move if the platform no longer fits.
Choose against real work. Keep your evaluations and accumulated context portable. Know which dependencies you are accepting.
Then make the trade deliberately.
About the author:
I’m AJ Asver, co-founder and CEO of Grep. I’ve spent the past three years building and deploying AI agents for high-stakes work inside large companies. I write The Operator’s Guide to AI to share what we learn when those systems meet real workflows, customers, costs, and production constraints.