Skip to content

20 — Glossary

The canonical reference for the vocabulary The Aetherium Engine uses across this documentation set: a tight definition for each term and a pointer to the section that explains it in full.

Terms are alphabetical. The definition tells you what a term means; the section link tells you where to read the whole story — the glossary defines and points, it does not re-explain.

A

  • Agent — The basic unit of execution, defined by four pieces every time: a persona (name, title, description), a system prompt, a tool allowlist, and a model assignment. "Agent" is the runtime concept; a Role is the same thing persisted to the database. §04
  • The Aetherium Engine (the Engine) — A multi-agent AI orchestration platform that runs locally, coordinating teams of agents so they collaborate on a task instead of you driving a single chat. Written "The Aetherium Engine" on first reference, "the Engine" after. §01
  • Audit trail — The PostgreSQL record of every gated tool call. Elevated and Restricted calls capture full arguments and result; Standard calls keep a truncated summary. §07

C

  • ChromaDB — The vector store holding the Engine's knowledge embeddings. It needs a POSIX-locking filesystem (ext4/btrfs/xfs, never NTFS) and is treated as infrastructure, not an integration. §03
  • Circuit breaker — The fail-fast layer that halts a runaway run before it burns the GPU, tripping on turn caps, identical-call loops, the plan-step timeout and the re-plan cap. Thinking models get widened ceilings. §06
  • Context window — The LLM's token input limit, set per template. When history exceeds the budget, ContextManager keeps the first and last two messages and drops oldest middle ones to fit 85% (15% reserved for the response). §04, §06

D

  • delegate / reply — A supervisor's two coordination tools: delegate hands a task to a named worker, reply sends the final response to the user. The router injects both for any supervisor, even when the template omits them. §07
  • DockerService — Owns each project's workspace container — create, start, exec, monitor, stop, destroy — giving agents an isolated filesystem and shell sandbox. §06
  • dynamic-parallel — The fifth dispatch shape: an escape hatch where the supervisor calls spawn_subagents (an Elevated tool) and the orchestrator runs the resulting workers in parallel. It powers research-team and is deliberately not a peer of the four topologies. §06, §04

E

  • edges — The template array that wires a team graph. It does real work only for Hierarchical; for the other shapes it documents intent rather than something the runtime reads. §08
  • Egress gate / DLP — The pre-execution hook on the four outbound tools. It enforces a per-team domain allowlist and scans outgoing arguments for credential shapes, blocking the call if a secret would leave the box. §07

F

  • Four-edit tool rule — Adding a tool is four edits, plus a fifth that bites: the [McpServerTool] method, a dispatch arm in McpToolRouter, a ToolToServerGroup entry, and a ToolDocs entry — plus an optional ToolSecurityLevels entry (omit it and the tool runs at Standard tier with no approval gate). §19, §12
  • Fresh-clone build prerequisite — On a fresh Linux clone the first build fails until empty bin/ and obj/ folders exist. The fix is a one-time mkdir; no deploy script does it for you. §10

H

  • Hierarchical — The topology in which a supervisor plans and delegates to workers via delegate. It is the only topology that consumes edges. §04

I

  • In-process MCP host — The architectural choice (ADR 1) that every MCP server class loads into the orchestrator's own process — no socket, no subprocess, no broker — so the MCP wire protocol collapses into method calls. §03, §17
  • Tool-result card — The typed view a tool returns alongside its text, so the UI can render a real diff, terminal output with its exit code, or a search result instead of one generic block. Card kinds are diff, terminal, read, search, web and generic. §07

K

  • Knowledge base — The searchable store of background information for a team, held in ChromaDB as per-project, global, and per-domain collections and queried with search_knowledge. It is shared, queried, and large, unlike Memory. §04

L

  • Lessons — Per-task notes the supervisor accumulates and LessonService persists, semantically searched and injected before a turn and reinforced or decayed after. §06
  • LLM router — LLMRouterService, which holds the per-slot runtime instance configuration (endpoints, enabled flags, per-slot concurrency) for Primary, Secondary and every other configured slot and the counters tracking how many calls are in flight against each. It does not choose an instance: that decision belongs to the scheduler, which also serializes calls. §06
  • LM Studio — The default local inference backend, reached over two APIs: the OpenAI-compatible /v1 for inference and a native management API for loading and unloading models. Any OpenAI-compatible server can stand in. §13
  • Long-term memory — The append-only Memory tier, accumulated across sessions; LessonService and SessionSummarizationService write to it. §04

