Graph Assistant

Building a reward graph by hand means knowing which card reads what, which field is required, and which combination silently does nothing. The Graph Assistant does that part with you: you describe what you want, it proposes a graph, and you decide whether it goes in.

✨ What it is

A chat panel on the graph editor — both the Leveling reward graph and Custom Commands in graph mode. Open it with the ✨ button in the top-right of the canvas.

It belongs to your team, not to you personally. Everyone on the team sees the same conversation, so a teammate can pick up where you left off, and you can see what they already asked rather than asking it again.

✏️ It edits your graph — it never replaces it

The assistant sends only the changes it wants to make: add this card, change that field, connect these two, remove that one. Anything it does not name is left exactly as it was.

This matters more than it sounds. The first version answered with a complete replacement graph, and on a long one the model would rebuild it from memory and quietly drop branches — leaving a smaller graph that still looked perfectly valid.

One honest caveat: a model that ignores the instruction and answers with a whole graph anyway is still honoured, because refusing to answer at all would be worse. That answer is now labelled as such — in the thread and again in the review window, right above the Apply button — so you know when you are looking at a rebuild rather than an edit. Everything that would disappear is listed under removed, in black and white. With smaller models it is worth reading that list rather than skimming it.

Two side effects come free: card identifiers are assigned by the panel and not by the model, so duplicates cannot happen, and removing a card takes its links with it, so no link is ever left pointing at nothing.

🔒 It proposes. You apply.

Nothing it suggests is ever applied on its own. A proposal appears in the thread with a Review changes and a Discard button, and until you apply from the review window your graph is untouched.

👀 The review window

Review changes opens a summary of what the proposal would do:

• every card added,
• every field changed, with its previous and its new value side by side,
• every card and link removed.

It is computed against the graph you have on screen at that moment, not against the one that existed when the answer arrived — so if you edited something in between, what you read is what will actually happen. A proposal that would change nothing says so, and Apply stays disabled.

This is not a formality. A reward graph is live automation on your server — it hands out roles, sends DMs and grants XP to real members. The decision to run it belongs to a person.

If you can talk to the assistant but not change a server, you still see the proposals — the Apply button is simply greyed out. Reading what was suggested is useful even when acting on it is not yours to do.

🧪 A proposal is checked before you are offered it

Every proposed graph is validated against the real card list before the Apply button appears. When something is wrong, the problems are listed instead:

• a card that does not exist,
• an action missing a required field — an Assign role with no role would be skipped in silence when the graph runs,
• a link pointing at a card that is not there,
• a command graph without its Reply, which the panel would refuse to save anyway.

It now tries to fix these itself. When a proposal is turned down, the refusal and the exact operations that caused it go back to the assistant, and it gets up to two more attempts before the answer is handed to you. You see each attempt appear in the thread as it happens, so a correction is something you watch rather than something you have to ask for.

If it is still refused after that, the problems are listed with an Ask again button. Three attempts is the ceiling on purpose: a model that cannot satisfy the validator twice is stuck on something a differently-worded question will solve faster than a fourth try.

This is also why a failed attempt stays visible in the thread instead of being tidied away. It is what the assistant reads to correct itself on the next attempt.

👀 Watching it think

Each answer carries the assistant's reasoning, folded away under Show reasoning. It is worth opening when a proposal surprises you: it usually explains which condition it thought you wanted, and that is faster than reading the graph card by card.

Questions are labelled with who asked them, because the thread is shared.

⏳ One request at a time

While the assistant is working, the composer is disabled for the whole team, in every conversation, and everyone sees who it is working for. A team shares one model and one bill, so two questions running at once would cost twice and answer over each other.

💬 Several conversations

Reward graphs and custom commands no longer share a single thread. Start a new conversation whenever you change subject — each keeps its own history, and that history is all the assistant sees, so an unrelated earlier discussion cannot confuse it.

Ask again on any answer puts your previous question back in the box, so you can adjust a word instead of retyping it. The answer it replaces stops offering Apply.

A finished conversation can be deleted with the 🗑 button next to it — it takes its messages with it, and everyone on the team sees it disappear. The button is hidden when only one conversation is left, since the panel always needs a thread to write in, and deleting one the assistant is currently working in is refused rather than allowed to break the run.

If a request fails, the thread says so and the assistant frees up immediately. When the endpoint refuses the call — a model name it does not know is the usual reason — its own explanation is what appears in the thread, so you can read what to change.

🌍 What it can see, and what you let it see

The ⚙ button in the chat window opens What the assistant may read: two switches, each one a source of context, each one yours alone. They follow you from one server and one conversation to the next, and they change nothing for your teammates — everyone on the team decides for themselves.

Your team's other servers

On by default. It can look at every server your team owns — which features are on, how they are configured, and their graphs. That is what makes "set this up the way my other server does" a question it can actually answer.

Turn it off and it stops being told about them at all. The inventory is not built and then hidden; it is not built.

What the bot remembers here

Off by default. If AI Memory is on, the bot notes things it learns about your server from conversations on Discord. Granting this hands those notes to the assistant along with your question, so it can take them into account.

It is off until you turn it on for a reason: it is context the assistant never used to have, it is re-sent with every question you ask, and what it contains was written by your members rather than by you.

When it is on, what it receives is bounded on purpose:

• the server you currently have open, and no other,
• notes about the server itself — never the ones the bot recorded about an individual member, which belong to that member's conversation with the bot and stay there,
• a fixed number of the most recent notes, each one cut to a reasonable length, so a growing memory cannot quietly grow the cost of every question.
• only while the server's memory setting is on. Turning it off stops the bot recording, and it stops this too — the notes already written stay where they are, and nothing is handed over.

Two limits that are not optional

• It never sees your credentials. API keys, tokens and secrets are masked before it is told anything, exactly as they are everywhere else in the panel.
• It only ever writes a graph, on the server you currently have open. It cannot change feature configuration, and it cannot touch another server.

⚙️ Which model it uses

By default it uses the model configured by the platform. A team can bring its own instead — its own API key, its own model, or its own endpoint. Any OpenAI-compatible endpoint works, and in that case no API key is needed.

The endpoint has to be reachable over HTTPS at a public address. A model running on your own laptop behind your router is not — the panel is a server elsewhere, and letting it call private addresses on request is a well-known way to turn a product into a scanner of its own network. Self-hosting works when the endpoint is published; a machine on your desk does not.

You set it on your team settings page, under Assistant model. Only the team owner can change it, because it is a credential rather than a preference. The key is stored and never shown again: leave the field blank when saving and the stored one is kept.

List models next to the model field asks the endpoint what it actually serves and offers the answer as suggestions — it uses the URL and key currently in the form, so you can check an endpoint before saving it. The field stays free text: publishing a model list is optional, and several self-hosted servers do not, so when nothing comes back the reason is shown and you type the name yourself.

💡 Getting a good answer

Say what should happen and to whom, not which cards to use — deciding that is its job:

• "Give the Veteran role at level 25, but only to boosters."
• "When someone solves the Wordle in three tries or fewer, grant 200 XP and congratulate them in #general."
• "Same as my other server's graph, but with the announcement in #levels."

Then read the reasoning, check the cards it chose, and apply.

Ask it to change one thing at a time. A short, specific request produces a short list of changes, which is far easier to check in the review window than a dozen at once.