Which community platforms can you run by talking to ChatGPT or Claude?

We make Drry, which ships the thing this guide is about, so read the whole page as an interested party writing it. And here is the part an interested party would rather not lead with: several of the platforms we compete with shipped this before we did. The first draft of this guide said the opposite, on the lazy assumption that a feature we had built early must be rare. It is not, and the useful version of this page is better for it, because once everybody has one the question stops being who has a connector and becomes what theirs is allowed to touch.

The question people are actually asking is smaller than "is there AI in it". Every platform in this market has added AI in the sense of a button that writes a lesson description. What a coach is asking when they ask this is: can I sit in the assistant I already use all day, say "add a fourth week to the onboarding course and drip it seven days apart", and have it happen. That is a different feature, it has a name, and most platforms do not have it.

The distinction that decides everything: reach

An assistant is only as useful as the things it can touch. There are three levels, and they get conflated constantly in marketing copy:

• AI inside the product. A generate button in the editor. Useful, and it has nothing to do with your assistant: you still do the work, in their interface, at their pace.
• An API plus an automation tool. Real power, but it answers only the questions you wired up in advance. Ask for something you did not anticipate and you are building another automation.
• A connector the assistant can call. You describe the outcome in words. The assistant works out which calls to make. Nothing was configured in advance, and the request can be one nobody thought of.

The third is what MCP is for, and it is the one worth asking a vendor about by name. "Do you have an AI assistant?" gets a yes from everyone. "Do you publish an MCP connector, and what can it reach?" gets a much shorter list of answers.

What the read side gets wrong, and why it matters more

The failure everyone anticipates is an assistant doing something destructive. The failure that actually happens is quieter and more common: an assistant answering confidently from an incomplete picture.

A worked example from our own connector, because we got it wrong first. An early version of ours could list a course's lessons with their titles and publish state, and nothing else. Ask it "is this course gated so people take it in order?" and it would say no, about a course that was: the drip schedule and the prerequisites were stored on every lesson and simply were not in what the tool reported. Nothing errored. The answer was wrong and sounded certain.

That is the shape of the real risk, and it is why a missing write is the lesser problem of the two. A write an assistant cannot do produces a refusal you can see and work around. A read that omits half the row produces confident wrong answers you have no reason to check. When you are evaluating one of these, ask the assistant a question you already know the answer to, and see whether it gets it right.

Where the category stands, as of September 2026

Read this section as perishable, and check the vendor pages rather than trusting any guide, including this one, on a question moving this fast. Every claim here comes from each vendor's own page, read in September 2026.

• Kajabi publishes one on every plan, and it is the most cautious design of the group: every write lands as a draft for you to publish by hand. Its own page says it does not cover analytics, community management or payment processing yet.
• Circle publishes one on its Business plan and above, connected by an admin, scoped to what its admin API already exposes and counted against the same rate limits.
• Mighty Networks publishes one a host turns on per network, with the reach set by role, and it is explicit that it gives nobody access to content they could not already see.
• Skool publishes none, and has no public API: its sanctioned automation route is a Zapier app on the paid plan. The Skool connectors you will find are third-party projects working against undocumented internal endpoints, which is a different risk to take on.

The pattern worth taking from that list is that the interesting differences are not in whether a connector exists. They are in how much of the product it reaches, who is allowed to connect it, whether it can commit anything by itself, and what it costs you to have one. On one of the four it sits above the entry plans, which means the coach most likely to want it is the least likely to be on a plan that has it.

Kajabi's draft-only rule deserves a closer look, because it is the most defensible decision on this list and the one we would argue with. Writing everything as a draft removes the whole class of mistake where an assistant publishes something half-finished to your members. It also means the assistant cannot finish a job, so the work it saves you is the typing rather than the doing. Which of those you prefer depends on whether you would review the change anyway. Ours drafts the same way for the things that reach members, courses, guides, pages, forms and emails, and then differs on the next step: it can publish those drafts when you tell it to, rather than leaving every one for you to publish by hand. Settings are the exception on both sides and take effect as they are written.

The three things to keep in your own hands

This is the part we would argue for even about a competitor's connector, and it is the part that gets skipped because it reads as less exciting than the demo.

• Money. Refunds, prices, payouts, plan changes. An assistant reading whether your payment account is connected is fine. An assistant issuing a refund is a mistake nobody can take back, and the upside over doing it yourself is seconds.
• Your members' personal details. Their email addresses and what they paid are their data, not yours to hand to a third party because it was convenient. A connector that returns a member's address has made that decision on your behalf.
• Judgements about a person. Approving a held post, removing a member, changing somebody's role. These end subscriptions and rule on what somebody said. They are yours even when a model would probably get them right.

There is a fourth that is easy to miss because it costs money rather than trust: anything billed by the minute. A live video room invoices per participant per minute, so a door an unattended assistant can open is a bill with no ceiling. Ours keeps assistants out of live rooms for exactly that reason.

Notice what all four have in common. The restriction is never "this is too complicated for a model". It is that the action is irreversible, or somebody else's, or meterable. Composing a course draft is none of those, which is why the useful version of this feature is broad on building and narrow on committing.

What this looks like in Drry

Judged on the four questions above rather than on having one at all: ours is on every plan, it reaches the whole build surface, anybody holding a console seat can connect it, and what it makes for your members starts as a draft it can also publish on your say-so. Practically, it is one connector with one address, which you copy from your settings and paste into the assistant. You approve it once, on a screen that names each capability it is asking for, and you can disconnect it from the same settings page whenever you like. Nothing about it is a developer task.

What it reaches, stated plainly so you can hold us to it: courses and lessons, including the drip schedule and the prerequisites that early version could not see; guides; the audio library; events and the time people can book; funnel pages and forms; membership tiers; your audiences, emails and automations; your settings and how the community looks. Plus the questions about your members and your numbers that usually mean opening a dashboard.

And what it will not do, which is the more informative list: move money, return a member's email address, enter a live room, delete your content, or rule on a held post or somebody's role. It gained the ability to unpublish something long before it will ever gain the ability to delete it. Those are deliberate gaps rather than work in progress.

Two honest edges to that list, because a page that says "hold us to it" has to name them. It can undo a contact import, which does delete the rows that import added, and that is the one delete it has. And it can create a payment link, owner only: no money moves until somebody opens the link and pays, but the amount on it is set through the assistant, so a price is not as far out of reach as the rule above would suggest.

Common questions

If you are weighing platforms on more than this one feature, our roundup of community platforms covers the rest of the decision, and the piece on platform fees covers the one that costs the most money over time.