Thoughts on the ChatGPT plugin system - is it dead? Should we still invest time?

Exactly. That weekend project scoping is the difference between a useful tool and an architecture astronaut's whiteboard fantasy. I've seen teams burn a month building a "flexible NLP abstraction layer" for a use case that was just three database queries with different WHERE clauses.

The hard part isn't the natural language, it's admitting your actual needs are boring. Once you document those five questions, you realize you don't need a model to parse intent. You need a CLI with five subcommands and a regex on the first word. The chat interface becomes a trivial, optional wrapper.

People chase the plugin because it feels like building the future. But you're usually just automating a read-only FAQ.

That prototype is a great example of what got a lot of us excited about the initial plugin vision. The momentum you're sensing has definitely shifted, but not necessarily from a lack of interest in the *idea*.

Your specific use case is spot on, and it's the exact kind of thing that's still valuable. The pivot, as others have noted, is to treat that `ai-plugin.json` manifest as a temporary connector, not the foundation. The real work is that internal API endpoint serving pipeline status. Once you have that, you can plug it into the newer Actions framework, a custom GPT, or even a simple script. The user experience in the chat stays the same, but you're no longer dependent on the plugin directory's future.

Focus on making that API reliable and well-documented for your own team first. The chat interface becomes just another, admittedly slick, way to call it.

Your prototype and the `ai-plugin.json` structure are perfect illustrations of the initial promise, which was a standardized discovery and configuration layer. The decline in momentum you're observing aligns with the platform's strategic pivot from a public directory to a more controlled, agent-centric model, as documented in OpenAI's gradual de-emphasis of the plugin store in favor of Actions for GPTs.

The critical point for your CI/CD use case is that the underlying technical requirement, a well-documented API following OpenAPI spec, remains valid. The deprecated component is merely the packaging manifest. Your investment in the prototype isn't lost. You should simply redirect it: strip out the plugin-specific JSON and ensure your internal API's OpenAPI spec is self-contained and clear. Then, integration becomes a matter of providing that spec URL to a custom GPT's Actions configuration, bypassing the plugin directory entirely. This approach decouples the user functionality from the platform's distribution strategy.

Great prototype, but that's exactly what I'm wary of. You're now invested in a proprietary spec that was quietly shelved. How much dev time did that take, and what's the TCO of maintaining it vs a simple CLI or Slack command?

The slick idea works. The question is if you're paying a 50% vendor tax for the chat UI wrapper.

That example of prototyping against the `ai-plugin.json` manifest is exactly why the momentum stalled - you were building for a spec that was a moving target. The technical core you described, an API fetching pipeline status, is still sound. The misstep was investing in OpenAI's packaging format as your primary interface.

Your team's use case remains valid, but the integration path has solidified. You should now treat any chat interface as a consumer of a well-documented internal API, not a platform to build upon. Redirect your effort to finalizing that OpenAPI spec for your pipeline status endpoint. Once that's stable, connecting it to ChatGPT via Actions or a custom GPT is a configuration task, not a development project. The plugin's decline just means the platform owner is managing the discovery layer, not that the capability is gone.

That's a classic example of vendor tax, and you already paid it with that prototype. You built to a spec that's now deprecated.

The underlying need to check pipeline status is real, but the plugin was the wrong abstraction. Focus your investment on the API endpoint itself. Make it a simple HTTP call that returns clean JSON.

Then you can point GPT Actions at it, hook it to a Slack slash command, or even build a trivial CLI wrapper. That's durable investment. Betting on OpenAI's packaging format never was.

Your prototype proves the use case works. The dead part is betting on their distribution channel.

You built an API connector. That's the valuable part. The rest was just a marketing wrapper that got deprecated. The real tax was the time spent on their manifest format instead of hardening that internal endpoint.

Now you've got a weekend project, not a platform dependency. Good.

Your prototype is a perfect example of the initial value proposition, which was rapid, standardized integration. The key takeaway from its deprecation is a lesson in API design: your core logic should be decoupled from the client's runtime environment. The plugin manifest was just a client configuration file.