M

  • MCP (Model Context Protocol) — The contract between a host that runs LLMs and a server that exposes tools: the server advertises tool schemas, the host invokes by name with structured arguments, the server returns structured results. §04
  • MCP server class — A focused capability boundary: a C# class that groups related tools, hosted in-process — not a separate running process. Ten ship, each carrying [McpServerToolType]. §07
  • MCP server (group key) — The mcp_servers allowlist sense: one of the ten group keys an agent declares (workspace, shell, research, knowledge, quality, planning, comms, orchestration, team, comfyui). The key is not always identical to the class name — comms maps to CommunicationTools, team to TeamMessagingTools. §07
  • McpSessionContext — The per-turn context object carrying project ID, agent identity, container and workspace paths, authorized server groups, allowed domains, argument defaults, and the agent's knowledge scope and image model — made ambient through an AsyncLocal provider. §07
  • McpToolRouter — The service that decides whether a tool call runs and where, owning schema discovery, the three-layer permission model, and dispatch into the right server class. §06
  • Memory — The per-agent state that survives across turns, stored in PostgreSQL and injected automatically by the orchestrator at turn start. Two tiers — working and long-term — private, automatic, and small, unlike the Knowledge base. §04
  • Memory bank — The persistent context layer in .memory/ that bridges the Engine's own development sessions: four canonical files, updated through the update-memory-bank skill. §05
  • ModelScheduler — ModelSchedulerService, which serializes every LLM request behind a channel so the system never asks LM Studio to thrash between models. It honors the orchestrator's affinity pins for the life of a build. §06

N

  • Network isolation as the trust boundary — The Engine's most consequential open trade-off (ADR 3): the orchestrator API has no built-in authentication, so keeping it on a private network or behind an authenticating proxy is the operator's responsibility. §17

O

  • Orchestrator API — The inbound control surface under /api/orchestrator, whose key endpoints are the synchronous POST /run and POST /run-from-template. It carries no built-in auth. §13
  • OrchestratorService — The heart of the ReAct loop: it dispatches a message to the right topology handler, drives each agent's tool loop, triggers re-planning on failure, and enforces circuit-breaker checkpoints. §06

P

  • Plan — A structured step list a supervisor builds with create_plan; each step names the work, the responsible agent, and the required tools. The supervisor delegates against it in order and revises it through re-planning when a step fails. §04
  • Project — What gets created when you instantiate a Template: the database row plus the chat history plus the team's working area — the thing you click in the sidebar. §04
  • Push-dispatched supervisor — The coordination model (ADR 2): the supervisor's LLM makes every delegation decision through tool calls and workers execute what they are assigned. Workers never self-select from a shared queue. §17

Q

  • Quick Create — The natural-language alternative to picking a Template: you describe what you want and TeamGeneratorService synthesizes the team. The result is still a Project plus a Workflow Template. §04

R

  • RAG — Retrieval-augmented generation, the pattern behind the knowledge base: a query is embedded, ChromaDB returns the nearest chunks within the agent's knowledge scope above a cosine floor (ChromaDb:ScoreFloor, 0.525), and they are injected into the agent's turn as reference data. §04
  • ReAct loop — Reason → Act → Observe, repeating: the host asks the model to think and choose a tool, executes it, feeds the result back, and continues until a turn has no tool calls. It drives every agent. §04
  • Reflection — An optional self-critique turn (ReflectionService) the supervisor takes between a worker's reply and synthesis, up to three passes. Configured per node; no shipped template enables it. §06
  • Role — The database representation of an Agent — one row per agent in the roles table. Distinct from the template role field, which names a node's kind (supervisor or worker). §04
  • Roundtable — The topology in which every agent answers the same prompt in parallel, then critiques and reconciles peers' responses over later discussion rounds (config.discussion_rounds, default 2). Shipped as roundtable-review. §04

S

  • SearXNG — The self-hosted metasearch engine backing web_search, with a DuckDuckGo fallback. Optional, deployed via a separate compose file. §13
  • search_knowledge / write_knowledge — The two KnowledgeTools: search_knowledge runs semantic search over the calling agent's knowledge scope; write_knowledge saves a document and persists the file even when ChromaDB indexing fails. §07
  • seedKnowledgeBase — The outer-object (camelCase) template flag that gates the one-time knowledge-seeding job. Independent of target_collections. §08
  • Sequential — The topology that runs nodes in array order, feeding each agent's output to the next. edges are documentation only. Shipped as sequential-docs. §04
  • SessionSummarizationService — At session close, it writes summaries through the scheduler at low priority, updates both memory tiers, and triggers lesson extraction — the seam between the runtime loop and persistence. §06
  • SignalR hub — The real-time layer. Four hubs carry different concerns — NotificationHub, ProjectRunHub, ContainerHub, TeamHub — staying thin and delegating every broadcast to a service. §06
  • Single — The topology in which one agent runs the ReAct loop alone; the example template is quick-script. §04
  • .slnx vs .csproj publish gotcha — dotnet build works against the .slnx, but dotnet publish against it produces no runnable server output. The rule: always publish the server .csproj directly. §10
  • SSR double-registration — The rule (ADR 6) that a client service used during server-side prerendering must be registered in both Program.cs files, or SSR throws InvalidOperationException. The most common cross-tier mistake. §17
  • Supervisor — An agent whose role is to plan and delegate. In a Hierarchical team it builds a Plan, delegates, reflects, re-plans, and synthesizes; it is marked is_supervisor: true. §04
  • Supervisor auto-repair — The defense-in-depth normalization that guarantees exactly one supervisor with delegate and reply, gives every worker reply, and derives mcp_servers from each node's tools. It runs as teams are generated and instantiated, and re-runs on the next load of a drifted legacy team. §06, §12
  • SystemSettings — The PostgreSQL key-value table of runtime-mutable knobs that take effect without a restart. It is the highest layer of the configuration precedence chain. §09

