Glossary¶

Canonical definitions for every term used across the Tryll documentation. Every page links the first mention of a term below to its anchor on this page. Subsequent mentions render as plain text.

Terms are grouped by topic so related concepts sit next to each other.

Sessions, agents, and turns¶

Agent¶

A server-side object that owns one conversation: its dialog, its compiled workflow, its retained knowledge, and a handle to the models it needs. Each agent belongs to exactly one session and is referenced by a numeric agent_id. Created via CreateAgentRequest, retired via DestroyAgentRequest.

Session¶

The logical scope a client works in on the Tryll server. The client opens a TCP socket (the server answers with ConnectionReady), then sends one CreateSessionRequest and receives a session_id. There is at most one session per connection, and only CreateSessionRequest creates it. All later requests on that socket are scoped to the session; closing the socket ends the session and destroys every agent it owns.

Turn¶

One request–response cycle initiated by a user message. A turn begins when the client sends SendMessageRequest and ends when the server emits TurnComplete. Between those two frames the client may receive zero or more AnswerText chunks (see streaming). Only one turn is in flight per agent at a time.

Dialog¶

The ordered list of interactions belonging to an agent — the conversation as the server sees it. Each turn appends exactly one interaction. Used by the projection stage to build the next prompt.

Interaction¶

A single user-and-assistant exchange within a dialog. Holds the user message, the assistant response, any retrieved knowledge components, and (when diagnostics are on) per-node debug information.

Graphs, nodes, and workflows¶

Workflow¶

The overall per-turn behaviour of an agent — what happens between receiving the user message and emitting TurnComplete. A workflow is defined by a graph of nodes and is compiled from a GraphDescription when the agent is created.

Graph¶

A declarative description of a workflow: a list of nodes, where each node's typed params carry both its configuration and its exit wiring, plus a start node name. Built client-side with the graph builder APIs, validated server-side at agent creation. Compilation failures surface as error 3003 (see error codes).

Node¶

A single unit of computation within a graph. Each node has a typed parameter struct containing both its configuration and one or more named exit fields, and well-defined side effects on the dialog. See Workflow Nodes for the full, current catalog of built-in node types.

Exit route¶

A named output of a node. Each exit is encoded as a typed string field on the node's params object using the naming convention <exit_name>_exit (e.g. triggered_exit, not_triggered_exit). An empty string routes the turn to end-of-turn; any non-empty value names the next node to execute. For example, RegexGuardrailNode has triggered and not_triggered exits; ToolCallNode has tool_called and no_tool_called.

Projection¶

The stage that turns the dialog plus retained state into a prompt for a language model. For Generate nodes, projection also renders the node's Mustache template against the current turn's instruction slots and knowledge components, then splices the result into the prompt at the configured placement. A token budget with hysteresis ensures the prompt fits inside the model's context window. When a rolling summary is present, history replay starts after the newest fold. See the projection concept page.

Rolling summary¶

The compressed record of interactions a Summarize node has folded. Projection appends the newest summary to the system message and replays the dialog only after covered_through. Older summaries stay in the dialog as history and are not rendered. The summary is part of an exported dialog snapshot.

Fold¶

One summarizer pass. It rewrites the rolling summary from the previous summary plus the interactions that have aged out of the hot window (keep_recent_turns). A fold that does not fit the summarizer's own context covers the largest chronological prefix that does, and leaves the rest for a later fold.

Mustache template¶

