← All research
Research By Dipole ML Inc. Public Relations Published Last updated

OpenAI gave up on plugins. We didn't give up on integrations.

ChatGPT plugins died in 2024, and the autopsy matters: sandboxed islands with no real account access were never going to work. Connectors, done properly, are the version that survives.

In the spring of 2023, OpenAI shipped ChatGPT plugins, and the internet spent a week calling it an app store moment. A year later the program was wound down, and the quiet burial became one of the most instructive failures in this industry's short history. We think about that failure a lot, because we spent the same two years building the version we believed should have shipped: connectors. This is the autopsy, and the counter-argument.

What went wrong the first time

Plugins failed for structural reasons, not execution ones. Three stand out.

The first problem was the sandboxing. A plugin could perform a canned trick on its own infrastructure, but it could not act on your data with your permissions, because it never held them. The model could not read your actual calendar; it could ask a third party's copy of a calendar app for something adjacent. Users noticed, and the demos stopped translating into daily use.

Trust was the second problem, and it had no leg to stand on. Granting scopes meant handing credentials to strangers' server code, one unvetted manifest at a time. Every security reviewer in the world had the same opinion of that model, and they were right.

Discovery, the third problem, was chaos. Hundreds of plugins, no ranking signal to speak of, and a chat window is a terrible app store. People tried two, found toy integrations, and left.

The connector model, in plain terms

Connectors invert every one of those failures. You connect an app with its real OAuth screen: your Google account, your GitHub, your Notion. Not a plugin's imitation of the app. The actual thing, with the actual consent page you have approved a hundred times, scoped to read what it needs and nothing more.

Your credentials then live server-side, encrypted, and they never enter the model's context. Ask "what's on my calendar today" and the model never sees your token, let alone improvises with it. What happens instead is a narrow, allowlisted action with fixed parameters, executed by the server, and only the result comes back into the conversation. The model can read your last email. It cannot decide, on its own initiative, to also forward it.

That one distinction carries the whole architecture: narrow verbs, vetted hosts, audited parameters, and tokens the model can look through but never actually touch.

Where the tokens live

Here is the part we are strangest about, and proud of it: the connector infrastructure is ours. Self-hosted, on hardware we operate, on this side of the border. The typical pattern in this industry is to bolt on a third-party integration SaaS and hope their terms of service stay friendly. We did the opposite, because a connector stack is a pile of other people's credentials and a sovereignty commitment that dies at the first convenient subcontractor is not a commitment. Canadian jurisdiction, end to end, including the boring middleware.

The current lineup

Thirty-one native connectors are live in the Raven app right now. Gmail and the Google family come first for most people. Then GitHub and the developer set. After that it is whatever your team lives in, whether that is Notion and Linear, Stripe and Sentry, or Zoom and Calendly. The full list runs to thirty-one, and the marketplace catalog holds over a thousand more, each one a real integration waiting on a connection screen rather than a mockup.

You can read about how that works in practice in our connectors walkthrough, or just open the Raven app, go to Settings, and connect something. The consent screen you will see is the real one. That was the point.

Get started

Try what we just shipped.

The real models, free in your browser, or download DCode and put them to work.

Related posts