OpenAI's new Agents API hands the agent "harness" — the loop that decides how your agent thinks and acts — to the vendor. That's a real upgrade, and a real governance shift.
There is a part of every AI agent that almost nobody outside the engineering team thinks about, and it is the part that determines most of the agent's behavior.
It isn't the model. It isn't the prompt. It's the harness: the loop of code that decides when the model gets called, how tools are offered to it, what happens when a tool fails, how much conversation history survives into the next turn, when the agent stops, and when it asks a human. Two teams using the identical model with the identical prompt can get wildly different agents depending on how that scaffolding is written.
Until now, that scaffolding was yours. You wrote it, you owned it, you debugged it at 2am. With the launch of its Agents API, OpenAI is offering to take it off your hands — providing versioned access to the same harness that powers Codex, maintained and continuously improved alongside each model release. The pitch, in OpenAI's words, is that upgrading models often means reworking your harness, which takes time away from improving your actual application. Let them handle the plumbing.
It's a genuinely good pitch. It is also one of the more consequential architectural decisions an engineering team will make this year, and most organizations will make it without anyone outside engineering noticing.
What actually changes
The old model of building agents was: pick a model, build your own loop around it, own every behavior that emerges from that loop. Painful, slow, but fully legible. If your agent did something strange, the explanation lived in code you wrote.
The new model is: pick a model, pick a harness version, and inherit a set of behaviors defined by your vendor. OpenAI cites improvements like keeping agents working across long sessions — which is an enormous practical win, and also a quiet statement that the vendor is now making judgment calls about context management, compaction, and persistence on your behalf.
This is the same trade every organization has made a hundred times with cloud infrastructure, and mostly it has worked out. Managed services beat hand-rolled ones. Google runs Kubernetes better than you do. OpenAI almost certainly tunes an agent loop for GPT-6 better than your three-person platform team does, because they have the model internals and you don't.
But there's a difference between managed infrastructure and managed behavior. When AWS improves a load balancer, your app serves the same responses faster. When your agent vendor improves the harness, your agent may make different decisions — take an extra step, retry a failed action, persist a piece of context it used to drop, escalate later than it did last month. The output changes. And output is the thing your customers, your auditors, and your regulators actually care about.
Three questions this raises for anyone running agents
1. Is the harness version in your inventory?Most AI inventories, if they exist at all, record the model: "Customer support agent — GPT-6 Astra." That's now insufficient. The behavior of that agent is a product of model version and harness version. If you can't name both, you can't reproduce an incident, and you can't explain to anyone why the agent behaves differently in October than it did in August.
Versioned access is the good news here — OpenAI is explicitly offering version pinning rather than silently rolling everyone forward. That only helps if someone in your organization treats the harness version as a tracked, owned, deliberately-upgraded dependency rather than a default nobody chose.
2. What is your evaluation suite actually measuring?If you built your evals against your own harness, they encode assumptions about your loop: how many steps, what tool-failure behavior, what stopping condition. Move to a vendor harness and those assumptions quietly stop holding. Your evals will still produce numbers. The numbers will still look fine. They just won't be measuring the same system anymore.
The practical fix is unglamorous: re-baseline your evaluations against the new harness before migration, not after, and re-run them on every harness version bump the same way you would on a model upgrade. Treat harness version changes as a change-management event with a rollback plan.
3. Where does accountability sit when behavior is shared?Nowhere in any regulatory framework does "the vendor's harness did it" appear as a defense. Under the EU AI Act you're the deployer. Under sector regulators you're the accountable firm. Under contract law you're the party your customer sued. Adopting a vendor harness redistributes control without redistributing liability — which is precisely the asymmetry that makes it worth a conscious decision rather than a default.
The broader pattern
Zoom out and the Agents API is one instance of a trend that will define enterprise AI over the next two years: the abstraction layer keeps rising, and every time it rises, organizations trade visibility for capability.
That trade is usually correct. Hand-rolled agent scaffolding is a maintenance tax with almost no strategic value, and teams that insist on owning every layer will ship slower than teams that don't. The mistake isn't adopting the managed harness — it's adopting it without registering that a meaningful chunk of your system's behavior now lives outside your organization, on someone else's release schedule.
The organizations that navigate this well won't be the ones that resist vendor abstraction. They'll be the ones that know exactly which layers they've outsourced, which versions they're pinned to, and what their evidence looks like when someone asks why the agent did what it did.
That starts with an inventory that goes one level deeper than the model name. Most don't yet.
Evum AI helps organizations inventory their AI systems, track spend, and measure maturity across five dimensions — so you know what you're running, which version of it, and where the gaps are.