T

  • target_collections — The team-level array naming the knowledge collections agents write into; it routes write_knowledge by injecting the names into agent prompts. §08
  • TeamNode — One entry in a template's nodes array, which is to say one agent, carrying its id, role, is_supervisor, model_id, system_prompt, tools, and mcp_servers. §08
  • Template — The JSON blueprint that wires a team's topology, agents, tools, and scaffolding; TemplateService loads and instantiates it. The product name surfaced in the UI is a Workflow Template. §04, §08
  • Thinking model — A reasoning-tuned model, identified by the Engine's model-capability table rather than by configuration. When one is the team's default, the Engine applies the team's thinking_model_overrides to its circuit-breaker ceilings. §09
  • Three-layer permission model — The model (ADR 4) that gates every tool call in order: connection (the mcp_servers allowlist of server classes), capability (the per-tool allowlist, stripped from the schema before the LLM sees it), and runtime (the security-tier gate). §07
  • Tool — One method on an MCP server class, described by a JSON Schema reflected from its attributes. Thirty-seven ship across the eleven classes. §07
  • Tool catalog drift — The boot failure ToolCatalogValidator raises when the routable catalog and the prompt-enhancer's docs disagree; the Engine fails fast rather than lie to the model. Distinct from [TEMPLATE-DRIFT]. §07
  • tool_defaults — Per-run argument defaults supplied on the orchestrator API request (the toolDefaults field), which flow into McpSessionContext. It is not a template field and not a configuration key. §08, §09
  • Tool tier — A tool's security level, tracking blast radius: Standard runs immediately with a basic audit record (29 tools); Elevated captures full arguments and result (8 tools); Restricted blocks for human approval via ToolApprovalService (one, download_pdf). The assignment lives in the static ToolSecurityLevels map — code, not configuration. §07
  • Two-homes split — The LM Studio gotcha that loading and inference are addressed independently: a model is loaded against one URL and inference is sent to another. Mis-set one and chat keeps hitting the old endpoint. §13

U

  • Unified Studio — The visual workspace where you chat with the team, watch tool calls stream in, and inspect the team graph. A project opens here once its workspace finishes provisioning. §04

V

  • VRAM orchestration — VramOrchestrationService, which makes a run's models resident before it starts by taking a run-priority lease from the inference arbiter (InferenceLeaseService) and releases it afterwards. Every load is planned against the card's real contents: models held by other leases and models the Engine did not load are never evicted, the standard set is evicted when a run needs the room and restored once the slot is idle, and a model that cannot fit beside what is protected fails the run with the numbers. §06
  • Inference lease — the arbiter's unit of residency: a consumer (run, interactive or batch priority) holds one or more models on a slot for a TTL, touches it to keep it alive, and releases it. Run evicts interactive at once; run preempts batch cooperatively; interactive is resident-only (granted only for a model already on the card, never loads or preempts) and is refused while any run or batch lease is live on the slot; batch that cannot be granted, or that would start a service or load a model while a run is live on the card, queues. api/inference/leases and api/inference/queue. §06

W

  • Webhook API — The outbound push direction: a target registers a URL, a shared secret, and glob event patterns, and deliveries are HMAC-signed and fire-and-forget. A failed delivery drops into an in-memory dead-letter queue that retries, then clears on restart. §13
  • Working memory — The Memory tier overwritten per session — a scratch pad of the current task that the supervisor updates as the conversation progresses. §04
  • Workflow Template — The locked product name for a Template: the JSON blueprint that turns one click into a wired agent team. Its schema is camelCase on the outer object and snake_case inside the team block. §08
  • Workspace — The on-disk directory tree where agents read, write, and execute files for a Project, bind-mounted into that project's Docker container. §04
  • Workspace tiers — The three storage tiers — Production, Staging, Temp — each with its own resource ceiling and retention. An unknown or empty tier name falls back to Staging. §09

Where to go next