Glossary
AgentMux has its own vocabulary. This page is the authoritative source — when two pages use a term differently, this one wins.
ABF (Agent Bundle Format) — The file format for exporting and importing a bundle as a single .abf file: instructions, skills, MCP servers, native memory and credential requirements, composing existing standards (Agent Skills, MCP server.json, AGENTS.md). It was called the Armory Bundle Format; the letters and the .abf extension are unchanged. See Agent Bundle Format (ABF).
agent operating environment — How AgentMux positions itself: more than a workspace, it’s an environment where agents are first-class residents with stable identity, memory, a streaming parser, lifecycle management, and access to the MuxAPI. An agent running inside AgentMux can open panes, rename tabs, discover peers, and send messages — not just process text.
MuxAPI (formerly the Agent App API) — The typed RPC surface an agent uses to call back into the AgentMux workspace — spawn panes, set titles, render dashboards, update status. See /internals/muxapi.
AppImage — The Linux distribution format for AgentMux. A single self-contained executable (.AppImage) that bundles the app, the Chromium runtime, and all shared libraries. Run directly: chmod +x AgentMux_amd64.AppImage && ./AgentMux_amd64.AppImage. On first launch it extracts itself to ~/.local/share/agentmux/extracted/<version>/ for faster subsequent starts. See Installation.
agent pane — A pane that runs an AI agent session. Streams the agent’s tool calls, reasoning, and file diffs into a structured view. See Pane types.
ambient — A model call AgentMux makes on its own, not one you asked for: pane titles, activity summaries, ghost-text prompt suggestions, narration and the continuity summary. These use a small, fast model and are counted as “AgentMux internal” in token usage. “Ambient” says how something was produced, never where it goes: text sent into the agent is a context delivery. (The same word also appears in ambient login, the host’s own CLI login; that’s unrelated.)
block — One view instance: an Agent, a Terminal, an Editor, a Browser and so on, with its own settings (its meta: the view type, the file or URL, zoom, colour) persisted by the sidecar. Each pane tab is one block. The layout records which blocks sit in which pane. Blocks are not pieces of output: a terminal’s output or an agent’s messages live inside their block. See Persistence and Pane types.
bundle (formerly “Preset”) — A reusable package of an agent’s instructions, MCP servers, memory and skills. An agent takes several, in order: its own bundle first (created with the agent), then the ones picked in the new-agent form’s Bundles field, the launch modal or the Stash. Each picked bundle’s instructions go into the agent’s startup file after Global Memory. A bundle is what an agent does; its Identity is who it does it as. Managed in Memory → Bundles; exported and imported as ABF files. See Bundles.
browser pane — A pane of type browser — an embedded CefBrowserView (a child Chromium browser, not an iframe). Each browser pane runs in its own renderer process; opening more browser panes adds more renderer processes. See Browser pane and Pane types.
CEF — Chromium Embedded Framework. The host process embeds Chromium via CEF to render the SolidJS frontend; this replaces the platform WebView and gives AgentMux a consistent Chromium runtime on Windows, macOS, and Linux. See Architecture overview.
channel — A named on-disk data-dir scope that groups AgentMux builds for shared agent definitions and settings. Key channels: stable (installed + released portables), local-<branch> (locally built portables), dev-<branch>-<clone> (dev-mode builds). Agent definitions and settings.json persist within a channel across version upgrades; runtime databases (SQLite, CEF cache, IPC artifacts) are scoped per (channel, version). See Multi-instance & dev mode.
Connectors — The app-wide pane for what agents connect to outside AgentMux, in three sections: Accounts (sign-ins to providers and services such as Claude, Codex, GitHub, Google Workspace, AWS, OpenAI, Anthropic, Slack and AgentMux Cloud, bound to agents), MCP servers and Remotes (SSH hosts and WSL distributions). Opened from the widget bar, the hamburger menu (≡) or the command palette. Together with Memory it replaced the Armory. See Connectors.
context delivery — Content an agent is given without you typing it: its memory at a new session, after /clear or after a compaction, and Claude Code’s conversation summary after a compaction. The agent pane shows each one as a card that lists what was given, one row per item; a summary card also shows a one-line excerpt, and opens to the full text. See Memory and Conversation overhead.
document tab — One file inside one block, shown in a tab strip under the pane header: the Editor’s files and the Media pane’s files. The innermost of the three kinds of tab, after window tabs and pane tabs. A document tab is another document in the same pane; Agent, Terminal and Browser panes have none.
Global Memory — Entries composed into every agent’s startup file (CLAUDE.md, AGENTS.md, GEMINI.md, …) at launch, as # [Workspace] <name> sections, after AgentMux’s own Operator Config entries (# [AgentMux System]). Managed in Memory → Global; agents use the GlobalMemory* MCP tools. Shared by the channels that share your main accounts.
host — The CEF process (agentmux-cef). One per instance. Owns the OS windows, the browser panes, the JS bridge, and IPC fan-out to every renderer. Spawned by the launcher; spawns the Chromium subprocesses. (The sidecar is also spawned by the launcher, which owns its lifecycle — see Architecture overview.)
Identity — An agent’s directly-bound accounts, at most one per provider: who an agent acts as, as its bundles are what it does. A new agent takes the provider’s first account; Bind changes it. See Identity & Accounts.
instance — One AgentMux process tree, rooted at one launcher, with its own sidecar, host, renderer(s), and process-isolation container (Job Object on Windows / process group on Linux + macOS). Each launch of agentmux-launcher creates a new instance. Multiple instances run side-by-side. The “other AgentMux instances on LAN” entries shown in the status bar each correspond to a separate instance. See Multi-instance & dev mode.
Note: “instance” is not one process — a baseline single-window dev session has 4 processes (launcher + sidecar + host + 1 renderer), plus shared GPU/utility Chromium subprocesses, plus more renderers as windows and browser panes are opened.
Note: instances and data dirs don’t always map 1:1. The data dir is keyed by channel, not by instance. Two portables on the same channel launched from different folders are two distinct instances (two process trees, two process-isolation containers) that share the same on-disk SQLite database — see Multi-instance & dev mode for the per-instance vs per-channel split.
jekt — Verb. Inject a message directly into a target agent’s terminal stdin. Synchronous, immediate processing. Counterpart to message. Use the SendMessage MCP tool (MuxAPI) or POST /agentmux/reactive/inject to jekt an agent.
Knowledge — The former name of the Memory pane. Panes, widget-bar pins and keybindings (app:knowledge) saved under it are moved to Memory the first time it starts after updating; layout files that use it still open Memory, and /knowledge/ links redirect.
launcher — The 325 KB shim process (agentmux-launcher) that boots AgentMux. Spawns the host and sidecar, holds the IPC auth-key, tracks window reality. See Architecture overview.
Memory — The app-wide pane for what agents know and carry, in four sections: Global (Global Memory), Personal (Personal Memory), Skills and Bundles. Opened from the widget bar, the hamburger menu (≡) or the command palette. Formerly Knowledge; together with Connectors it replaced the Armory. “Memory” on its own means this pane; the other kinds are always qualified as Global or Personal Memory. See Memory.
message — Verb. Deliver a message to the recipient’s mailbox; the recipient reads it when they’re ready. Asynchronous counterpart to jekt. Use the SendMessage MCP tool (MuxAPI) with the target agent’s name.
MuxBus — The cross-process, cross-machine interagent messaging substrate, in three tiers: Host (in-process reactive handler, same AgentMux instance), LAN (mDNS peer-to-peer forwarding, same network, v0.46+), and WAN (opt-in cloud relay you operate). Two delivery models: jekt and message. Powers the DiscoverAgents and SendMessage MuxAPI tools. See Interagent Communication and Reactive event bus. (Formerly called agentbus.)
MCP — Model Context Protocol. A JSON-RPC protocol that AI agents use to talk to external tools and data sources. Agents subscribe to MCP servers; MCP servers expose tools, resources, and prompts.
Muxqueue — The shared work queue: durable items any agent can enqueue and claim later. The pull counterpart to MuxBus’s push — SendMessage names a recipient and delivers now; a Muxqueue item waits to be claimed instead (usually by anyone, optionally restricted to one agent or group). Claiming grants a time-limited lease, not ownership, so a crashed claimant’s item can be re-offered — though only while it has attempts left, and only once some agent’s next claim triggers the lazy reaper. Lives in the always-global store, so items cross channels and survive restarts. Exposed as the Work* MuxAPI tools and muxspect work. See MuxAPI.
OAC — Origin Access Control. The AWS CloudFront mechanism that restricts S3-bucket access to a specific distribution. Used by the docs and landing infrastructure; not a runtime AgentMux concept.
pane — A UI slot in the workspace layout. A pane holds one or more pane tabs. Panes have types: terminal, agent, code editor, browser, media, swarm, system metrics and more (see Pane Types). The user composes a workspace by mounting panes in a grid. The browser type is a special case — see browser pane.
pane tab — One block stacked in a pane, shown in the pane header’s tab strip: an Agent and a Terminal can share one pane as two pane tabs. The middle of the three kinds of tab, between window tabs and document tabs. A pane tab is a different pane in the same slot. See Pane tabs.
Personal Memory — An agent’s own memory files: notes it reads and writes about itself, kept by its provider (for Claude Code, a memory folder and its MEMORY.md index) and versioned by AgentMux’s memory record, so they follow the agent across accounts and channels. Shown in Memory → Personal and the agent’s Stash → Personal Memory; agents use the Memory* MCP tools. “Native memory” is its storage’s name in the code; it was once labelled “Brain”.
process — An OS process. Avoid in user-facing copy — one instance has 4+ processes (launcher, sidecar, host, renderers, plus Chromium GPU/utility subprocesses), so “this AgentMux process” is ambiguous. Reserve “process” for internal docs that genuinely discuss the process tree.
process group — The Linux + macOS equivalent of a Windows Job Object for AgentMux’s process-isolation needs. The launcher places the host and sidecar in a process group. On Linux, PR_SET_PDEATHSIG ensures child processes terminate when the launcher exits — this prevents orphaned agentmux-cef or agentmux-srv processes if the launcher crashes. On macOS, crashed-parent children are reparented to launchd rather than killed; the process group provides isolation but not automatic orphan cleanup.
reducer stack — AgentMux’s layered state model. Each layer (launcher / host / sidecar / frontend slice) owns a slice of state, with dispatch ordered top-to-bottom. The single canonical place to look for “why did X change?” See The reducer stack.
renderer — A Chromium renderer process (agentmux-cef --type=renderer). Runs the SolidJS frontend JS for one browser context. Not a singleton — every OS window gets its own renderer, and every browser pane inside a window adds another. Multiple renderers per instance is the normal case.
sidecar — The Rust app-domain server process (agentmux-srv). Owns workspaces, tabs, blocks, layouts, agents, identity. Persists to SQLite. Bound to 127.0.0.1 only. See Architecture overview.
skill — A reusable instruction an agent can call, as a /trigger or a Claude Code skill file. Global skills are in Memory → Skills; an agent can also have private ones, and its bundles add theirs at launch.
Stash — The per-agent drawer behind the toolbox icon in an agent pane’s header, with tabs Accounts, Personal Memory, MCP Servers, Skills, Bundles, Registration and Devices: the per-agent side of Connectors and Memory. Its Bundles tab was Startup. See Pane types → Subsections.
streaming buffer — In the agent pane virtualization model: the trailing ~50 message rows that are always mounted in normal flow and not recycled. Eliminates measurement lag during token streams. See Agent pane virtualization.
subagent — An agent spawned by another agent. Claude Code’s sub-agent feature is the canonical example. For Claude Code agents, the Swarm pane tracks these and expands each one’s activity inline under its parent agent.
swarm — The multi-agent overview pane. Lists every running agent pane on this instance as a tree, with each agent’s subagents, todos, shells, cron jobs and background commands, plus a fleet toolbar. See Swarm.
Unix domain socket — The IPC mechanism the launcher uses on Linux and macOS to communicate with the host. The socket lives at $XDG_RUNTIME_DIR/agentmux/<hash>.sock (primary) or /tmp/agentmux-<uid>/<hash>.sock (fallback when $XDG_RUNTIME_DIR is unset), where <hash> is derived from (data_dir + version) — the same isolation key as the Windows named pipe. The counterpart Windows primitive is a named pipe (\\.\pipe\agentmux-<hash>). Both carry the same wire protocol (the reducer command set defined in crates/common/src/ipc). See Platform support → Linux.
window — An OS window owned by an instance’s host. One instance can have many windows. Each window has a backend windowId (UUID), a launcher label ("main", "window-pool-...", internal/IPC), and a window rank. Renamable via the bottom-right window-list popover (open it via the version chip → double-click a row, or press F2).
window rank — A window’s 1-based position within its instance, shown after the version in the status bar as (2), (3), etc. when more than one window is open. Cosmetic only — the underlying identity of a window is the windowId, not the rank.
window tab — A whole layout of panes, shown in the tab bar along the top of the window (Tab 1, Tab 2, …). The outermost of the three kinds of tab, before pane tabs and document tabs.
WRR (Window Reality Reconciliation) — The launcher’s loop that reconciles desired window state (what AgentMux wants) against actual OS state (what the OS says). Defends against state drift when external tools or the user move/resize/close windows. See Window Reality Reconciliation.
If a term is used somewhere in the docs and isn’t here, that’s a gap — please file an issue or PR.