Lorekeeper Bot

What is a Discord AI campaign manager?

A Discord AI campaign manager helps tabletop role-playing groups keep campaign information organized between sessions. For a product like Lorekeeper Bot, that means giving a group a searchable record of its NPCs, locations, rulings, clues, and unresolved plot threads—then using AI to answer questions and draft recaps grounded in that group’s own lore.

The core promise is practical: players and game masters spend less time searching old messages and trying to remember details, and more time playing. A bot that can answer “What did we learn about the apothecary?” or “Which house rule did we agree on for falling damage?” is useful only if it can find the right source, preserve context, and avoid inventing information.

That last requirement is what separates a reliable campaign tool from a generic chatbot. Lorekeeper Bot should not simply generate plausible fantasy prose. It should retrieve relevant campaign records, indicate when it is uncertain, and respect the game master’s control over spoilers and private notes.

Who needs Lorekeeper Bot?

The best early users are groups that already use Discord for coordination and have enough campaign history to feel the cost of scattered information. The product can serve several audiences, but each has different needs and willingness to pay.

Game masters managing long-running campaigns

Game masters (GMs) are the clearest primary audience. They maintain world details, introduce NPCs, track consequences, answer rules questions, and prepare sessions. As a campaign grows, those responsibilities can become difficult to manage across notes, chat logs, character sheets, and memory.

Lorekeeper Bot can help GMs:

• Record or refine NPC, location, item, faction, and quest entries.
• Search past sessions and decisions using natural-language questions.
• Draft session recaps from notes or approved conversation history.
• Keep private GM notes separate from player-facing information.
• Track open plot threads that need follow-up.
• Find the source behind an answer before relying on it.

The most valuable benefit is not just saving time on note-taking. It is reducing the risk that a campaign detail gets forgotten, contradicted, or revealed to the wrong person.

Players joining an established campaign

Players often need reminders rather than a complete world encyclopedia. They may ask what their characters know about a contact, where the party found a clue, or what the group agreed to do next. A searchable archive makes it easier to re-enter the story after a busy week or a missed session.

For player-facing answers, the bot should distinguish between:

• Information the characters have discovered.
• Information a player may know from table discussion.
• Information reserved for the GM.
• Information that is not yet recorded.

Those distinctions should be configurable by the GM, not inferred solely by the AI.

West Marches and other shared-world groups

Shared-world campaigns, living campaigns, and West Marches-style games can involve multiple parties, rotating players, and sessions run by different GMs. These groups have a greater need for consistent records because campaign knowledge is distributed among people who may not attend every session.

Lorekeeper Bot could help them maintain shared locations, faction changes, discovered secrets, and table rulings. Permission boundaries become especially important here. A campaign may need a shared player archive, private GM channels, and session-specific notes with different visibility rules.

Actual-play communities and organized play groups

Some groups record sessions, publish recaps, or coordinate events for a wider community. They may benefit from transcription and recap workflows, but they also have heightened consent, privacy, and moderation requirements. The bot should never assume it can process voice recordings or message history simply because it has access to a server.

For this audience, clear controls over data collection, retention, and deletion are central product features—not fine print.

The market opportunity and product gap

Tabletop groups already use a mix of tools: Discord channels, shared documents, campaign wikis, virtual tabletops, note apps, and spreadsheets. The opportunity is not necessarily to replace all of them. It is to reduce the effort required to keep the important information connected and findable.

A Discord AI campaign manager occupies a useful position between a general-purpose AI assistant and a full campaign-management suite:

• A general chatbot can generate ideas, but it does not automatically know a group’s canon.
• A wiki can store canon, but it usually requires people to organize and search it manually.
• A chat archive contains discussion, but important decisions can be buried in years of messages.
• A virtual tabletop can support play, but it may not be the group’s preferred place for campaign conversation.

Lorekeeper Bot can connect those behaviors by making campaign knowledge searchable where the group already talks.

A focused problem is better than an oversized promise

It would be tempting to describe the product as an AI that runs a campaign. That positioning creates unrealistic expectations and may concern GMs who want to retain creative control. A more credible promise is:

