Replacing a ChatGPT workaround with a properly engineered integration

Somewhere in your business there is a thing nobody planned. A chain of triggers stitched between two applications, with a model call somewhere in the middle, that reads something and writes something, and has been doing it for months.

It works. Mostly. It breaks when someone renames a field, or edits a template, or volume spikes at month end. Somebody notices, somebody restarts it, and everyone moves on. It is in no system diagram, it is in no budget line, and if you asked who owns it you would get a name followed by "well, sort of".

The uncomfortable part is not that it is fragile. It is that the business became dependent on it without ever deciding to.

This is about what to do with that. Not all of them should be replaced, and the test for which ones should is shorter than you would expect.

These got built because they were the right call at the time

Start here, because the alternative framing is both unfair and wrong.

Whoever built that chain did the business a favour. They had a real problem, engineering time was not available for it, and they found a route that took days instead of months. It very likely paid for itself inside a quarter. Judged as what it was, a cheap experiment against a real cost, it was a better decision than the meeting about it would have been.

What nobody did was revisit it once it stopped being an experiment. There is no moment at which one of these is formally promoted. It simply accumulates dependants: a report that assumes it ran, a team that no longer has the manual version in living memory, a customer commitment that only holds if it fires. By the time anyone asks whether it is fit for purpose, that question was settled months ago by everyone who quietly started relying on it.

So the question is not whether it was a mistake. It is whether what it now carries is more than what it was built to carry.

Seven failure modes, and you can check for every one of them this afternoon

Vague warnings about robustness are how unnecessary projects get approved. Here is the specific list. Most of these you can check yourself, without an engineer in the room.

It fails silently, and there is nothing to check afterwards. The failure signature is not an error message. It is nothing happening, and nobody sets an alert for the absence of work. Ask when it last ran and how you know. If the answer is opening the tool and squinting at a recent-activity list, you cannot answer the same question about last quarter at all.

A rerun creates duplicates. When something stalls halfway, the recovery is to run it again. Nothing on either side knows the first attempt already wrote half its records, because nothing carries a key saying "this event has been handled". You get two records, two notifications or two orders, and the clean-up is manual and undercounted.

A transient failure becomes a permanent one. A system is briefly unavailable, a request times out, an API returns a rate-limit response. OpenAI returns a 429 when a request exceeds a temporary rate limit, with guidance to wait at least as long as the Retry-After header says and "add a small random delay so multiple clients don't retry at the same time". A chain with no retry logic treats all of that as failure and drops the work. It is not wrong often, and when it is wrong nothing reports it. The patterns that make that reliable are set out in OpenAI API patterns for CRM work.

Any upstream change breaks it. A renamed field, an added picklist option, an edited email template, a supplier changing their attachment layout. The chain has no contract with any of those systems and no test that would catch the change. Whoever makes the change has no idea it exists, so better communication will not prevent this.

The credentials belong to a person. The connections were authorised with somebody's login, quite possibly their own personal account. That fails twice: it does not survive a security review, and it stops working the day they leave. It also means their access, not the process's, is what the chain can reach.

The bill tracks volume rather than value. Per-operation pricing was cheap at prototype volume and does not stay cheap. The busiest month becomes the most expensive month, and nobody is watching for the point at which owning the code costs less than renting the operations.

Every change is tested in production. There is no staging copy. Someone edits the live thing, watches the next real run, and hopes. Tolerable when the blast radius is a summary in a channel. Not tolerable when the next real run writes to your CRM.

The test is what happens when it stops, not how it was built

Plenty of these chains are fine and should be left exactly where they are. To tell which, stop assessing the build quality, which is not the point, and assess the dependency instead.

Five questions. Answer them about a specific chain, not about the category.

Benign on all five and you are done. A chain that pulls a weekly summary into a channel, where a wrong or missing answer is obvious and harmless, is a productivity tool. Industrialising it will cost more than it returns, and the version that survives a security review will be more annoying to use than the one you have. Leave it alone.

Two or more problem answers and it is not a workaround any more. It is infrastructure that was never treated as infrastructure, and you are already paying for that in interruptions and manual clean-up rather than in a budget line anyone can see.

Check what your subscription already does before anyone quotes you

This is the step most articles on this question are too out of date to include, and skipping it is how businesses commission projects they did not need.

On 22 Apr 2026 OpenAI introduced workspace agents in ChatGPT, describing them as an evolution of GPTs. They are configured by whoever owns the process rather than by an engineer, and they close more of the list above than most buyers expect:

• They run on a schedule, on a Slack mention, or on an API trigger from another system, and they run in the cloud, so they keep going when nobody is logged in.
• They connect to apps, and to your own MCP server if you have one.
• Write actions default to asking for approval.
• They have version history and a preview to test against, so a change is not automatically live.
• They have named owners and editors, ownership can be transferred, and OpenAI recommends a service account rather than an individual's login for a shared agent.
• On Enterprise, the Compliance API gives admins visibility into an agent's configuration and runs, and lets them suspend one.