A Mustache source string attached to a Generate node via the template param. Before each model call, projection renders it against a context that includes {{user_message}}, the {{#instructions}} list from instruction slots, and the {{#knowledge}} list from knowledge components. The rendered text is spliced into the prompt at the position specified by the placement param. See the Use Mustache Templates how-to.

Classify Intent node¶

A node type that maps a user message to a discrete intent label by top-1 vector similarity search over a small, labelled embedded string storage. On a match it attaches an intention component to the current interaction for a downstream Intent to Instruction node to consume; it generates no text and renders nothing into the prompt. See the Classify Intent reference.

Intent to Instruction node¶

A node type that looks up the intent label written by a preceding Classify Intent node in a Map-kind string storage and attaches the matching value as an instruction slot to the current interaction. The downstream Generate node then renders it via its Mustache template. It always takes the default exit. See the Intent to Instruction reference.

Knowledge, retrieval, and storage¶

RAG¶

Retrieval-Augmented Generation. An approach that injects topically relevant text snippets into the prompt so the language model can ground its answer on content the model itself does not "know". In Tryll, RAG is implemented by a Retrieve node in front of a Generate node.

Retrieval¶

The act of selecting the snippets from a knowledge source that best match the current query. Dense retrieval (the default) ranks by cosine distance to the query embedding; lexical retrieval ranks by BM25 keyword score; hybrid runs both and fuses the rankings with Reciprocal Rank Fusion (RRF). Produces knowledge components that the workflow may or may not present to the model.

Retrieve node¶

A node type that searches an embedded string storage (dense, lexical, or hybrid retrieval) and attaches the top-k matches to the current interaction as knowledge components. See the Retrieve reference.

Knowledge base¶

Synonym for "vector index used by a Retrieve node". In Tryll, a knowledge base is realised as an embedded string storage.

Instruction slot¶

A named instruction string attached to the current interaction as a kind=Instruction slot by an Instruction node (or Intent to Instruction). Projection exposes instruction slots to the downstream Generate node's Mustache template as: {{slot.<name>}} (direct lookup) and entries in the {{#instructions}} list (each with {{name}} and {{text}}).

Knowledge component¶

A single piece of retrieved or attached text plus metadata (source, score, chunk id). Multiple components may attach to one interaction. Projection exposes them to the Generate node's Mustache template as the {{#knowledge}} list and {{#knowledge_<source>}} direct-lookup sections.

Chunk¶

One record you wrote in the records file of an embedded string storage. Tryll embeds and indexes those records as they are; it does not split source text, and there is no chunk-size setting. Each retrieval result is one chunk.

Embedding¶

A dense floating-point vector that represents the semantic content of a piece of text. Produced by an embedding model; compared via cosine distance inside an HNSW index.

Embedding model¶

A model whose output is an embedding rather than generated text. Declared in the model catalog with "model_type": "embedding". Referenced by name from RetrieveNode parameters or from an embedded string storage config file.

HNSW¶

Hierarchical Navigable Small World — the approximate-nearest-neighbour index structure used by Tryll's embedded string storage. Optimised for fast cosine-distance search over large vector sets.

String storage¶

A named, session-owned container of plain strings. A node param may name a file path relative to the storage root, and the server loads it when the agent is created; CreateStringStorageRequest (inline array or file path) is the explicit pin. Consumed by canned-response and regex-guardrail nodes, which pick or match one string per invocation. Not embedded, not indexed. See the string storage reference.

Embedded string storage¶

A session-owned vector index built from strings plus a precomputed HNSW file. Two construction paths: a config JSON on disk that names the embedding_model, the records_file (a *.kb.json records array by convention), and an optional *.usearch index (Path A), or an inline array of strings that the server embeds on demand (Path B). Consumed by Retrieve nodes. See the embedded string storage reference.

Canned response¶

A fixed reply selected from a string storage. The canned-response node emits one string from its backing storage or its inline lines (RoundRobin by default, or Random or First) without invoking a language model. The next node is default_exit; an empty default_exit ends the turn. Useful for scripted answers and fallback paths.

Guardrail¶

A pattern-matching check that gates workflow flow. The regex-guardrail node runs an input slot (default user_message) against a string storage of patterns and routes the turn to triggered or not_triggered accordingly. Common use: short-circuit unsafe or off-topic inputs to a canned response.

Models and inference¶

Language model¶

A model that takes a text prompt and emits generated text token-by-token. In the Tryll catalog, language models omit the model_type field entirely — language is the implicit default. See the models concept page.

SLM¶

Small Language Model — a language model small enough to run on consumer hardware (CPU, integrated GPU, or a single consumer GPU). Tryll is designed around SLMs: on-device inference, no cloud round-trip, and aggressive KV-cache management.

Inference engine¶

The backend runtime that executes a model. Each model catalog entry names its engine, and every variant of that entry shares it. The session does not choose an engine: CreateSessionRequest.model_config may carry optional (role, engine) hints, which only let the server initialise those engines early. The default build runs llama.cpp (LlamaCpp), Sherpa-ONNX (SherpaOnnx, for STT and TTS), and ONNX Runtime (OnnxRuntime). OnnxGenAI, WindowsML, OpenVino, and TensorRtLlm are InferenceEngine enum slots reserved for future engines.

GGUF¶

The binary file format used by llama.cpp for quantised language models. Tryll downloads GGUF files from HuggingFace for catalog entries whose inference engine is llama.cpp.

LoRA adapter¶

A small GGUF file, fine-tuned for one base language model, that changes how that model behaves for a narrow job. An LLM node runs its model with up to 8 adapters, each with a scale (1 = as trained, 0 = off), listed in the node's adaptation table. Fixed when the agent is created. See Use a LoRA Adapter.

Model catalog¶

The server's models.json file — the authoritative list of models Tryll can download, load, and run. Each catalog entry declares a name, a purpose (model_type: language — the default when the field is omitted — embedding, stt, tts, or vad), default sampling parameters, and one or more variants. See the model management reference.

Model variant¶

One concrete packaging of a catalogued model, such as one GGUF quantisation. All variants of one catalog entry share a single inference engine, and loading the model uses that engine. LoadModelRequest takes a model name and an optional memory placement hint; it does not select an engine or a variant.

Variant¶

Short form of model variant.

Pinned retention¶

A model-loading policy that keeps a language / embedding / STT / TTS model resident in memory until an explicit UnloadModelRequest (and no live users remain). Suitable for the hot model(s) on a given machine. Opposite of OnDemand retention. VAD catalog entries are not pin/unloadable.

OnDemand retention¶

A model-loading policy that loads a language / embedding / STT / TTS model when an agent (or voice input / TTS / embedding use) needs it and unloads it when unused — after DestroyAgent, or when the next validated model load sweeps idle OnDemand entries across all four caches. Trades memory for latency. Opposite of Pinned retention.

Context (KV)¶

The KV cache — the cached attention keys and values for every token a node has processed. Tryll keeps one KV cache per node, per agent; only the model weights are shared, and agents on the same model queue on its FIFO scheduler. Tryll reuses as much KV state as possible across turns when the prompt prefix is stable; this is what makes conversational inference fast.

TTS¶

Text-to-speech — turning text into spoken audio. The Generate and Speak node voices generated tokens sentence by sentence as they stream; the Speak node voices a slot's text. Both speak with the agent's voice profile; neither node has voice settings of its own.

Voice profile¶

An agent's one voice (VoiceProfile): the TTS model from the model catalog (tts_model_name, required), the base identity (speaker_id, a reference clip, or a voice description), speed, language, emit_visemes, and named delivery modes. Passed at CreateAgent and replaced with SetAgentVoice. Every speaking node of the agent uses it, so one workflow can serve many characters. See Voice Profile.

Delivery mode¶

A named way of speaking that a voice profile defines, such as angry or whisper. Game code switches it with SetAgentDeliveryMode, which applies from the next sentence. neutral is built in and means the plain voice. What a mode can change depends on the TTS model: a different reference clip, a Maya1 delivery clause, the Chatterbox exaggeration, or only speed. See Voice Profile and Add Emotions to a Voice.

Prompts, tokens, and streaming¶

Prompt¶

The concatenated input passed to the language model at generation time: system preamble, projected dialog, attached knowledge, tool descriptions, and the current user message. Produced by projection.

Token¶

The atomic unit the language model reads and emits. Each model has its own tokenizer; token counts for the same text differ between models. Token budgets in projection are measured in tokens of the active model.

Token budget¶

The number of tokens a language-model node's projected prompt may use: that node's context size minus the headroom reserved for the generated response. Each node trims its own prompt; there is no per-agent setting. Exceeding the budget triggers dialog truncation with hysteresis.

Streaming¶

The mode in which the server emits generated text in chunks rather than waiting for the full response. Each chunk arrives as an AnswerText frame carrying only the new text (is_delta = true). The last chunk from each node carries is_final = true; for streamed output it is an empty terminator. TurnComplete follows once the turn ends. See how to stream answers to a UI.

Tool calling¶

Tool call¶

A structured instruction emitted by a language model indicating it wants to invoke a named external function. In Tryll, tool calls are detected only — the server parses them from model output and never runs the tool. A ToolCallNotification goes to the client only when the node's disposition notifies; the default Acknowledge records the call without telling the client. See the tool calling concept page.

Tool-call format¶

The specific textual convention the language model uses to express a tool call. Tryll follows the model's own chat template for both prompting and parsing, so there is nothing to choose. The tool_call_format field on the tool-call node is deprecated and ignored by the server.

Constrained decoding¶

Forcing a language model's output to match a formal grammar at every decode step: tokens that could not legally continue the output are masked out before sampling, so malformed output is impossible (not merely discouraged). Also called grammar-constrained generation. In Tryll it is exposed via the grammar param on Generate and Generate and Speak nodes. It guarantees the output's shape, never its meaning — a constrained model can still emit a valid-but-wrong answer. See the constrained output concept page.

GBNF¶

GGML BNF — the grammar notation used by llama.cpp (and therefore by Tryll's grammar param) to describe constrained output. A grammar is a set of name ::= … rules over string literals, alternation (|), and sequences; it must define a rule named root and must not be left-recursive. See the upstream GBNF guide for the full syntax.

Transport¶

Wire protocol¶

The byte-level contract between the Tryll client and server: TCP transport, 4-byte little-endian length prefix, FlatBuffers payload, 1 MiB max frame. See the wire protocol reference.

Editor tools¶

Chat Window¶

An editor-only window (Window ▸ Tryll ▸ Chat in Unity, Window ▸ Tryll ▸ Tryll Chat in Unreal) that creates its own agent from a scene component and lets you converse with it without entering Play mode. Hosts the turn inspector in a side pane. See Test an agent in the editor.

Dialog Lab¶

An editor-only window that runs one scripted dialog across parameter variants and seeds, then shows every result side by side so the spread is visible. Makes no quality claim — it shows raw output, deterministic checks, and timings. Ships in both editors. See Compare dialog variants.

Agent Log¶

An editor-only window that records what this editor process sent to and received from each agent — turns, voice transcripts the client sent, deferred variable flushes, and lifecycle events — as a per-agent narrative rather than an event dump. Scoped to one client connection, not the whole server. See Use the Agent Log.

Turn inspector¶

The shared panel that explains a single turn: which nodes ran and via which exit routes, per-node timing, the node parameters used, the rendered prompt and output, retrieval hits, and tool calls. One implementation, hosted by the Chat Window, Agent Log, and Dialog Lab. See the turn inspector reference.

Turn diagnostics¶

The per-turn debug_info payload the server attaches when an agent was created with enable_diagnostics. It is the data the turn inspector renders. The flag is structural — it cannot be enabled on an agent that already exists.

Server monitor¶

A contributor-facing browser UI served by a dev-time HTTP/SSE sidecar in the server process. Sees every session on the server, which is its advantage over the Agent Log; it cannot see what a client sent, which is the Agent Log's. Compiled out of Production builds.