OpenAI's Agents SDK: build in-house or hire it out

Somebody has made the case for an agent, and it is a good case. You also have developers. So the question is not whether to do it. It is who does it: hand your own team OpenAI's Agents SDK, or commission the build. Where a developer tool turns into a business dependency is covered in when to outgrow Codex.

This is not a tutorial, deliberately. OpenAI's documentation explains the SDK better than we will. What it cannot tell you is whether your team should be the ones using it, and that is a commercial question about capacity, consequence and who owns the thing in eighteen months.

Start earlier than the SDK, though, because the first honest test has changed.

Check whether the subscription you already pay for does it

On 22 Apr 2026 OpenAI introduced workspace agents, which it describes as an evolution of GPTs, in research preview across ChatGPT Business, Enterprise, Edu and Teachers. Without an engineer, they run on a schedule, can be triggered from outside, run in the cloud while the user is offline, work in Slack as well as ChatGPT, connect to apps and custom MCP servers, keep memory of what they have learned, carry version history, and put write actions behind an approval that defaults to "Always ask". They can be shared across a team, handed to a new owner, and authenticated with a service account. On Enterprise they are off until an admin enables them.

Read that list against whatever prompted this decision. It has to run every morning. It has to run unattended. Five people need it, not one. Somebody must approve it before it writes anything. Those were engineering requirements in 2025. They are now configuration.

Two caveats. OpenAI has not declared workspace agents generally available, and the research-preview wording it launched with no longer appears in the help centre, so confirm the status before planning around it. And there is one hard boundary, stated in OpenAI's developer documentation as at 08 Aug 2026: "The agent's response cannot currently be retrieved through the API." You can start a run from another system. You cannot collect the answer programmatically.

That sentence is the dividing line. If the output only ever has to be read by a person, in ChatGPT or in Slack, you may not need a build at all, and anybody telling you otherwise should be asked why. If it has to land inside your CRM, your ERP or something a customer sees, in a shape another system can rely on, you have crossed into engineering. Note "currently": the line may move.

What you would actually be adopting

Assume you have crossed it. Three things make up the current stack, and it is worth knowing which is which before anyone estimates.

The Responses API is the base layer: send input, get output, with tool calling built in. The Conversations API holds multi-turn state on OpenAI's side rather than making you manage it. The Agents SDK is an open-source framework, in Python and TypeScript, that runs the agent loop for you, with handoffs between specialist agents, input, output and tool guardrails, resumable approval flows, sessions and built-in tracing. OpenAI puts the choice in one line: use the Responses API when you want to own the loop, use the Agents SDK when you want the SDK to run it.

One thing to catch before your team starts reading. The Assistants API retires on 26 Aug 2026. It was the previous way to build this, and much of the tutorial material your developers will find was written against it. If a proof of concept, an estimate or a supplier's proposal rests on it, it rests on a published end date.

None of this is hard for a competent developer, which is precisely why the decision gets made on the wrong evidence.

The first version is the cheap part

Teams estimate the build. The build is not the commitment. Five things follow it permanently, and they are where in-house agent programmes stall.

Evaluation. You need a set of real examples, including the ugly ones, with the right answer written down next to each, run before and after every prompt change and every model change. Without it, nobody can answer a straight question from your board: is this better than last month. One warning if you are scoping now. Do not let that harness be built on OpenAI's Evals product, because existing evals become read-only on 31 Oct 2026 and Evals shuts down on 30 Nov 2026. The test set belongs in your own repository anyway.

Observability. The SDK's tracing is useful while you are developing. It is not the same as knowing, in production, what the agent did, to which record, and whether it has stopped. You need your own logs, and alerts on the error rate and on volume falling to zero. A broken integration usually looks like silence, not errors.

Prompt and version management. Prompts are logic, and logic belongs in the codebase under review, with a history of what changed and why. OpenAI's own direction agrees: reusable prompt objects and the prompts API close on 30 Nov 2026, with the recommendation to move prompt content into application code.