Lorekeeper Bot helps your group remember and retrieve campaign information, while leaving storytelling decisions in the hands of the players and GM.

This positioning creates a clearer initial product. Start with trustworthy lore capture, search, recap drafts, and spoiler controls. Consider autonomous storytelling or complex campaign automation only after users trust the underlying record.

Validate demand before building deeply

Interest in AI tools does not automatically prove demand for a specific campaign bot. Validate the workflow with actual GMs and players before investing in sophisticated AI features.

Useful discovery questions include:

1. Where do you currently store campaign notes?
2. What information do players ask you to repeat?
3. How do you distinguish canon from brainstorming?
4. What happens when a ruling or NPC detail is forgotten?
5. Would you want the bot to read Discord messages, or would you prefer explicit submissions?
6. Which campaign information must never be visible to players?
7. What would make you stop using an AI tool at your table?
8. Would you pay for convenience, increased storage, or multi-campaign management?

Look for repeated examples of real friction, not just positive reactions to the concept. A strong signal is a GM willing to connect a real campaign, test the bot for several sessions, and give feedback about what it got wrong.

For market-size claims, use a transparent research approach. Review relevant tabletop role-playing market reports, Discord community policies, competing product pricing, and direct interviews. If the article or product site includes numerical market claims, cite the original report and its publication date rather than repeating unsourced estimates.

Core features for Lorekeeper Bot

The product should earn trust through a small set of dependable workflows before expanding into a broad suite of AI features.

1. Campaign knowledge base

Each campaign needs a structured home for its information. Records might include:

• NPCs and relationships.
• Locations and regions.
• Factions and organizations.
• Items, clues, and discoveries.
• Quests and unresolved plot threads.
• Session summaries.
• House rules and table decisions.
• GM-only secrets.

Allow records to be created manually, imported from a document, or drafted from a conversation. The GM should approve AI-generated canon before it becomes an authoritative entry. This review step helps prevent an offhand idea or joke in chat from being mistaken for a permanent fact.

A practical record should include a title, type, description, tags, campaign, visibility level, and provenance. Provenance means users can see where a claim came from, such as a GM-approved note or a particular session recap.

2. Searchable lore and grounded answers

Players should be able to ask questions in natural language, such as “Who gave us the silver key?” or “What was the name of the inn near the old bridge?” The bot should search relevant campaign records and return a concise answer with supporting references.

A trustworthy response pattern is:

• Answer directly when the source is clear.
• Include the relevant record or session reference.
• Say when the archive does not contain enough information.
• Ask a clarifying question when multiple results are plausible.
• Avoid presenting generated guesses as campaign canon.

This is a retrieval problem before it is a generation problem. Better retrieval, clean data, and clear source attribution often matter more than using a larger language model.

3. Session recap drafts

After a session, a GM may want a readable recap that captures events, decisions, discoveries, and open questions. Lorekeeper Bot can generate a first draft from GM-provided notes or permitted session information.

The recap should remain editable. It can also offer different views:

• A spoiler-safe recap for all players.
• A private GM summary.
• A short “last time on” version for the next session.
• A list of unresolved plot threads.
• A structured list of new NPCs, places, and clues for GM approval.

The bot should not publish a recap automatically unless the GM has explicitly enabled that behavior. A review-and-approve workflow protects both narrative accuracy and spoiler boundaries.

4. Spoiler-aware permissions

Spoiler handling should be part of the data model, not a prompt instruction added at the last moment. A campaign might have visibility levels such as:

• Public to everyone in the campaign.
• Known to players.
• Known to a specific character or group.
• GM-only.
• Unpublished draft.

The bot must apply permissions before retrieval. If a player asks a question, GM-only records should not be included in the material sent to the AI model. Filtering after generation is not sufficient because the model may already have used hidden information to shape its answer.

For character-specific knowledge, the product will need a clear identity model. Discord users and fictional characters are not automatically the same thing. Let the GM map members to characters, support multiple characters per player, and review who can see character-specific content.

5. Ruling and decision tracking

