Codex: when a developer tool becomes a business dependency

Somewhere in your business there may be a process that matters, running on a subscription in one developer's name. The configuration sits in their home directory, the prompt that makes it work is in their head, and it runs under their seat. Nobody decided this. It grew, because it worked.

That is the situation worth finding, and it is a different problem from the one people usually ask about. The usual question is whether a tool that works well should be turned into something bigger: your developers have been using Codex for months, pull requests come back faster, the review backlog is shorter, and somebody senior has asked whether the business should commission something proper, something it owns rather than something the developers use. The build-or-commission decision itself is set out in OpenAI's Agents SDK: build in-house or hire it out.

It is a fair question asked in slightly the wrong shape. It treats a custom build as more Codex, the same thing but larger and with an invoice attached. They are two different purchases, with different users, different budgets and different lifespans, and almost every muddled conversation on this subject starts by treating one as an expensive version of the other.

Codex covers more than most people commissioning a build realise

Start generously, because for a good number of readers the honest answer is that they already have what they need.

Codex is a product, not a model. It is OpenAI's agentic coding system, and it runs across several surfaces that share one backend: a terminal CLI, extensions for VS Code and JetBrains, a desktop application, a cloud mode that runs tasks asynchronously in isolated containers with your codebase preloaded, and a code-review capability you can point at a branch or a single commit. Underneath, it mostly runs the same frontier models as the rest of the platform, which is why quoting a Codex "model version" in a procurement paper is a reliable way to date the paper within a quarter. (And if a colleague forwards you the Codex Micro, that is a physical keyboard accessory OpenAI launched on 15 Jul 2026, not a cheaper tier of the software.)

It is also governed, which people tend to assume it is not. Inside a ChatGPT Business workspace, Codex sits under the same workspace-level admin controls as standard seats.

One commercial detail is worth getting right. From 24 Jun 2026, Codex-only seats closed to new ChatGPT Business workspaces and to any existing workspace that had not already added one. That sounds like a door shutting and mostly it is not: standard ChatGPT seats include Codex access, so a new Business workspace still gets Codex. What it cannot buy is the usage-billed Codex-only seat for people who never touch ChatGPT. The change is to how you buy it, not to whether you can.

So if the problem you are solving is that your developers ship too slowly, that code review is the bottleneck, or that the security backlog never gets touched, that is the tool's own job description. Buy the seats, stop reading, and spend the project money on something else.

The difference that matters: one accelerates people who write software, the other is software that runs your process

This is the distinction that settles most of these conversations, and it is not a matter of scale.

Read that as two columns rather than two rungs of a ladder. A build is not a bigger Codex, and Codex is not a cheap build. It follows that the two coexist rather than replace each other: when you commission software, the engineers writing it will almost certainly use Codex to write it, and nothing about that changes on the day the project starts.

That also settles how to price the decision. Put a project quote next to a per-seat cost and the project looks indefensible. Put the seat cost next to a system that removes a daily process and the seats look like a bargain, for a problem they were never pointed at. Neither comparison tells you anything, because the two are not substitutes.

Before you commission anything, check whether a workspace agent already does it

A large part of the traditional case for building was that the work had to run unattended, on a trigger, with approvals. A subscription now covers a good deal of that, so check it before anyone, this firm included, makes the case for engineering.

OpenAI introduced workspace agents on 22 Apr 2026 and describes them as an evolution of GPTs. Per OpenAI's own documentation for ChatGPT Business, Enterprise, Edu and Teachers as announced on 22 Apr 2026, an agent can be built and tested before publishing, given a chosen model and reasoning effort, connected to apps and to custom MCP servers, shared with a team or published to an organisation directory, run on a schedule, added to a Slack channel, and triggered through an API. Write actions to connected apps default to asking for approval during a run. Builders can narrow what a connector is permitted to do. An agent can authenticate as the person running it or through a shared agent-owned account, for which OpenAI recommends a service account rather than an individual's login. On Enterprise they are off until an admin enables them, and the same role-based access controls apply inside Codex's own Workspace Agents plugin.

Read that list against whatever you were about to commission. Schedules, triggers, approvals, shared ownership and a Slack front door are configuration now, not engineering.

One boundary is worth knowing precisely, because it decides a good proportion of these cases. OpenAI's help centre and its developer documentation disagreed, when we checked on 08 Aug 2026, about what the API trigger returns, so take only the sentence both of them carry: "The agent's response cannot currently be retrieved through the API." You can start a workspace agent from your CRM. You cannot collect its answer back into your CRM. If the output has to land in a system rather than in a conversation, that is where the subscription stops and engineering starts. Note the word "currently", and check the page before you decide.

