Quick thing before we start. If you have been nodding along to the coverage this week thinking, well, that's an enterprise problem, that's somebody else's workspace, I want you to sit with that for a second, because it isn't.
It really isn't.
Daniel's been running a personal prompt-preprocessing setup for a while now. The one that takes his rough, context-heavy drafts and restructures them before they ever reach the production feed. Him and Hannah both send prompts in through a web form he built, and it infers the sender name from the login state, so it knows who's talking without anyone typing it.
Which is a nice little touch, to be fair.
It is. And he's been experimenting with a Custom GPT sitting in front of that. Take what I'm asking, order it for structure, keep it optimized for a thirty minute informative conversation, and crucially, separate the actual questions from the introductory context he tends to open with. He even flagged the caveat himself, we've been over the perils of negative instructions before, but he says for the most part it works.
Except for the part where it doesn't.
Right, and that's the interesting bit. The failure mode he describes is ChatGPT piling extra questions on top of what he actually asked. Which means the prompts with nested sub-questions? Those are the AI-generated ones. That's not a bug in his setup, that's the setup doing exactly what he told it not to do.
That's a good detail, actually.
So here's where he lands. He'd discounted Custom GPTs entirely in the era of agentic AI and MCP, figured they were just a nice container for a system prompt and a lightweight retrieval store, and he always assumed the product would get discontinued as agents eclipsed the simpler configurations. But it's still got traction on the website. And he realized nothing stops him from extending the GPT with an Action that invokes the authenticated webhook that kicks off the generation pipeline. He tried a Telegram bot for dispatch once. Called it brittle and unreliable, which is putting it kindly. So the question he's actually asking is whether a Custom GPT with an Action is a good fit for this back-and-forth, refine, confirm, then dispatch workflow, or whether some other straightforward agentic interface does the job better.
And he's expecting us to say the product's getting discontinued anyway.
He is.
Well.
Yeah. Before we get to whether this is a good idea, we should be precise about what a Custom GPT actually is and what an Action actually consists of, because the whole answer turns on those mechanics.
Start with the container. A Custom GPT is a saved configuration. You write a system prompt, you attach reference files, which is a lightweight retrieval store, nothing fancy, and then optionally you bolt on Actions, which are the part that lets it talk to the outside world. And you get a shareable surface on the ChatGPT website, which is why people treat them like little apps.
The Action itself has two components.
Two, and people conflate them constantly. First is the authentication method. You get four options. None, which is what it sounds like. An API key, which can go in as Basic auth, Bearer, or a custom header. Or OAuth, which is the full dance, client ID, client secret, authorization URL, token URL, scopes. The second component is the OpenAPI schema, which is just a description of the endpoint, what it takes, what it returns, so the model knows how to call it.
And then the platform constraints, which are the part that bites people.
Every Action call has to go over TLS 1.2 or higher on port 443, with a valid public certificate. No self-signed nonsense. And custom headers are not supported, except for a handful of providers, Google and Microsoft being the main ones. So if your webhook expects a bespoke header for routing, that's a wall.
There's also the apps versus actions thing.
A GPT can use either apps or actions, but not both at the same time. And Actions are not available in Pro mode, so the moment you configure one, the model selector drops to non-Pro models only. That's a real limitation if you care about which model is doing your preprocessing.
So the surface is well-defined. It's a system prompt, a lightweight file store, and a schema-described call out to an authenticated endpoint.
That's the surface as it's been.
Here's the thing. The surface moved, and it moved recently.
It moved about eleven days ago, depending on which document you read.
Walk it.
September eleventh, OpenAI sends an admin notice to Enterprise workspaces, and the release notes say they're planning to retire custom GPTs across ChatGPT plans and provide a migration path to plugins. September seventeenth was the target date for the migration experience and the user banner in affected Enterprise workspaces, and that's labeled a target, not a guarantee, so don't treat it as gospel. September eighteenth, PCWorld runs a piece titled, Custom GPTs in ChatGPT are going away, here's how to save yours. And the Help Center now says, flatly, we're planning to retire custom GPTs and help you build on the workflows you've already created. Instead of custom GPTs, we recommend moving your workflows to Plugins.
So Daniel's instinct was right.
Daniel's instinct was right, and that's the problem.
Give me the hard date.
December eleventh, for affected Enterprise workspaces. And September twenty-fifth is when new Custom GPT creation ends for Enterprise workspaces. Those two dates are real and they're published.
Now here's where every headline goes wrong.
Every headline goes wrong in the same way. The FAQ says the transition affects all ChatGPT plans, and that other plans are expected to follow the same timeline. Expected. No retirement date has been published for Free, Go, Plus, or Pro. So if you read a piece claiming your Plus account's GPTs die on December eleventh, you're reading the Enterprise schedule and generalizing it. That's the single most common error in the coverage right now.
Which is cold comfort, because there's a second piece of news that's sharper.
There is. New GPT creation and publishing is already closed to personal accounts. OpenAI's docs say it plainly. New GPT creation and publishing are not available on personal ChatGPT accounts, including Free, Go, Plus, and Pro. Only Business, Enterprise, and Edu workspaces can create or publish, and only where admin settings allow.
So the thing Daniel wants to do, extend his existing GPT with a new Action, hinges on something he needs to verify before he writes a single line of schema.
Whether he can even modify the actions on his existing GPT depends on his plan and his permissions. That's the first thing to check. Not the architecture, not the auth flow. Can you edit the thing today.
And the deeper problem. What happens to the Action when the product goes?
This is the part that turns it from a sunset into a downgrade. Instructions transfer as a skill inside the new plugin. Connected apps transfer. Custom actions do not transfer. OpenAI's own words, GPT custom actions do not transfer through the migration workflow, and the person maintaining the workflow will need to assess and rebuild required integrations using a supported connector or custom MCP server.
Say the last part again, slower.
Rebuild. Using a supported connector or a custom MCP server. That's not a migration, that's a rewrite with extra steps.
There's more.
There's more, and it's all small and it all compounds. Conversation starters and previous chats may not copy over. The selected model does not carry over. The replacement plugin starts private, so you have to re-share it. And the original GPT becomes read-only after migration, and the creator cannot delete it. You get a museum piece you can't touch and can't remove.
So the one component Daniel's entire workflow depends on, the authenticated webhook Action, is the one component confirmed not to migrate.
That's the irony. The lightweight engineering surface was the appeal. The lightweight engineering surface is what's being removed. And the migration path pushes you toward more engineering, not less.
So the format is sunsetting and the Action doesn't survive migration. That leaves the real question. What does the successor look like, and does it actually fit this workflow?
The sanctioned successor is MCP. ChatGPT has been a full MCP client since late 2025. You add custom MCP servers through Developer Mode as connectors or apps, and that's paid plans only. Free accounts cannot add custom connectors, full stop.
And the rollout state matters here.
It does. Full MCP support, including write and modify actions, is rolling out in beta to Business, Enterprise, and Edu. Pro users can connect MCPs with read and fetch permissions only, so no writes. And ChatGPT connects to remote MCP servers over HTTPS, not local stdio ones. There's a Secure MCP Tunnel for private-network servers if you need it.
Here's the detail that should sting for this specific workflow.
MCP apps are web-only. Not mobile.
Hannah uses the form from her phone.
She uses the form from her phone. So the mobile dispatch experience Daniel values may not survive the transition to MCP apps at all. That's not a footnote, that's a functional regression in the exact thing he's trying to preserve.
There's a counterweight, though, and it's a big one.
Confirmation before action is now a first-class platform feature. Both GPT Actions and MCP write actions trigger confirmation prompts. The docs say ChatGPT may ask for confirmation based on app permissions and the action's context. So the gate Daniel wants, the that's great, let's send it moment, is natively supported. He doesn't have to build it.
Which strengthens the case for some agentic interface even as the specific one he picked sunsets.
Right. The architecture instinct is sound. The container is the problem.
Now the negative instructions thing, because he raised it himself and I think he undersells how shaky it is.
He does. The canonical finding is a 2022 paper, Jang, Ye and Seo, Can Large Language Models Truly Understand Prompts, a case study with negated prompts. And the result is uncomfortable. Larger language models perform worse on negated prompts. It's an inverse scaling law. They tested across nine tasks and model families, OPT, GPT-3, InstructGPT, few-shot setups, even models fine-tuned on negation.
Worse as they get bigger.
So the intuition that don't do X is a weak instruction isn't folklore, it's measured. And the inference for Daniel is rough. His don't add any additional questions instruction may get less reliable as models grow, not more.
Which is exactly backwards from what everyone assumes about capability.
Exactly backwards. The fix is positive framing. Instead of don't add questions, you write preserve exactly the questions asked. Same intent, framed as a thing to do rather than a thing to avoid. Small rewrite, real reliability argument behind it.
And the failure pattern he described, the nested sub-questions showing up in his prompts, that's the inverse scaling result wearing a hat.
That's what it looks like in practice. The instruction is there, the model is bigger than the one it was written for, and the negation just doesn't bind the way he expects.
It's worth pausing on how counterintuitive that is, though, because I think people hear it and file it under trivia.
File it under things that cost you a weekend. Here's the mechanism as best anyone can tell. A negation is a modifier that has to be held in working memory and applied to a candidate output. The model has to generate the thing, recognize it's the forbidden thing, and suppress it. That's three steps where a positive instruction is one. And the bigger the model, the more fluent and confident its generation is, so the candidate it has to suppress arrives more fully formed. The suppression step doesn't scale with the generation step.
So capability outruns constraint.
Capability outruns constraint. Which is why you see it in the wild as, the model did the exact thing I told it not to do, and it did it beautifully.
And this isn't unique to Daniel's setup.
Not remotely. Anyone who's written a house style guide as a list of don'ts has the same exposure. Don't use the passive voice. Don't open with a question. Don't exceed three paragraphs. Every one of those is a candidate for the same failure, and every one of them gets shakier as the underlying model improves.
So what's the alternatives landscape? He asked directly.
ChatGPT Projects holds custom instructions plus reference files and keeps related chats together. PCWorld recommends it as the personal-user fallback. The limitation is that chats created with a GPT cannot be moved into a project, so there's a wall there too. Claude Projects adds a built-in scheduling tool, and Gemini Gems is the other cross-vendor equivalent. Those are the three containers.
And n8n, which he raised himself and pre-emptively called too much architectural uplift.
He's not wrong that it's uplift. But there's a template he should know about. OpenAI's own cookbook documents a Retool Workflow GPT Action that sends the request to the workflow in Retool using a webhook trigger and returns JSON to ChatGPT. That's a direct template for his dispatch pattern. And there's a community write-up on connecting Custom GPT Actions to internal APIs via OAuth2 and n8n, with a warning attached. The webhook must treat every field from the GPT as untrusted input.
That warning deserves a beat.
It deserves more than a beat. The model is generating the payload. If you're wiring an authenticated webhook that starts a generation pipeline, and the fields coming in are model-authored, you validate them like they came from the open internet, because functionally they did.
There's security context that belongs in this conversation too.
September tenth, there was a report on a ChatGPT flaw that let attackers hijack a victim session. A cross-account data leak. That's relevant for anyone wiring authenticated webhooks into ChatGPT. Not because it's the same mechanism, but because it's the category of risk you're accepting when the call originates from inside a session.
And the strategic backdrop, which I think is the real story here.
Workspace Agents. Launched April twenty-second, Codex-powered, cloud-run, with Slack, Salesforce, and Notion integrations. OpenAI described them as an evolution of GPTs. Free until May sixth, then credit-based pricing. And OpenAI said, soon, we'll make it easy to convert GPTs into workspace agents.
An evolution of GPTs, said out loud, months before the retirement notice.
Months before. So this wasn't a surprise internally. The direction was announced in April and the retirement paperwork showed up in September.
So here's where I land, and I want to be honest about the shape of it rather than turn it into a to-do list.
Go on.
A Custom GPT with an Action is a good fit for the workflow Daniel described. The confirmation gate, the back-and-forth, the lightweight surface, all of it lines up. It's a fit with an expiration date, and the migration path drops the exact component he needs. The question isn't whether the architecture is right. It's whether it's worth building on a surface OpenAI has already scheduled for replacement.
And the honest answer is that the answer depends on a fact neither of us can check from here.
Which is whether he can still edit the thing today.
Hilbert: Four hundred and thirty dollars.
For what.
Hilbert: The dispatch board. Late seventies, regional courier outfit, I did a stretch on order dispatch. Every job went out over a phone line to a dispatcher. The dispatcher took the call, read it back, and only then keyed it into the system. The read-back was the whole job.
The read-back being the part everyone wants to automate away.
Hilbert: First thing they cut. Every time. You agree with the hosts about the confirmation step being the valuable part, and I think you're right, but you've got it in the wrong place. It isn't a feature you bolt on at the end. It's the thing that makes the rest of it trustworthy. You lose it in a migration, you haven't lost a button. You've lost the reason anyone believed the system in the first place.
So it's not a gate, it's the foundation.
Hilbert: It's the foundation. Everything downstream is just arithmetic once somebody's said the job back correctly. And I've still got the laminated call-script card from that job somewhere in a drawer. Read-back phrasing printed on it. I've never seen a system prompt do that job as well as that card did.
What's actually printed on it.
Hilbert: Repeat the job back in the customer's words, not yours. Then confirm. Then key it in.
In the customer's words, not yours.
Hilbert: That's the line. Anyway. I'm needed to let somebody in somewhere, and I'm the only one with the key.
The card is the whole thing, isn't it. Let's leave it there and pull the threads.
The threads are all open questions. Whether OpenAI ever publishes a personal-account retirement date, whether MCP apps close the mobile gap, and whether the migration tooling ever learns to carry Actions across intact.
The larger implication, which is the part that'll outlast this specific product. The lightweight tier of agentic tooling is being consolidated into the heavier, enterprise-shaped tier. And the people who got the most out of the lightweight tier are the ones who lose the most in the transition.
Every time. The people who squeezed the most out of the simple thing are the ones with the most to rebuild.
If you enjoyed this one, a review helps more than you'd think. Thanks as always to our producer, Hilbert Flumingtop.
This has been My Weird Prompts.
The human-AI collaboration podcast. Email us at show at my weird prompts dot com. We'll be back soon.