House rules and table decisions are easy to lose in chat. A ruling record can include the decision, the date, the relevant system or situation, and whether it is temporary or permanent.

A useful workflow might let a GM save a ruling from a command or button, then make it searchable later. If a ruling changes, preserve the previous version or change history. That avoids confusion when an older message appears in search results.

6. Plot-thread tracking

A plot-thread view can show unresolved questions and possible next steps without dictating what should happen. Each thread could include:

• The question or hook.
• Who or what it relates to.
• When it was introduced.
• Its current status.
• A GM-only note.
• A link to related sessions or lore records.

This feature can help a GM prepare without asking AI to write the campaign for them.

7. Transparent corrections and feedback

AI errors are inevitable. Make it easy for users to flag an incorrect answer, correct a lore entry, or mark a result as outdated. Capture useful feedback without turning every interaction into a complicated report.

A correction flow should answer three questions:

• What did the bot say?
• What is wrong or incomplete?
• Which source should be treated as authoritative?

Use corrections to improve records and retrieval, rather than silently training on private campaign content without clear consent.

How the product should work

A robust Discord AI campaign manager can be understood as a pipeline:

1. Collect information from explicit submissions, approved notes, or permitted message sources.
2. Normalize it into campaign records with a type, author, date, and visibility.
3. Review it when the information could affect canon or spoilers.
4. Retrieve relevant sources for a question using keyword and semantic search.
5. Apply permissions before any private information reaches the model.
6. Generate a grounded answer using the permitted records.
7. Show sources and uncertainty so users can verify the result.
8. Store feedback when users correct or improve an answer.

This workflow separates the searchable archive from the AI response layer. That separation makes the system easier to test, audit, and improve.

Recommended technology stack

The right stack depends on team expertise, expected Discord activity, and the amount of data to manage. For an early SaaS product, favor technologies that let the team ship quickly while keeping data boundaries explicit.

Discord integration

Build the bot using Discord’s official developer platform and a maintained library for the team’s language. Review Discord’s current developer documentation for bot permissions, application commands, interactions, and policy requirements at Discord Developer Documentation.

Use slash commands, buttons, and modals where they make workflows clearer. Avoid requesting broad permissions without a clear product need. A bot that only responds to explicit commands may be easier for users to understand and more privacy-conscious than one that reads every message.

Application framework

A TypeScript web application is a practical choice for a SaaS dashboard, account settings, campaign administration, and billing. Teams may choose Next.js for a full-stack React framework, or a different framework that better fits their existing architecture.

A web dashboard is useful for tasks that are awkward in Discord, such as reviewing imported records, managing access, editing a large lore entry, or exporting campaign data. Discord can remain the primary interaction surface without being the only interface.

Database and search

A relational database such as PostgreSQL is a strong default for users, servers, campaigns, memberships, records, permissions, and billing relationships. It supports structured queries and transactions that are important for access control and account management.

For semantic search, a vector extension such as pgvector can keep embeddings close to the campaign records. This can simplify early infrastructure compared with operating a separate vector database. However, a specialized search service may become useful if the product later needs high query volume, advanced filtering, or independent scaling.

A hybrid search approach is often preferable:

• Use database filters for campaign, visibility, and record type.
• Use keyword search for exact names and phrases.
• Use vector similarity for conceptually related questions.
• Re-rank results using freshness, source quality, and user context.
• Return citations to the original records.

AI model layer

Keep model-provider calls behind an internal interface. That makes it easier to compare providers, manage cost, and change models without rewriting product workflows. Review the provider’s official documentation for data handling, retention, rate limits, and current API behavior before selecting it.

The model should receive only the information it needs for the current response. Do not send an entire campaign archive to answer a question about one NPC. Use explicit instructions that distinguish sourced facts from uncertainty, but do not rely on prompting alone for access control.

Background processing

Imports, recap generation, embedding creation, and scheduled maintenance can take longer than a Discord interaction allows. Put those tasks on a background job queue and give users a clear status such as “processing,” “ready for review,” or “failed.”

