The bot lives on your WordPress community page, not inside Discord or Slack. It can read content that lives in WordPress - channel descriptions, pinned post mirrors, event posts, code of conduct, FAQ - and point visitors at the matching Discord channel URL or Slack workspace invite. For Discourse, where the forum often is on your site, the bot can read threads directly via the post type or via the Discourse API. The bot supplements the community platform, it does not replace it.

Yes - if events live as WordPress posts (custom post type, The Events Calendar, or a structured field), the bot reads them. The system prompt is configured to mention events when relevant: a newcomer asking about a topic that has a scheduled event gets the event surfaced as part of the welcome. Past events are de-prioritised so the bot does not point newcomers at last year's showcase. Date filtering happens in the data source query, not in the prompt.

Yes. The code of conduct loads as a source, and the system prompt instructs the bot to answer rules questions warmly, with the section reference attached. The bot does not enforce - moderation actions still go through moderators - but it removes the friction of newcomers having to read 4,000 words of rules to learn what is allowed. Recurring 'is this allowed' questions become opportunities to clarify the code of conduct itself.

Yes - and this is one of the bigger wins. Many community pages convert poorly because visitors cannot tell from the static page whether the community is active and welcoming. A bot that describes the channels, surfaces the next event, and mentions a recent good thread answers the unspoken question 'is this place for me'. We have seen meaningful lifts in newcomer signup just from the conversational layer existing on the page, especially for hobby and creative communities.

The system prompt should explicitly require warm, non-bureaucratic tone for rules answers. 'Please remember to use the WIP tag' beats 'untagged work-in-progress posts violate section 3.2 of the Code of Conduct'. Both quote the same rule, but the first invites compliance and the second invites pushback. Tone shapes moderation outcomes as much as the rules themselves, and the bot is a high-leverage place to set it consistently.

Generally we recommend not. Naming specific members ('@taylor handles WordPress questions') ages quickly and can create awkwardness when those members move on. Roles ('moderators', 'the events team', 'a community lead') are more durable and stay accurate as the team changes. For larger communities, a 'staff page' that lists current roles and the canonical channels for each role works better than the bot trying to track individuals.

Yes. For communities with thousands of threads, mirror the most useful content (pinned posts, FAQ, official announcements, code of conduct) into an OpenAI Files vector store rather than loading the whole forum. Active forum search is better served by Discourse's own search; the bot's job is the welcome and rules layer, not full-text discovery across 20,000 posts. Scoping correctly is the difference between a useful community bot and an overconfident one.

The system prompt should route any harassment, safety, or moderation-incident language to a real moderator inbox immediately, with the conversation transcript attached and a clear acknowledgement to the reporter. The bot does not investigate, does not message accused members, and does not opine on outcomes. These conversations belong with humans. For broader safety - mental health crisis language, for example - configure the bot to surface relevant public hotlines and the community's own welfare resources rather than improvising.