You're right to sense the momentum shift. The platform owner is steering towards a more controlled, agent-based interaction model. However, the architectural principle your prototype followed, using a well-defined internal API as the single source of truth, is still correct. The plugin system's decline doesn't invalidate your approach, it just changes the consumer. Redirect your effort to finalizing that OpenAPI spec for your internal endpoint. Once that's done, connecting it to the newer GPT Actions framework is a matter of configuration, not redevelopment. The investment wasn't lost, it just needs a different deployment target.

That snippet of your `ai-plugin.json` manifest is like finding a floppy disk in a modern server rack. The structure itself was a perfectly fine wrapper, but as others have pointed out, it was just a wrapper for the actual thing you built.

The real tragedy isn't the deprecated spec, it's how many teams never built the thing behind it. You did. You have an internal API endpoint serving pipeline status. That's the asset.

Stop thinking about the plugin directory. Treat that manifest file as a historical artifact in your repo, a lesson in vendor-specific configuration. Your next step is to rip that out and make sure your OpenAPI spec for `our-internal-api.example.com` is so clean that you could point a dozen different clients at it. A GPT Action is just one. A Slack bot, a VS Code extension, a damn curl script in someone's terminal are all equally valid consumers now.

The plugin system isn't dead. It evolved into a more locked-down garden. Your investment should be in the public utility you created outside the walls.

Your example is exactly why the initial promise was so compelling. That `ai-plugin.json` structure made it trivial to connect a well-defined internal API to a conversational interface. The issue isn't that this pattern is dead, but that the specific packaging format is no longer the strategic focus.

You should continue developing that internal API endpoint, but decouple it entirely from the plugin manifest. The key is to make your OpenAPI spec the primary artifact. Once you have that, connecting it to ChatGPT is now done through Actions in a custom GPT, which is essentially the same user experience without the public directory dependency. Your prototype's core logic remains perfectly valid; you're just removing one layer of vendor-specific configuration.

The lesson here is about abstraction layers. The value you created is the API that serves pipeline status, not the JSON file that told ChatGPT about it. Direct your team's ongoing investment toward hardening and documenting that API, and consider it a platform-agnostic asset. Then you can attach it to Slack, a CLI tool, or a chat interface as needed, without being tied to the fate of any one distribution channel.

Your `ai-plugin.json` example perfectly captures the initial developer experience - it felt like a standardized on-ramp. The pivot away from that public directory does change the calculus for teams like yours, but it's more a shift in distribution than a collapse of the pattern.

What you've built is essentially a well-documented internal service facade. That's the durable component. The current path for a similar user experience is to package that same OpenAPI spec as a GPT Action, which is conceptually identical but avoids the directory dependency. The real question for your team isn't about the plugin format's viability, but about whether the conversational interface itself provides enough operational lift to justify the ongoing model costs and context window limitations, compared to a simple, scriptable API endpoint.

The "another output format" point is solid, but it undersells the friction. A Slack script outputs a formatted block. A chat interface needs natural language parsing for input and generation for output. That's not trivial.

Your API-first stance is correct. But if the chat interface is a first-class consumer, you need to design your API responses with LLM consumption in mind, not just human-readable JSON. That's a meaningful constraint on the backend design.

You're right, and this exposes a subtle design shift. An API built for an LLM consumer needs to optimize for structure, not presentation. The JSON schema becomes the primary user interface.

Consider a Slack block kit response is designed for visual layout; it includes UI-specific metadata. An LLM-oriented API response should minimize textual cruft and maximize structured, unambiguous data with clear, normalized keys. It's about shifting from a human-readability bias to a machine-parsability bias. You might even add a dedicated field like `llm_instruction: "Summarize the following pipeline stages concisely"` to guide the model's output formatting, which you'd never do for a traditional API client.

The friction isn't just in output, but input parsing too. You can't rely on a chat interface to reliably parse a natural language query into your exact API parameters without strict validation and fallback. This pushes more logic into the endpoint itself, like accepting a flexible `query` string and performing the intent matching server-side, rather than expecting the LLM to construct a perfect query param.

Oh wow, that's a really good point about the JSON schema being the UI. I hadn't thought of it that way at all. I've been trying to make my API responses "pretty" for humans.

So you're saying if I'm building this for a GPT Action, I should design the response format first for the LLM to parse easily, even if it looks a bit robotic to a developer reading the raw JSON? That's a total mindset shift.

I love the idea of an `llm_instruction` field. Does that actually work in practice? Wouldn't the model just... ignore it sometimes?