For the last two years, most SaaS teams shipping agents built their own harness: a loop that calls the model, routes tool calls, trims context, retries failures, and stores state somewhere. In September 2026 that started to change in a visible way. On September 10, OpenAI introduced the Agents API in public beta, offering the harness behind Codex as a managed service, with the agent's compute running in an OpenAI-hosted sandbox, on your own infrastructure, or with sandbox partners. On September 29, MongoDB launched Atlas Agent Engine in public preview, pitching a model- and framework-neutral layer for agent execution, memory, and governance. The question for founders is no longer whether you can build an agent loop. It is which layers of the agent stack are worth owning.
Split the stack before you compare vendors
“Agent platform” bundles several very different things. There is the harness, which manages context, tool selection, retries, and subagents. There is the sandbox, where code runs and files live. There is memory and retrieval, which decides what the agent knows across sessions. There is governance: identity, permissions, audit logs, and cost limits. And there are your tools and workflows, the part customers actually pay for. Vendors increasingly let you adopt these layers independently. MongoDB says customers can use its memory and governance layers with or without its runtime; OpenAI separates the hosted harness from your choice of environment.
What a managed harness genuinely buys you
OpenAI's announcement lists features many teams spent months building badly: automatic context compaction as sessions approach the context limit, tool search that loads tool definitions on demand, programmatic tool calling for parallel and chained calls, and multi-agent support where subagents keep their own context. It also says the harness is versioned alongside model launches and based on the open-source Codex harness. If your team's roadmap includes “rewrite the agent loop for the new model again,” renting that maintenance can free engineers for the domain work that differentiates you.
What you should keep in-house
Keep anything that encodes your customers' business: tool implementations and their permission checks, tenant isolation, the evaluation sets that define a correct outcome, and the UX for approvals and handoffs. Keep your audit trail in a store you control, even if a vendor also logs actions, because enterprise customers will ask you, not your vendor, what an agent did and who authorized it. If a managed runtime disappears or changes pricing, those assets should move with you.
Agent stack ownership map (example)
harness / context management -> rent (managed), behind adapter
sandbox / code execution -> rent, region + VPC options checked
memory / retrieval -> evaluate; tenant-scoped either way
tools + permission checks -> own
evals + golden tasks -> own
audit log of agent actions -> own (mirror vendor logs)
approval + handoff UX -> ownLock-in is the real cost to price
Managed runtimes reduce build cost and increase switching cost. Mitigate this deliberately. Expose tools through open protocols where possible; both announcements emphasize MCP, and MongoDB also cites A2A. We covered the product decision in MCP for SaaS founders . Wrap the vendor SDK behind a thin internal interface so the rest of your code calls startAgentRun , not a vendor-specific method. Store agent outputs and intermediate artifacts in your own storage. Run your eval suite against at least one alternative path every quarter so you know what migrating would actually cost. The same ownership discipline shows up in build vs buy for B2B auth .
Data residency and security reviews
Enterprise buyers will ask where agent code runs, where files and secrets live, and which subprocessors touch their data. A hosted sandbox may be fine for internal analytics but a non-starter for a regulated customer. OpenAI lists options including fully managed environments and deployments within your VPC through partners. Map each customer segment to an acceptable environment before you commit, and update your subprocessor list and DPA when you adopt a runtime. Discovering a residency gap during procurement costs far more than checking it upfront.
Price the economics honestly
OpenAI says there are no additional fees for the Agents API beyond tokens and tools; MongoDB describes consumption-based pricing that draws on existing Atlas commitments. Neither makes agents cheap by default. Long-running agents with subagents can multiply token use quickly. Model cost per completed task, not per call, and set per-tenant budgets and kill switches regardless of platform. Remember that public beta and public preview labels mean APIs can still change; plan engineering time for that churn.
A sensible adoption path
Pick one internal or low-risk workflow, implement it on the managed runtime behind your adapter, and run it side by side with your existing harness against the same eval set. Compare task success, latency, cost per task, and debugging experience. If the managed option wins, migrate customer-facing workflows one at a time, keeping your audit log and permission layer unchanged. If it loses, you have learned that cheaply.
Observability you can take with you
Managed runtimes usually include their own tracing views, and they are useful for debugging. Still emit your own spans and events for every agent run: tenant, workflow, tools called, approvals requested, cost, and outcome. Send them to the observability stack you already use. When you compare runtimes or migrate, those traces become the baseline that tells you whether the new platform is actually better for your customers. Start with the checklist in ship agent observability before you ship agents .
Founder takeaway
Managed agent runtimes are now a serious option, not a demo. Rent the commodity layers, own the tools, data, evals, and audit trail, keep vendor code behind an adapter, check residency before procurement does, and price everything per successful task. That gives you the speed of a managed harness without betting the product on one vendor's roadmap. If you are still deciding whether the work belongs in a long-running agent at all, read durable agents vs chatbots , or how to brief an agency for AI features . Want a second pair of eyes on your agent stack? Talk to the CodeFlamme team .
