Skip to main content

AI Companion concept

This page explains what the AI Companion is and how it works, so you understand the idea before you set it up or start using it.

The AI Companion is a chat-based assistant built into the admin panel. You describe what you need in plain language, and it does the legwork: it reads your server data on its own, reasons across multiple steps, and drafts the actions you want to take. You stay in control — the Companion never changes anything by itself.

Today the Companion is focused on ticket support, but it is built as a general, server-wide assistant. We are gradually opening up more of the platform to it over time.

How it works​

The Companion is agentic, not a single-shot chatbot. When you ask it something, it can take several steps on its own before answering:

  • it looks things up using read access to your server data (players, factions, tickets, logs, orders, bases, rules, and more)
  • it correlates what it finds across those sources
  • it summarises the result for you and proposes concrete next actions

A single request can trigger many lookups behind the scenes. You see a short trace of which areas it consulted, so you can tell it actually checked the data.

Proposals and approval​

This is the most important idea to understand: the Companion never performs an action on its own.

  • Reading data happens immediately and freely.
  • Anything that changes something — a ticket reply, an internal note, a ban, a balance change, a refund, a Discord message, and so on — is only ever drafted as a proposal.

Each proposal appears as a card with a clear summary and Approve / Reject buttons. Nothing happens until a human approves it. A single answer can contain several proposals at once (for example a reply plus an internal note, or two alternative replies — approve one, reject the other). Each one is decided independently.

When you approve a proposal, dzbot re-checks that the action is still valid (the ticket is still open, the player still exists, the order can still be refunded) and then carries it out using the same internal logic as the normal admin pages. If something changed in the meantime and the action is no longer valid, the proposal is marked as failed with a reason instead of doing something half-finished. The Companion is told the outcome of every proposal, so it can react on your next message.

Sessions​

Conversations with the Companion are organised into sessions, similar to a chat history:

  • sessions are private to you — each staff member has their own
  • they are named automatically from your first message and can be renamed
  • they are append-only — they are never deleted, which makes every prompt, lookup and approval auditable later
  • a session's context is fixed when it is created — one session is one task. When the task is done, start a new session for the next one.

You can keep a session open to continue later, or archive it once you are finished.

Page awareness​

The Companion is page-aware: it adapts to where you started it. Today this is implemented for ticket pages — when you open the Companion from a ticket, it already knows that ticket and can read its full conversation without you pasting anything. On other pages it works just as well; you simply describe the goal yourself. More pages will become context-aware over time.

Bring your own key​

The Companion runs on a third-party AI provider that you connect: OpenAI, Anthropic, or Google. The server owner pastes their own API key, and usage is billed directly by that provider to that account. dzbot records token usage per server so you keep an overview, but the AI cost itself sits with your provider account, not with dzbot.

See AI Companion setup for how to obtain and configure a key.

Access and availability​

The Companion only appears when both conditions are met:

  1. an API key is configured for the server, and
  2. the user has the AI Companion access right.

A single access right gates the whole feature. A user who has it may use every capability and approve any proposal type — there is no per-action permission split. This is deliberate: because sessions are non-deletable, every action a user takes through the Companion is fully auditable after the fact.