Glossary
AgentMux has its own vocabulary. This page is the authoritative source — when two pages use a term differently, this one wins.
agentbus — The cross-process, cross-machine message bus that lets agents (and the panes they live in) exchange messages. Two delivery models: jekt and message. See Reactive event bus (Wave 2) for the full surface.
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/agent-app-api.
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.
block — An immutable persisted unit of pane state. A block is the smallest thing the reducer writes. Terminal output, code block, diff, chat message — each is one or more blocks. Layered structure with reducer-driven mutations. See The reducer stack.
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 146 runtime on Windows, macOS, and Linux. See Architecture overview.
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 sidecar and the Chromium subprocesses. See Architecture overview.
Identity bundle — A named credential set bound to an agent at launch. Decouples who an agent acts as (GitHub PAT, AWS profile, API keys) from what an agent does (the Memory bundle). The same Memory can run as multiple identities — work, personal, demo — without restart. See Identity bundles.
instance — One AgentMux process tree, rooted at one launcher, with its own sidecar, host, renderer(s), and Job Object. 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 version, not by instance. Two same-version portables launched from different folders are two distinct instances (two process trees, two Job Objects) that share the same on-disk SQLite database — see Multi-instance & dev mode for the per-instance vs per-version split.
jekt — Verb. Inject a message directly into a target agent’s terminal stdin. Synchronous, immediate processing. Counterpart to message. The MCP tool mcp__agentbus__inject_terminal is the primary entry point.
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 bundle — An agent personality + capability stack: provider, model, instructions, MCP servers, skills, environment. Reusable across launches. Memory is what an agent does; Identity is who it does it as. See Memory bundles.
message — Verb. Deliver a message to the recipient’s mailbox; the recipient reads it when they’re ready. Asynchronous counterpart to jekt. The MCP tool mcp__agentbus__send_message is the primary entry point.
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.
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. Panes have types: terminal, agent, code editor, browser, swarm, subagent, system metrics, code preview. The user composes a workspace by mounting panes in a grid. The browser type is a special case — see browser pane.
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.
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.
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. AgentMux’s Subagent Watcher tracks these and gives each one its own focused activity-stream pane. See Subagent Watcher.
swarm — The multi-agent orchestration view. Shows every active and completed subagent across your workspace, with event counts, models, and last-activity timestamps.
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.
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.