Your First Engineer Wants to Build the Plumbing. OpenAI Just Started Renting It.

Every few months I get the same message from a founder I'm advising. It's usually forwarded from their first engineer, and it usually reads something like: before we build features, we should build our own agent framework so we're not locked into anyone.

I've now heard some version of that from four different companies in a year. I've also been the person who wrote that message. Years ago, on my own team, we built orchestration, retry logic, and a memory layer from scratch, and I signed off on it because at the time there wasn't much to buy.

That argument just got a lot weaker. Last week OpenAI put the Agents API into public beta, which is the managed version of the harness they run Codex on. Context handling, tool calls, subagents, files, sandboxed code environments, and execution that survives longer than a single request. The plumbing, in other words. The part your engineer wanted six to ten weeks to build.

I haven't shipped anything on it yet. It came out days ago, and anyone telling you they've battle-tested it is lying to you. But I don't need to have used it to know what it does to a scoping conversation, because I've watched this exact category of work get commoditized twice already.

What the six weeks actually were

When a developer says "agent framework," they mean a specific and unglamorous pile of work. Something has to decide which tool the model calls next. Something has to catch the call that failed and try again without looping forever. Something has to carry what happened in step three into step eleven without blowing past the context window. Something has to run generated code somewhere it can't touch your production database.

That is real engineering. It is also the same engineering at your company as at the company down the street. There is no version of retry-with-backoff that is yours. I've now run engineering for about ten companies as a fractional CTO, and I could take the orchestration layer from any one of them, swap the tool definitions, and drop it into another. Nobody would notice.

Here's what that means on your budget. When I scope a fixed-price MVP, I'm dividing the work into two piles in my head before I quote anything. One pile is the stuff that makes your product the thing your customers pay for. The other pile is the stuff that has to exist so the first pile can run. Historically the second pile ate a third of the calendar on anything agent-shaped. Now a meaningful chunk of it is a vendor line item instead of a sprint.

If you are paying for weeks of work on the second pile, you are funding a worse copy of something OpenAI, Anthropic, and three open-source projects all maintain full-time.

What I refuse to build now, and what I still insist on owning

I've gotten blunt about this in scoping calls. There are three things I will not spend your money building anymore:

• The execution loop. Tool calling, subagent spawning, long-running jobs. Rent it.
• The sandbox. Somewhere isolated for generated code to run. Rent it. Getting this wrong is a security incident, not a bug.
• Memory plumbing. The mechanics of storing and retrieving conversation state. Rent the mechanics. What goes in memory is your call, and that's different.

And there are three things I will not let a vendor own, no matter how good the API gets:

Your domain rules. The forty pages of judgment that live in your head and your ops lead's head, about what a good outcome looks like in your specific business. Which claims get escalated. What counts as a qualified lead in your market versus the market next door. No API ships with that. I've had founders tell me this part is "just prompting," and then watched a competitor with worse engineering beat them because the competitor actually wrote it down.

Your data. Not the model. The proprietary records, the labeled outcomes, the history of what your business did and whether it worked. That is the only asset in this stack that appreciates.

Your evals. An eval is just a scored test set: a batch of real inputs from your business with a definition of what a correct answer looks like, run automatically every time something changes. This is the single most underbuilt thing I see. Founders will happily pay for a demo and balk at paying for the harness that tells them whether the demo still works next month. Then a model version changes underneath them and nobody finds out for three weeks except a customer.

If you rent the plumbing and own those three, you have a defensible product. If you build the plumbing and skip those three, you have a science project with good uptime.

This changes who you hire

The instinct for a first technical hire is to look for the person who can build the most from scratch. That instinct made sense when the plumbing was the job. It's now the wrong filter.

The engineer I'd hire today is the one who is comfortable being unimpressive about infrastructure. Who reaches for the managed thing first, gets to a working slice in days, and saves their originality for the parts of the system that encode your business. Who, when you ask "how do we know this is working," has an answer that isn't "I tried it and it looked good."

In an interview, ask them what they would refuse to build for you and why. A strong candidate will name three or four things immediately and sound slightly annoyed that anyone would consider it. A weak one will describe an architecture.

The uncomfortable version of this: some of the cost of a build was always the plumbing, and that portion is shrinking fast. A three-week fixed-scope MVP at $14,500 is possible precisely because I'm not rebuilding the same layer for the fifth time. What you're actually buying is the judgment about which pile each piece of work belongs in.

Your engineer isn't wrong that the plumbing matters. They're wrong that you should pay them to invent it.

If someone on your team just asked for two months to build an agent framework, forward them this and then book 30 minutes. I'll tell you honestly which weeks in that estimate are still real.