Make tasks idempotent where possible. If a job retries, it should not create duplicate NPCs or publish the same recap multiple times.

Privacy and security foundations

At minimum, plan for:

• Tenant isolation between Discord servers and campaigns.
• Role- and record-level authorization.
• Encrypted transport and secure secret storage.
• Deletion and export workflows.
• Clear retention settings.
• Audit logs for permission-sensitive actions.
• Rate limits and abuse monitoring.
• A documented process for handling security reports.

For a product that processes private campaign material, privacy needs to be visible in onboarding and settings. Users should know what the bot can read, what is stored, which model providers process requests, and how to remove their data.

Competitive advantage and positioning

Lorekeeper Bot’s potential advantage is not simply “AI for D&D” or “a bot that summarizes Discord.” Those descriptions are easy to copy and do not explain why a group should trust it.

The stronger USP is:

A campaign memory layer for Discord that gives grounded, searchable answers while respecting GM-controlled spoilers and preserving the sources behind its claims.

That advantage can be built through several product choices:

• Campaign-specific retrieval: Answers are based on a group’s own approved records.
• Visible provenance: Users can inspect where a response came from.
• Spoiler-aware access: Private information is excluded before generation.
• Canon review: AI suggestions do not automatically become facts.
• Low-friction workflows: Groups can capture and retrieve information without adopting an entirely new campaign platform.
• Continuity over spectacle: The product focuses on remembering accurately rather than generating the most elaborate response.

A competitive analysis should compare workflows rather than feature lists alone. Assess whether other products support Discord-native use, campaign-level permissions, source citations, editable recaps, structured lore, exports, and clear data controls. Product capabilities and pricing change, so verify current competitor information directly before publishing comparisons.

Monetization strategy

A sustainable pricing model should align with the value delivered and the cost of AI processing. The product can begin with a simple subscription structure and add complexity only after usage patterns become clear.

Freemium for adoption

A free plan can help one campaign test the core loop. It might include a limited number of lore records, a modest query allowance, basic recap drafts, and one connected server. The goal is to let a group experience value without building a full campaign archive that becomes difficult to migrate.

Set limits that are understandable. If a user reaches a limit, explain what changes on a paid plan and let them export their data.

Subscription tiers

A paid individual or campaign plan could include:

• More campaigns or connected servers.
• Higher AI usage limits.
• Larger searchable archives.
• More recap and import workflows.
• Advanced character-level permissions.
• Longer history and richer analytics.
• Priority support or early access to features.

A group subscription can make sense when the product’s value is shared by the whole table. Keep the purchaser’s role clear, particularly when several GMs or server administrators manage the same campaign.

Usage-based AI allowances

AI costs vary by model, request size, and usage. Include fair-use allowances or transparent usage limits rather than offering unlimited generation if the economics are uncertain. Monitor cost per active campaign, not just cost per account.

Consider caching repeatable searches and using smaller, less expensive models for classification or extraction. Reserve more capable models for tasks where quality meaningfully affects the user experience.

Add-ons and future revenue

Potential later offerings include bulk campaign imports, advanced export formats, additional storage, or organization plans for multiple GMs. Avoid selling features that undermine trust, such as access to private campaign data or using a group’s lore for unrelated purposes without explicit permission.

Risks and mitigation

Hallucinated or misleading answers

A fluent answer may still be wrong. Ground responses in retrieved records, show sources, and say when evidence is incomplete. Test questions should include missing information, contradictory notes, similar NPC names, and outdated rulings—not just examples where the answer is obvious.

Spoiler leakage

This is one of the highest-impact product risks. Apply access controls before retrieval and before model calls. Test permission boundaries with automated cases, including group membership changes, character-specific secrets, and mixed public/private search results.

Confusing conversation with canon

A message in Discord is not necessarily a final decision. Make ingestion transparent and provide a review queue or explicit save command. Let GMs mark records as draft, approved, contradicted, or archived.

Discord policy and platform changes

The bot depends on a third-party platform. Track changes to Discord’s developer rules, API limits, and permission model through official documentation. Keep integrations modular and request only the access the product requires.