Six signals that the work has outgrown a developer tool

None of these is a criticism of Codex. Each is a property of the work, and a reason the work needs to live somewhere other than a developer's machine.

1. It has to run unattended, on a schedule or a trigger. Apply the workspace-agent test first. If the answer still has to arrive inside a system rather than a conversation, you are building.
2. People who are not developers have to use it. Codex assumes a repository, a terminal or an IDE, and somebody who can read a diff. Any sentence that ends "and then the ops team runs it" describes a different product.
3. The output has to be written into a system of record, with its structure enforced. Today a person is quietly doing the error handling: noticing the odd one, fixing the formatting, deciding not to paste it. Nobody wrote that job down, and it does not survive being automated away.
4. You need an audit trail. Who ran it, on what input, what it changed, and whether you can still answer that in a year for a complaint, an auditor or a client security review.
5. The same input has to produce the same output. Once people start checking every result by hand because they cannot predict it, the saving has already gone.
6. It is load-bearing, and it still lives on individual machines. The configuration is in one person's home directory, the prompt that makes it work is in their head, and it runs under their seat. That is a business process with a bus factor of one, and the risk is organisational rather than technical.

One or two of these firing is not a build. Four or five, and you are already dependent on something nobody owns.

The counter-case: buying a build to replace a tool people like

Commissioning software to replace a flexible tool that developers use happily is one of the more dependable ways to spend money and end up with less. The build does one thing, in the way it was specified in month one, and needs a change request to do anything else. The tool it displaced did whatever was asked of it, that afternoon.

Do not build when:

• The process is still changing month to month. You would be casting a draft in concrete, and paying to do it.
• One team uses it and adapts it constantly. The adapting is the value. Fixing it removes the thing that works.
• The value sits in the judgement of the person driving it, not in the output. You would be automating the easy half.
• Nobody can write down what a correct answer looks like. If you cannot state the acceptance test, you cannot commission the build, and a supplier who takes the work anyway is not doing you a favour.
• The real problem is the data or the process. Software runs a bad process faster and produces confident answers from bad records, which is worse than an error because an error gets noticed.

Price the whole life rather than the project, too. A build has an owner, a maintenance line, and a platform underneath it that moves and deprecates on its own schedule. A subscription you can stop paying for next month has none of that.

What commissioning a build actually involves

Briefly, because it is a longer subject than this post. It means a defined piece of software that lives in your repository and your cloud account, runs on keys the company owns, enforces the structure of its own output, sends anything it is not confident about to a person, logs enough to investigate a complaint, and has one named owner. It also means a test set of real examples, including the ugly ones, so the next platform change is an afternoon's verification rather than an act of faith.

What tends to break on the way there is set out in what actually breaks between a ChatGPT prototype and production. What it costs in the UK is in what an OpenAI integration costs. How to tell a supplier who will build it from one who will demo it is in choosing an OpenAI implementation partner.

The decision in front of you

Take the three questions in order, and stop at the first yes.

1. Is the problem that your developers are slow? Then it is a seat, not a project.
2. Does a workspace agent do the job, including getting the answer to where it needs to end up? Then turn it on, set the write approvals, and give it an owner.
3. Do four or more of the six signals fire, and can you write down what a correct output looks like? Then commission the build, and scope it around the writing and the audit trail rather than around the model.

If none of the three lands, leave it alone. A tool your developers like, that costs a monthly fee and can be cancelled, is a respectable end state. Revisit it when the work changes shape.

There is one exception worth acting on regardless of the three. If a process the business depends on is running under one person's seat, on their machine, with the working knowledge in their head, that is not a tooling question and it does not wait for a budget cycle. Find out whether you have one. The answer takes an afternoon and it is the cheapest risk assessment available to you.

This is one rung of a longer ladder, set out in our overview of OpenAI for UK business.

We are an OpenAI Select Partner, and a firm that builds this kind of software has an obvious interest in your answer being the third one, so judge that on how we behave rather than on the paragraph. We resell nothing and take no margin on your usage, so a workspace agent that removes the need for a project costs us a project and saves you one. If you want the call made on evidence, request a quote and tell us what your developers are doing with Codex and who is asking for it to be made permanent, or read what a production build involves on our OpenAI implementation page.