How the Prompt Manager Works in TavernAI 2

Updated

The Prompt Manager in TavernAI 2 is the layer that decides what actually reaches the AI model. Instead of a single text box where you paste a character description and hope for the best, it treats the prompt as a structured system: folders, activation rules, roles, placement, presets, token counters, structural nodes, and visual merge groups. Each character can carry its own prompt tree, and you can open the fully assembled prompt before generation to see every role, source, token, attachment, transformation, and the raw request itself. If you want to understand why a character behaves a certain way — or fix it when it doesn't — this is the mechanism to learn.

The core idea: a prompt is a tree, not a string

In a simple chat app, the prompt is usually one block of text: system message, then history, then your input. TavernAI 2 replaces that with an ordered tree. Each node in the tree is a prompt item, and each item has properties that determine whether it fires and where its output lands in the final request.

The building blocks the site describes:

  • Folders — group related prompt items so you can enable, disable, or reorder them as a unit.
  • Activation rules — conditions that decide when a prompt item is included.
  • Roles — who a prompt item speaks as (system, user, assistant, or character-specific).
  • Placement — where in the assembled prompt the item's content appears.
  • Presets — saved configurations you can switch between.
  • Token counters — visibility into how much of the context window each item consumes.
  • Structural nodes — items that shape the prompt's structure rather than adding prose.
  • Visual merge groups — combine items so they render as a single block in the final prompt.

Because these are properties of items rather than hardcoded positions, the same character can produce very different prompts depending on which folders are active and which rules pass.

How a character becomes its own prompt system

The site states that every character is built from an ordered prompt tree with any prompts, folders, rules, scripts, files, and structure it needs — and that the avatar, identity, and complete behavior travel together in one card. Practically, this means:

  1. You define the character's prompt tree once, inside the card.
  2. The card carries that tree wherever it goes — no separate global prompt you have to remember to load.
  3. Two characters in the same chat can have completely different prompt structures, because each one brings its own.

This is what makes "one world, many lives" work: each character has its own history and knowledge, and when their timelines meet, the shared event is preserved in each life before the stories separate again.

Attaching files directly to prompt items

Any prompt item can take attachments: images, PDFs, documents, audio, video, or text. The site's framing is that files become part of the same context system as characters, scenes, and chat history — they aren't a separate upload bucket. So if a scene depends on a reference image or a PDF of lore, you attach it to the prompt item that needs it, and it enters the assembled prompt alongside everything else.

Verifying what the model actually sees

Before generation, you can open the final assembled prompt. The site lists what's exposed: every role, source, token, attachment, transformation, and the raw request itself. Use this to:

  • Confirm an activation rule fired when you expected it to.
  • Check that a folder you disabled is genuinely absent.
  • See how many tokens an attachment or a long history is consuming.
  • Catch placement mistakes — content landing in the wrong role or position.

If a character is ignoring an instruction, this view is usually where the answer is: the instruction either didn't activate, got merged into a block that diluted it, or was pushed out by token pressure.

A concrete example

Say you're running a mystery scenario with two characters who share a past event.

  • Character A's card has a folder for "shared history" with an activation rule tied to the presence of Character B.
  • Character B's card has its own folder for the same event, written from its perspective.
  • You attach a reference image of the location to a scene prompt item.
  • A structural node places the scene description before the character prompts.
  • A merge group combines both characters' shared-history items so they appear as one consistent block.

Before sending, you open the assembled prompt: both folders fired, the image is attached, the scene sits in the right position, and the token counter shows you have room left. If Character A suddenly acts as if it never met B, you check the activation rule first — that's the most common failure point.

Where to go next

The Prompt Manager is one part of a larger workspace that also covers provider setup, Macros, and PM Scripts. If you haven't installed the app yet, the Windows build targets Windows 10 and 11, and there's a portable option; on a Linux VPS the install script downloads the latest stable build, extracts it to ~/TavernAI, and adds an update script. No account is required, and you bring your own provider — either local GGUF models (CPU, CUDA, or Vulkan) or one of the built-in and custom API integrations.