Read that against your seven. Two of them close outright: changes get previewed and versioned rather than tested live, and the credentials become a service account with a transferable owner rather than one person's login. The ownership problem goes with them, because an agent has named owners and editors by default. The trigger endpoint also accepts an optional Idempotency-Key header, so retrying the same event returns the original outcome instead of queuing a second run, which is precisely the property your current chain lacks.

Be equally clear about what it does not fix. Retry and backoff against your own systems, brittleness to an upstream field rename, and an alert when nothing happens at all are all still yours to solve.

Two practical notes. Runs moved to a credit-based model on 06 May 2026, so confirm current terms with OpenAI. And agents were off by default for Enterprise workspaces at launch until an admin enabled them, which is often the real reason a business believes it cannot do this.

There is a real limit, and it sat in OpenAI's own documentation when we checked on 08 Aug 2026: "The agent's response cannot currently be retrieved through the API." You can start one from your CRM and confirm it ran. A person can read what it produced in ChatGPT, but your systems cannot collect it, so nothing downstream can act on it automatically. If your chain ends with a person reading something, that does not touch you. If it ends with a system receiving a result, it rules the option out. The fuller version of this decision is in what the OpenAI API does that ChatGPT cannot.

What an engineered integration adds, and almost none of it is the model

If the five questions came back badly and a workspace agent cannot reach where the output has to land, this is what you are actually buying. It is worth being concrete, because "we will build it properly" is not a specification and should not be priced like one.

Idempotency. A key derived from the source event, checked before anything is written, so the same event cannot produce two records however many times it is retried. This is the largest practical difference and it is invisible in a demo.

Retries with backoff and jitter. A rate-limit response or a timeout triggers an automatic retry, spaced out and slightly randomised, rather than being logged as a failure and forgotten. Transient problems stop being data loss.

Errors that reach a person. A structured error, with the failing input attached, delivered somewhere a human is already looking. Alert on the error rate, and separately on throughput falling to zero, because that is what most breakages look like.

An enforced output shape. Structured Outputs makes the model's response conform to a JSON schema you define, so a value outside your allowed list is rejected rather than paraphrased into something plausible and saved.

A test path and version control. The code lives in your repository, and OpenAI's own production guidance is to run separate projects for staging and production so development work cannot disrupt the live application. Changes get tested somewhere that is not your CRM.

Credentials that are not a person. Keys in environment variables or a secret management service rather than in code or a public repository, a service identity rather than an individual's login, and per-project spend limits and alerts set on day one.

A log you can reconstruct an incident from. Every run, with its input, its output, the model used and the outcome (written, rejected, or escalated to a person), kept long enough to answer a complaint six months later.

Notice how little of that is AI work. This is ordinary integration engineering, which is why a credible estimate for it is mostly not about the model, and why an estimate that is mostly about the model should worry you.

Swap it in parallel, never overnight

The replacement does not need a cutover weekend, and it should not have one.

Build the new integration to read the same trigger and produce the same output, and have it write nowhere real. Then run both over live traffic for a period, and compare the two outputs on every event.

The disagreements are the valuable part. Each one is a rule the old chain was applying that nobody wrote down, or a case the new build has not been told about. Investigate every one rather than counting them, because that list is the specification you never had.

When they agree consistently, move traffic across, ideally a segment or a source at a time rather than all of it. Keep the old chain switched off rather than deleted until you have been through at least one month end, because that is when the odd cases arrive.

One rule while both are running: only one of them writes. Two systems writing to the same destination is the duplicate problem you are trying to solve, running at twice the volume.

What to do next

Make the list first. Most businesses cannot name all the chains they depend on, and if that describes you, that is the work to do before any of the rest of this, along the lines set out in how to audit the shadow AI already happening in your business.

Then take only the ones that touch money, customers or a system of record, and run the five questions on each. Most will come back benign, and leaving those alone is the correct answer, not a deferral. Of the rest, a fair proportion are a workspace agent and an owner's name, which costs a subscription you may already hold. What survives both filters is a short list, and a short list is something you can get costed properly.

If you are earlier than this and still weighing the options, start with what ChatGPT and the OpenAI API actually do for a UK business.

We are an OpenAI Select Partner and this is the work we do, which is a good reason to discount this paragraph. So judge it against the shape of the post: the recommendation is that most of these should be left where they are, and a fair number of the rest are a configuration change rather than a project. Nothing we recommend earns us a margin on your platform spend, so nothing we recommend about tier, model or architecture moves our revenue. Project size does, which is why the test above is written to be run without us. If you have a chain that answers badly on two or more of the five questions, request a quote and tell us what it does and what stops when it stops, or read how we approach OpenAI implementation.