Cost spikes and abuse

A popular server, automated loops, or malicious users can increase model and infrastructure costs. Use rate limits, request budgets, input-size limits, abuse detection, and per-campaign usage reporting. Provide administrators with controls that do not require contacting support.

Privacy, consent, and data ownership

Campaign notes can contain personal information, unpublished creative work, and private conversation. Explain data handling in plain language, make ingestion opt-in and configurable, and provide deletion and export options. If voice transcription is considered later, treat consent and recording rules as a separate product and legal review—not an automatic extension of text features.

Overbuilding before finding product-market fit

It is easy to spend months on character sheets, maps, encounter generation, and virtual tabletop features. Keep the initial product focused on the memory problem. Track whether users return to search, approve records, and use recaps across multiple sessions.

Measuring whether the product works

Measure behavior that indicates reliable value rather than raw AI activity. Useful early metrics include:

• Campaigns that complete setup and save their first approved records.
• Weekly active campaigns, not just individual accounts.
• Searches that lead to a useful citation or follow-up action.
• Recap drafts that are edited and approved.
• Corrections per answer and recurring error categories.
• Percentage of answers that correctly abstain when the archive lacks evidence.
• Retention across multiple sessions.
• Cost per active campaign.
• Export, deletion, and support request rates.

Pair quantitative usage data with interviews. A drop in searches could mean users no longer need help, or it could mean they lost trust after a bad answer. Qualitative follow-up explains the difference.

A practical implementation roadmap

Phase 1: Validate the workflow

Interview GMs and players, then run a lightweight prototype with a few willing campaigns. Test one core question: can the product make campaign information easier to retrieve without creating more work or risking spoilers?

Start with explicit note submission and a small searchable archive. Avoid broad message ingestion until users clearly understand and request it.

Phase 2: Build a trustworthy MVP

The first release should include:

1. Discord server connection with minimal permissions.
2. Campaign setup and membership management.
3. Structured lore records with visibility levels.
4. Natural-language search with source references.
5. A GM approval flow for generated records.
6. Basic recap drafts.
7. Export and deletion controls.
8. Usage limits and operational monitoring.

Treat permission tests and answer-quality tests as launch requirements.

Phase 3: Pilot with real campaigns

Recruit a small, varied pilot group: a home campaign, a long-running campaign, and a group with rotating players are useful starting points. Observe how each group captures information and where the bot misunderstands its conventions.

Review errors weekly. Categorize them as retrieval misses, stale records, ambiguous questions, permission mistakes, or model-generated unsupported claims. Each category points to a different fix.

Phase 4: Improve onboarding and retention

Once the core workflows are reliable, make setup faster. Provide templates for campaign records, a guided import review, and examples of safe questions. Help users understand the difference between searchable notes and approved canon.

Add features based on repeated behavior. If users repeatedly ask for ruling history, improve rulings. If they consistently want NPC relationship maps, explore that workflow. Avoid adding features only because they are technically impressive.

Phase 5: Expand carefully

After the product demonstrates repeat use and sustainable unit economics, consider richer imports, more advanced campaign analytics, or integrations with other tabletop tools. Preserve portability so customers can export their material and are not locked into the product.

Getting started with the build

A SaaS launch involves more than the bot itself. You will need authentication, billing, account management, onboarding, and a reliable web dashboard alongside the Discord integration. A starter platform such as TurboStarter can help accelerate common SaaS foundations, leaving more development time for campaign memory, retrieval quality, and spoiler-aware workflows.

Final recommendations

Lorekeeper Bot has a compelling opportunity if it solves a narrow, recurring problem exceptionally well: helping tabletop groups remember what happened and find what matters without compromising the GM’s control over the story.

The most defensible product is not the one that generates the most content. It is the one that can show why an answer is trustworthy, admit when it does not know, and keep private information private.

Start with approved campaign records, grounded search, recap drafts, and permission controls. Validate those workflows with real groups, measure whether they return between sessions, and expand only when the evidence supports it. That approach gives Lorekeeper Bot a clearer position in the market and a stronger foundation for long-term trust.