Building the Agent Got Cheap. Feeding It Didn't.

OpenAI's Agents API makes orchestration a rented commodity. The expensive part of an enterprise agent was never the harness. It's the data sitting underneath.

On September 10, OpenAI moved its Agents API into public beta. Strip away the launch copy and the substance is this: long-running sessions, automatic context compaction, sandboxed execution, tool search, subagents running in parallel. All of it is now a managed service you stand up in one API call, at no cost beyond the tokens and tools your agents consume.

That's a real change, and worth being precise about. Your agent doesn't get more accurate. What disappears is the engineering your team was going to spend on session state, retry logic, context windows, and a sandbox that doesn't leak. For most enterprises that was the visible part of the project, the part with an epic and a demo at the end. Which is exactly why losing it will mislead people about how far along they are.

What got cheap, and what didn't

McKinsey's The State of AI in 2026, published August 25 and drawn from 1,719 respondents across 97 nations, found that 32 percent of organizations decided against buying software because they could build it in-house with agentic coding tools. Among the firms McKinsey classes as high performers it was 47 percent.

Same survey, same respondents: 37 percent attribute at least some EBIT impact to AI, about the same share as the year before. The group attributing 5 percent or more of EBIT held flat at 6 percent.

The obvious reading of those two numbers is the wrong one. This is not a case for going back to buying. Building is the right call more often now than it has been in a long time. What the numbers show is that the bottleneck moved. Writing the application was never the expensive part, and it just got cheaper still. The cost sits where it always sat: in the definitions, the access model, and the condition of the data underneath.

What the harness hands back to you

Rent the orchestration layer and four problems remain. All four live in the data platform, and no frontier release is going to solve any of them, because they're properties of your estate rather than of the model.

Definitions that disagree. The agent asks for revenue. Your finance mart nets returns, the regional warehouse doesn't, and a downstream Power BI model converts currency at a different date boundary than either. A human analyst catches this, because they know which number the CFO means. An agent takes whichever tool answered first and writes a confident paragraph around it. Drift you could live with when a person read the result becomes something else when an agent chains four of them.

A tool surface as wide as the database. The fastest way to demo an agent is to hand it a warehouse connection and a text-to-SQL tool. It's also the fastest way to fail a security review. Tool boundaries are access-control boundaries, and a broad query tool inherits every permission its service principal holds. What survives production is a narrow set of purpose-built tools over governed data products, each one scoped, auditable, and returning a shape you can validate.

No freshness contract. Warehouse consumers tolerate staleness informally. Someone notices the dashboard looks like yesterday, and waits. An agent has no such instinct. It will act on a nine-hour-old inventory position as readily as a current one, and with an agent the action is the output. Every tool needs a freshness guarantee the agent can read and refuse on.

No way to tell a change from an improvement. Teams ship an agent, field complaints, adjust a prompt, and have no idea whether it helped. Without a fixed set of real questions with known-correct answers, you're tuning by anecdote. The harness will run a worse agent for you at scale, quite happily.

The order that works

Most stalled agent programs did the right steps in the wrong sequence.

Start with the question rather than the agent. Write down the twenty or thirty things it's actually supposed to answer, in the words the business uses. That list doubles as your evaluation set, your tool inventory, and your scope boundary, and writing it is usually the first time anyone has defined what good means.

Then build the data products those questions need, with owners, contracts, and freshness guarantees, before any agent code exists. Expose each one as a narrow tool with a validated return shape. Then wire up the harness, which as of this month is close to the easiest step in the sequence.

Then budget the run. An agent that calls four tools and compacts context across a long session isn't priced like a dashboard refresh. Model the per-workflow cost and the warehouse compute behind it at real concurrency, before it reaches the business rather than after finance asks.

Governance runs alongside all of this rather than gating the end. Catalog grants, row-level security, lineage, and classification are the substrate the agent runs on. Bolt them on afterward and you get a rewrite.

What it costs to get wrong

The failure mode isn't an outage. It's quieter and more expensive than that.

An agent that's confidently wrong is worse than no agent, because it removes the friction that used to make people check. A dashboard with a bad number gets caught in a meeting. An agent with a bad number sends the email, updates the record, or feeds the next agent, and the error travels carrying the credibility of the system that produced it. Winning that trust back takes far longer than fixing the bug did.

The second cost is the rebuild. Programs that skip the data-product step reach production, find the definitions don't hold across sources, and start over with the semantic and access layer they should have built first. The cheap harness goes out with everything else.

None of this is an argument against building. It's an argument for knowing which part you're building. If your agent program is stuck somewhere between a convincing demo and something the business will rely on, the model is almost never the blocker. We'd be glad to look at where it actually is.