Vendor deprecations. Every date in this post is an instance of the standing job. OpenAI publishes them well in advance, which makes this a diary entry rather than a crisis, but only if somebody keeps the diary: a named person reading the deprecations page quarterly and booking the work. A team that ships and moves on finds out from an outage.

An owner in eighteen months. The most expensive failure here is not technical. One developer builds it, it works, they are promoted or they leave, and nobody remaining will touch the prompt because nobody knows what it will break. Ask before the estimate, not after: who maintains this when the person who wrote it has gone.

The case for building in-house is real, and four things have to be true

When they are, a supplier telling you otherwise is selling.

You have capacity, not just capability. Capability is whether your developers could. Capacity is what stops being built while they do. Make somebody name the project that gets deferred, out loud, in the meeting. If nobody can name it, you do not have capacity.

The work is core and will keep changing. Anything touching your pricing logic, your product data or the thing you are genuinely good at should sit inside the building. Requirements there change monthly, and every change routed through a supplier carries a delay and a rate card.

You already run production software properly. Version control, code review, a staging environment, secrets in a secret manager rather than in code, someone on call. The Agents SDK asks nothing exotic of a team with all of that, and exposes a team without it, because an agent fails in a way a web application does not: plausibly, quietly, and in your customers' data.

You expect to build several. Then the first one is training with a deliverable attached, and paying for that internally is defensible. The SDK is open source and the concepts are portable, so what your team learns survives a change of platform.

The case for commissioning is about consequence and timing, not ability

It is your first one. The failure modes are well known but not obvious, and a team learns them by hitting them: matching a customer's free text against your own product data, the same input arriving twice and creating two records, the confident wrong answer nobody catches because it looks like a right one.

A wrong answer leaves the building. If a bad output reaches a customer, an order or an invoice, you are not paying for the learning in developer time.

There is a date that is not yours to move. Buying capacity is a legitimate reason on its own, and a better one than pretending the work is beyond your team.

The difficulty is not in the model. In most builds the agent is the straightforward half. The engineering there is not the reading. It is deciding what a line of a customer's text corresponds to in your product data, and what happens when it corresponds to nothing.

If you do commission, four things belong in the contract rather than in a conversation: the code sits in your repository, the OpenAI account and keys are in your company's name, the test set is handed over as an asset, and one named person inside your business owns it from day one. A supplier that resists any of the four is building itself a dependency.

The hybrid that usually works

For most businesses with some development capability, neither pure answer is right. A partner builds the first one to production standard, in your repository, with your engineers in the code reviews rather than watching a demo at the end. Your team maintains it, extends it, and builds the second one alone.

Make the handover a test rather than a document. One of your engineers changes a prompt, runs the test set, and deploys, with nobody from the partner in the room. If that works, the handover happened. If not, it did not, whatever the documentation says. That arrangement is worth less to a supplier than an open-ended retainer, which is why you should propose it and watch the reaction.

The six questions that settle it

Right-hand column on the middle four and left-hand on the last is the hybrid.

The decision in front of you

Three questions, in this order. Does a workspace agent on your existing plan already cover this. If not, who owns the result in eighteen months. And what will not get built if your developers take this on. You can answer all three without an engineer in the room, and they decide the outcome more reliably than any view of how good the SDK is.

For how this sits against the alternatives, see the full guide to OpenAI for UK businesses.

We are an OpenAI Select Partner and this is work we take, so weigh the next sentences accordingly. We do not resell licences and we do not mark up your usage, so we gain nothing from you buying more platform than the problem needs, and the same reasoning applies whichever model you run, which is why it sits under AI implementation. If a workspace agent covers your case, we will say so and there will be no invoice. If it does not, request a quote and tell us what the agent has to do and who is asking for it, or read what a production build involves on our OpenAI implementation page. If what you have is a demo that impressed people, the stage before this one is what breaks between a ChatGPT prototype and production.