What the OpenAI API does that ChatGPT cannot: a guide for operations leaders

Somebody in your business wants ChatGPT seats. Somebody else, possibly a supplier, says seats will not be enough and you will need to build something on the API. Both are asking you to sign off on a number, and the two numbers are not remotely alike.

You have not built anything yet, so this is not a technical question. It is a question about what you are committing to: a monthly licence bill, or a project with a specification, a budget and an owner. What follows is what each option gets you, where each one stops, and how to tell which side of the line your work sits on before anyone quotes you.

This has three answers now, and most articles still give two

The familiar version of this comparison says the API can run unattended, on a schedule, triggered by your systems, while ChatGPT needs a person sitting in front of it. Until recently that was fair. That framing is now wrong, and any proposal that still relies on it is out of date.

On 22 Apr 2026 OpenAI introduced workspace agents in ChatGPT, describing them as an evolution of GPTs. They run on schedules, they can be triggered from other systems, they work in Slack, they keep going when nobody has ChatGPT open, and they are configured by whoever owns the process rather than by an engineer. A large amount of what used to justify a build now sits inside a subscription. A method for sorting a whole process list against these tiers is in ChatGPT for operations leaders.

So the decision has three tiers, and the useful discipline is to climb them in order.

Tier one: seats buy individual work, done with a person present

A ChatGPT seat is a tool for a person. They open it, ask for something, read what comes back and decide what to do with it. Drafting, summarising, questioning a document, working through an analysis. That is a large amount of useful work for a licence, with no project and no maintenance. Custom GPTs extend it, letting somebody package instructions and reference material into a reusable version for their team.

The boundary is one sentence. Nothing happens unless a person makes it happen, and that person is quietly doing all of the error handling: noticing the odd answer, fixing the formatting, deciding not to use the one that looks wrong. None of that is written down anywhere, which is why removing the person is a bigger change than it sounds. If you already have Custom GPTs in use and are being told they are not enough, the practical difference between a Custom GPT and a built agent covers that case.

Tier two: workspace agents go further than most people realise

This is the rung most buyers do not know exists, and it is where a good deal of the work people commission builds for now lives. A workspace agent is created and published by a person in your business, in the product, without engineering. From OpenAI's own documentation, one can be configured to:

• Run on a schedule you set, when someone mentions it in a Slack channel, or when another system calls its API trigger. It runs in the cloud, so it continues when nobody is logged in.
• Connect to apps such as Google Drive, Google Calendar, Slack and SharePoint, plus web search, plus your own MCP server if you have one.
• Ask for approval before write actions, which is the default, tightened to specific actions or relaxed per app. A builder can also constrain what the agent is permitted to ask a connector to do.
• Authenticate as the person running it or as the agent itself, with OpenAI recommending a service account rather than somebody's personal login for the shared case.
• Be previewed and tested before publishing, keep version history, and be rolled back to an earlier published version.
• Have named owners and editors, be shared with workspace groups, and have ownership transferred.
• Report usage through an analytics page, and on Enterprise be visible to admins through the Compliance API, including the ability to suspend an agent.

Read that list against whatever you were about to commission. Scheduled reporting, triaging an inbox, chasing a weekly process, drafting responses for someone to approve, pulling a briefing together before a meeting: a good proportion of these are tier-two jobs, and the honest answer is to build one and see.

Two practical notes. Runs are metered on a credit-based model rather than included flat, so confirm current terms with OpenAI before planning volume. And agents are off by default for Enterprise workspaces until an admin enables them, which is often the real reason a business believes it cannot do this.

If a pitch you have received rests on "ChatGPT cannot run on a schedule", it describes the product as it was, not as it is.

Tier three begins at six specific places, and the first one is sharp

There is still a real boundary. It is narrower than it was, and worth stating precisely, because vague warnings about scale and robustness are how unnecessary projects get approved.

You can start an agent from your systems. You cannot get its answer back. This is the sharpest line available and it sat in OpenAI's own documentation when we checked on 08 Aug 2026. Trigger a workspace agent through its API and the call queues the run and returns 202 Accepted with a link to the resulting ChatGPT conversation. Run status polling is in beta: send the beta header and you also get a run identifier and an endpoint reporting whether the run is queued, in progress, suspended, completed or failed. What you do not get, in OpenAI's words, checked 08 Aug 2026, is the answer: "the agent's response cannot currently be retrieved through the API".

Sit with that if you own a process. You can set one of these off from your CRM, and you can now find out whether it finished. You cannot receive what it produced, so nothing downstream can act on it automatically. That gap is the difference between an agent that helps a team and a system that runs a process end to end.

Enforced structure when writing to a system of record. A connector can write, with an approval step, and for many jobs that is fine. It is not fine when the destination has rules. Structured Outputs makes the model's response conform to a JSON schema you define, so it cannot omit a required field or invent a value outside your list of allowed options. Put practically: your CRM's stage field accepts eight values, and you need a ninth to be rejected rather than paraphrased into something plausible.

Output that is the same on Tuesday as it was on Monday. In tier two, testing means someone trying it in preview and forming an opinion. If a wrong answer costs money or credibility, you need real examples with the right answers written down, run automatically before any change goes out. That is a software practice and it needs somewhere to live.

Systems the connectors do not reach. Your ERP, your warehouse system, the internal database that runs pricing. A workspace agent can use a custom MCP server, which genuinely closes this gap, but somebody has to build, host and secure that server. The gap is closable, and closing it is a build.

An audit trail you own rather than one the vendor scopes. Analytics tells you how many runs there were. The Compliance Platform gives admins real visibility, and it is available to Enterprise and Edu customers only, not to self-serve ChatGPT Business. If you have to show a client, an auditor or a regulator what was decided on what input, you want that record in your own store, on your own retention schedule.

Cost shaping once volume is real. At a few hundred runs a month this does not matter. At scale three levers do: routing simple tasks to a cheaper model rather than the most capable one, structuring prompts so repeated context hits the cache instead of being re-processed, and pushing anything nobody is waiting for through the Batch API. You can only make those decisions when you control the calls, and they are covered properly in taking a ChatGPT prototype into production.

What each tier commits you to

The test, and it is shorter than you expect

Take the actual job, not the category, and work down.

1. Is a person going to read the output and decide what to do with it? Buy seats. You are finished.
2. Does it need to happen on a schedule or on an event, with nobody there, and a human approving anything it writes? Build a workspace agent. This is the case that used to justify a project and mostly no longer does.
3. Does another system have to receive the result and act on it, must the output land in a system of record with enforced field values, must the same input give the same output every time, do you have to prove afterwards what it did, or does it reach a system no connector covers? Any yes and you are in tier three.

The sentence worth taking away: most businesses should exhaust tier two before commissioning anything. Not because engineering is poor value, but because a project you did not need is the most expensive thing on this page, and the cheapest way to write a good specification is to run the cheap version first and find out exactly where it fails.

What to do next

We are an OpenAI Select Partner and we build on the platform. We do not resell licences and we do not mark up your usage, so we have no financial reason to push you up a tier, and we run the same work model-neutral when the right answer is a different vendor or the AI already inside software you pay for. More of these conversations end with "publish a workspace agent and give it a month" than end with a build.

For the full range of options open to a UK business, see our overview of what OpenAI offers.

If you have worked down the three questions and landed in tier three, the next step is a specification, not a project: what triggers it, what it writes, what happens when it is not confident, and what you need to prove six months later. To have that scoped, including a straight answer on whether your subscription already covers it, request a quote or read how we approach OpenAI implementation.