May 19, 2026 · Kealu Vector Team · Engineering
A consistent set of terms for talking about LLM-based agent systems, with explicit notes on alternatives in current use.
“Mal nommer les choses, c’est ajouter au malheur du monde.” A. Camus
A consistent set of terms for talking about LLM-based agent systems, with explicit notes on alternatives in current use.
This glossary is meant to be internally consistent rather than to reflect a settled standard. The field has not converged on most of these terms; where alternatives are in current use, we name them. Where a term carries a strong classical analog, we name that too. We expect parts of this vocabulary to drift as the field matures.
The goal is not to invent new vocabulary but to pick consistently from existing usage, so that two people who have read this document can talk about agent systems without talking past each other.
The glossary is dated May 2026, and we plan to revisit it every few months.
Model. A large language model as an artifact: the weights, the trained system, the thing accessed via an API call. The model is stateless across calls; it has no memory, no tools, no identity. It is a function from a prompt to a continuation. Other usage: "the LLM," "the base model," "the foundation model."
Agent. A stateful program that issues calls to one or more models in a control loop, maintains context across calls, and may invoke tools to affect the world or read external state. An agent is to a model as a process is to a CPU. The most important distinction this glossary insists on is between the model (stateless, called) and the agent (stateful, calling). Conflating these is a common error in current discourse. Other usage: "AI agent," "LLM agent," "autonomous agent." When ambiguity matters, agent program is unambiguous.
Session. A single running instantiation of an agent; the active execution from the moment context is assembled, and the control loop begins until the task completes or the session is terminated. A session is to an agent as a process is to a program: the agent is the definition (harness configuration, tools, memory references, system prompt); the session is the live execution. Sessions are ephemeral; when a session ends, its working memory (in-context state) is lost, but the agent&039;s durable state (memory, workspace modifications, harness configuration) persists. Recognizing this distinction resolves a common confusion about agent failure: when "an agent goes down," it is typically the session that has ended, not the agent&039;s definition or its durable state. Recovery means starting a new session from the surviving components. Other usage: "run," "invocation," "conversation" (when the session is interactive), "execution."
Agentic AI. A term in widespread use with two distinct senses. In policy and governance literature — notably the OECD&039;s 2026 report The agentic AI landscape and its conceptual foundations (OECD AI Papers No. 56) — agentic AI refers specifically to systems composed of multiple coordinated AI agents that decompose tasks, collaborate, and sustain operations autonomously over extended periods, distinguished from a single AI agent. In vendor and product marketing, the term is used much more loosely, often as a synonym for any LLM-based agent (single or multi-agent). This glossary largely avoids the term in favor of more precise vocabulary: an individual agent is an agent; a coordinated group is a swarm, intra-domain agents, or cross-domain agents, depending on the group’s memory and trust regime. When the term appears in policy contexts, the OECD definition is the most precise current usage. Other usage: "agentic system," "agentic system of systems," "agent ensemble."
Sub-agent. An agent invoked by another agent as part of completing its task. The invoking agent is the supervisor or orchestrator; the invoked agent is the sub-agent or worker. Other usage: "child agent," "delegate." The pattern as a whole is sometimes called agent decomposition or hierarchical agents. See capability agent for the related concept of design specialization.
Capability agent. A sub-agent specialized for a particular capability or narrow class of tasks — built through scoped prompting, fine-tuning, restricted tool access, or some combination. The term capability implies a specialization of the agent to a specific capability; it is a sub-agent nevertheless. The distinction from a generic sub-agent is one of design rather than structure: a sub-agent describes the architectural relationship (who invokes whom); a capability agent describes the design choice (this sub-agent has been built for a specific scope). Most multi-agent systems in production today are organized as a supervisor plus a set of capability agents, each handling one piece of the workload — a coding capability agent, a search capability agent, a verification capability agent. Other usage: "specialized agent," "skill agent" (in older robotics-derived terminology), "expert agent."
Agent runtime. The infrastructure layer that manages agent lifecycle, sub-agent dispatch, state, and coordination across multiple agents; analogous to an operating system for a population of processes. Examples: LangGraph, AutoGen, CrewAI, Kealu Vector, Autellix, Parrot&039;s runtime. Other usage: "agent framework," "orchestration layer," "agent platform." Distinguished from harness (see below): a runtime is concerned with coordination among agents; a harness is concerned with one agent&039;s interaction with the world.
Harness. The execution environment surrounding a single agent, the layer that turns a model&039;s outputs into actual effects in the world. A harness typically provides workspace access (filesystem, shell, sandboxed environment), tool invocation and dispatch, sandboxing and resource limits, observability hooks, and the mediation logic that converts the model&039;s text into structured actions and the world&039;s responses back into context the model can consume. The dual nature is well captured by the phrase part OS, part shell: the harness provides OS-like services (process management, isolation, resource control) and shell-like services (command parsing, dispatch, I/O multiplexing) for the agent it hosts. Examples: Princeton&039;s SWE-agent, OpenHands, METR&039;s evaluation harness, Cursor&039;s coding agent harness. Distinguished from agent runtime: a runtime orchestrates multiple agents (lifecycle, sub-agent dispatch, coordination); a harness mediates one agent&039;s interaction with the world. The two compose — a runtime can spawn agents each running in its own harness — but they solve different problems. Other usage: "agent environment," "agent sandbox," "execution layer." The term harness in this sense became increasingly common in 2024, particularly in coding-agent and evaluation systems, though terminology across the ecosystem remains fluid.
Orchestrator. The component within an agent runtime that manages the workflow — sequencing phases, managing state transitions, enforcing quality gates, and deciding when to escalate, retry, or terminate. Distinguished from supervisor: a supervisor manages agents (spawning, monitoring, restarting); an orchestrator manages the workflow (what happens in what order, with what gates). In practice, the two roles are often combined — a single component both dispatches sub-agents and sequences the workflow — but they address different concerns. When they are separated, the supervisor owns agent lifecycle and the orchestrator owns task sequencing. Examples: the workflow engine in Kealu Vector, LangGraph&039;s graph execution engine, CrewAI&039;s process controller. Other usage: "workflow engine," "coordinator," "conductor." The classical analog is a workflow orchestrator in the microservices sense (Temporal, Conductor) rather than a container orchestrator (Kubernetes).
Model router. The layer that selects the execution model, inference configuration, or model tier used to handle a given request, based on task characteristics, cost constraints, latency requirements, accuracy needs, or provider availability. A model router operates below the orchestrator (which decides what to do) and above the model API (which executes the call). The simplest routers are static mappings (use Opus for planning, Haiku for validation); more sophisticated routers infer task complexity, modality, or uncertainty and route dynamically. The term is gaining traction in industry discourse as model commoditization accelerates — when multiple models can handle the same task, value shifts to the layer that can select among them adaptively. Examples: the model selection layer in Kealu Vector, Martian&039;s model router, Unify&039;s routing API, OpenRouter. Other usage: "model selector," "inference router," "intelligence routing layer" (in investor-facing usage). Distinguished from orchestrator: the orchestrator decides what task to do next; the model router decides which model executes it.
Tool. A function or external service the agent can invoke during its control loop. Tools have a typed interface (name, parameters, return type) and may have side effects. Other usage: "function," "action," "plugin." MCP calls them "tools." Older agent literature called them "actions" or "operators." Distinguished from skill (which is the agent&039;s know-how for using tools) and from workspace (which is what the tools act on).
Skill. A piece of procedural knowledge an agent uses to accomplish a particular kind of task; typically a documented procedure for composing tools, often packaged with supporting files, examples, or templates. A skill is typically a memory of how to use tools, not the tool itself. The tool is the executable primitive (the function call, the API endpoint); the skill is the agent&039;s know-how about how to compose tools to achieve some goal. Examples: Anthropic&039;s Skills (markdown procedures plus reference files for working with specific artifacts), skill libraries in agent frameworks that store reusable task procedures, the prompt fragments and example traces that get loaded into context when an agent recognizes a task it has seen before. Distinguished from tool, memory, and context: a tool is what the agent invokes; a skill is what tells the agent how and when to invoke tools for a class of task; memory is broader (episodic recollection, semantic facts, and procedural knowledge including skills); context is what reaches the model on a particular call (which may include a skill that was retrieved or loaded for the current task). Other usage: "procedure," "playbook," "recipe," "macro." Older agent literature (1990s MAS, robotics) used "skill" specifically for learned motor or task primitives; today&039;s usage is broader and more documentation-flavored.
Workspace. The external state surface the agent operates on during a task; typically a filesystem tree, but also a sandboxed shell environment, a notebook, a database, or a code repository. In the canonical case, a workspace is a filesystem tree that the agent has access to via tools (read, edit, grep). The workspace is provided and bounded by the harness; the agent reaches into it through tools and observes the world through tool returns. Persists across multiple tool calls within a session and is sometimes preserved across sessions. Examples: the working directory in Claude Code, the repository checkout in SWE-agent, the file tree exposed to OpenHands. Distinguished from context, memory, and tools: the context is what the model sees on a particular call (per-call); memory is agent-internal state managed by the runtime (often a vector store or document store); the workspace is external state in the world, mediated by the harness, that the agent acts on through tools. Tools are the interface; the workspace is the substrate. Other usage: "agent sandbox" (overloaded; sometimes refers to the harness itself), "working directory," "agent FS."
Context. The input passed to the model on a particular call; typically a sequence of messages, tool definitions, and instructions. The model&039;s working "view" of the world is its current context. Other usage: "prompt" (when referring to the whole context as text), "input," "conversation."
Context window. The maximum length of context a particular model can accept, measured in tokens. A hard system limit.
Memory. Persistent state maintained by an agent across calls or sessions — separate from the context window, which is per-call, and from the workspace, which is external. Memory typically lives in the agent runtime (in a database, vector store, or file) and is read into the context as needed. Memory subdivides into three types with different properties:
Episodic memory. Records of past interactions and events — what happened, when, and what the outcome was. An agent&039;s episodic memory includes prior task executions, decision traces, error encounters, and user conversations. Episodic memory is autobiographical: it is tied to specific events in the agent&039;s history, not general facts. It is the primary input for learning from experience — an agent that has episodic memory of past security reviews can recognize patterns it has seen before. Distinguished from semantic memory: episodic is "what happened to me"; semantic is "what is true about the world."
Semantic memory. Facts, documentation, domain knowledge, and reference material — what is true, independent of when the agent learned it. An agent&039;s semantic memory includes codebase structure, API documentation, project conventions, and domain-specific knowledge. Semantic memory is referential: it describes the world, not the agent&039;s history in it. Often stored in a vector database or document index and retrieved via RAG. Distinguished from episodic memory: semantic is "what is true"; episodic is "what happened."
Procedural memory. Knowledge of how to do things — encoded in system prompts, fine-tuned weights, and behavioral patterns. Procedural memory overlaps substantially with skills (see above): a skill is a piece of procedural memory that has been made explicit and retrievable. The portion of procedural memory encoded in model weights (via fine-tuning) is not directly inspectable or transferable; the portion encoded in system prompts and skill definitions is.
These three types differ in what can be shared across agents. Semantic memory is the most sharable; multiple agents can reference the same documentation. Episodic memory is less shareable; one agent&039;s execution history is most relevant to that agent and its nearest collaborators. Procedural memory is the least shareable, as it defines what an agent is, and sharing it amounts to cloning the agent.
Other usage: "long-term memory," "persistent state," "agent state." Mem0, Zep, and Letta provide dedicated memory layers; LangChain and LangGraph provide memory abstractions within their frameworks; Kealu Vector and Claude Code maintain memory as file-backed stores loaded into context.
RAG (Retrieval-Augmented Generation). A pattern in which an agent retrieves relevant external information — from a vector store, document index, search engine, database, or knowledge graph — and includes it in the model&039;s context before generation, allowing the agent to reference knowledge that doesn&039;t fit in the context window or wasn&039;t in the model&039;s training data. RAG is an architectural pattern within an agent&039;s control loop, not a type of agent; a "RAG system" or "RAG application" typically refers to an agent (often a simple ReAct-shaped one) whose primary mechanism for accessing information is retrieval over a private corpus. Distinguished from memory: RAG retrieves from external corpora (documentation, knowledge bases, the web); memory (as defined above) is agent-internal state about its own prior interactions. The two patterns often coexist — an agent may have memory of past conversations and RAG access to a knowledge base. Other usage: "retrieval augmentation," "grounding" (when the emphasis is on tying generation to source material), "knowledge-augmented generation." The term was introduced by Lewis et al. (2020).
Blackboard. A shared data structure that multiple agents read from and write to, with agents activated or notified when relevant data appears. The blackboard is a classical AI coordination pattern (Erman et al., 1980, Hearsay-II) re-emerging in multi-agent systems. Distinguished from a shared workspace: a workspace is the external state agents act on (the codebase, the filesystem); a blackboard is the coordination surface agents communicate through (task status, intermediate results, claims). In current agent systems, the pattern appears as shared task boards, CRDT-backed coordination stores, or structured memory regions that multiple agents observe. Other usage: "shared store," "coordination store," "bulletin board."
KV cache. The model&039;s intermediate computation cached across tokens of the same context. A serving-system concept that has become an inter-agent-system concept because the cache can be shared, migrated, or transferred between requests. Other usage: "attention cache," "prefix cache."
ReAct loop. The Yao et al. (2022) pattern: an agent alternates reasoning (model produces a thought) and acting (model emits a tool call), with the result of each action observable before the next decision. The interleaving is the contribution. Other usage: "ReAct agent," "thought-action-observation loop."
Plan-then-execute. A pattern where the agent first produces a complete plan and then executes it without (or with limited) feedback during execution. Contrasts with ReAct&039;s interleaving. Other usage: "planner-executor," "deliberative agent" (in the older multi-agent-systems literature).
Supervisor pattern. A pattern where one agent (the supervisor) decomposes a task and dispatches sub-tasks to sub-agents, often capability agents, then synthesizes their results. The supervisor is responsible for the overall task and for handling sub-agent failure. Other usage: "orchestrator pattern," "router pattern," "manager-worker." The classical analog is the actor-model supervisor tree (Erlang/OTP).
Human-in-the-loop (HITL). A control pattern in which a human reviews, approves, or modifies an agent&039;s proposed actions before they execute. Variants differ in where the human sits and how often they intervene: approval-required HITL (every action awaits human confirmation), checkpoint HITL (human approval at defined points such as the end of a plan, before irreversible actions, or on errors), exception HITL (the agent operates autonomously but escalates to a human on uncertainty, low confidence, or specific triggers), and human-on-the-loop (HOTL — the human monitors but does not gate each action). HITL is the most general defense against autonomous error and a common requirement in high-stakes domains (medical, legal, financial, irreversible-action). Distinguished from autonomous operation: an autonomous agent acts without human approval per action; a HITL agent does not. Distinguished from supervision: supervision is monitoring, whether or not the supervisor can intervene; HITL is gating, where the human&039;s approval is required for action to proceed. Other usage: "human approval," "human review," "user-in-the-loop," "supervised autonomy." The classical analog is a code review gate or a release approval workflow.
Agent systems sit somewhere on two independent axes: whether agents share memory (a workspace, a context, a KV cache) or communicate only by messages; and whether they operate under one trust domain (one administrative authority) or across multiple. The two axes combine into three live regimes, named here for consistent use.
Swarm. A set of agents inside one trust domain that share memory — sub-agents or capability agents under a supervisor, cooperating over a shared workspace, KV cache, or blackboard. Coordination is cheap; restart-on-failure works; the available primitives are shared-memory consistency models, supervisor trees, mailboxes, and direct dispatch. Examples: a Kealu Vector workflow where a supervisor dispatches capability agents that share a workspace, a LangGraph graph where nodes share state, a CrewAI crew operating over shared memory. The classical analog is POSIX threads or an actor system with a shared store. Other usage: some authors use "swarm" with stronger emergent-behavior connotations (decentralized populations, biological inspiration); in this glossary we use it specifically for shared-memory cooperating agents under one trust domain. When precision is needed, shared-memory swarm is unambiguous.
Intra-domain agents. Agents inside one trust domain that communicate only by messages — typically because they run on separate machines, are written by different teams, or are deployed on different infrastructure. Trust is high, but state is not shared. This is the common microservices case: agents inside one company talking over HTTP, A2A, or other message-passing protocols. The available coordination primitives are RPC, sagas, idempotency, and rate limiting; the supervisor-tree pattern still works because the trust to restart a peer&039;s process is available. Other usage: "internal agent mesh," "trusted service mesh" (though that imports Istio/Linkerd connotations).
Cross-domain agents. Agents in different trust domains that communicate only by messages — a bank&039;s agent calling another bank&039;s, an MCP server in one company invoked from an agent in another. Memory is not shared because mutual distrust precludes it. Coordination primitives include sagas, idempotency tokens, capability advertisement, reputation, and federation protocols. Crucially, capability substitutability fails across this boundary: two agents may advertise the same capability and produce semantically different, irreversible results (the "Chase vs. Citi" pathology). Other usage: "federated agents," "agent federation," "Internet of Agents," "agentic web." The latter two belong to particular research programs (NANDA, Trust Fabric) and import their framing.
The fourth combination — different trust with shared memory — is essentially nonexistent in practice; sharing memory across trust boundaries is what mutual distrust forbids.
Most production agent systems combine all three regimes. An externally-visible cross-domain agent is often internally implemented as a swarm, some of whose sub-agents reach out to intra-domain services within the same organization. The three regimes are coordination tools, not types of systems.
Note on the framing: this 2×2 is not standard in the current literature, which tends to collapse the trust axis and the memory axis into a single "kind of agent." We separate them because they constrain different things — trust constrains what is possible (you cannot share memory across distrustful boundaries), while memory sharing is an architectural choice within what trust permits.
Tool call. A single invocation of a tool by an agent. Typed: has a name, an input, and a return value or error.
Agent-to-agent call. An invocation of one agent by another. Distinguished from a tool call when the callee is itself a stateful agent program rather than a stateless function. Other usage: "delegation," "sub-agent invocation," "agent message."
Capability. A description, typically structured, of what an agent can do — used for discovery and routing. A capability may be advertised as a binary declaration ("this agent handles code review") or, in emerging systems, as a continuous measure of proficiency ("this agent handles code review at quality level 0.87"). The binary form is standard today; the continuous form is a research frontier with implications for routing and fault tolerance — if you know how well an agent handles a domain, you can make finer-grained routing decisions and identify fallback agents when one becomes unavailable. Other usage: "skill" (in some 1990s MAS literature; not the same as the skill defined above), "service description," "agent card" (A2A&039;s term). The classical analog is service advertisement in service-oriented architectures.
Protocol. A specification governing how agents (or agents and tools) communicate. The current protocol layer includes:
MCP (Model Context Protocol). Anthropic, November 2024. Standardizes model-to-tool integration — how a model discovers, invokes, and receives results from tools. Addresses the N×M data integration problem: without MCP, every agent framework must integrate with every tool independently. Donated to Linux Foundation (AAIF), December 2025.
A2A (Agent2Agent). Google, April 2025. Agent-to-agent communication across frameworks and organizations. Treats agents as opaque — they collaborate without revealing internal logic. Introduces agent cards for capability advertisement. Now at the Linux Foundation.
ACP (Agent Communication Protocol). IBM BeeAI, March 2025. REST-native, edge-friendly alternative to A2A&039;s JSON-RPC. Merged into A2A, August 2025.
ANP (Agent Network Protocol). Community, 2024. Uses W3C DIDs and JSON-LD graphs for decentralized agent discovery and collaboration.
The space is in active flux as of 2026. A persistent gap across all current protocols: capability negotiation — determining what an agent is actually able to do, and how well — remains unsolved.
Federation. A set of agents operating under different trust domains that interoperate through shared protocols. The natural structure of a cross-domain system. Other usage: "agent mesh," "agent network," "Internet of Agents."
Trust domain. The set of agents and infrastructure operating under one administrative authority, typically one organization. The natural unit at which memory and tools can be shared and within which sub-agents can be freely spawned and supervised. (Whether they are shared is a separate architectural choice — see swarm vs. intra-domain.) Other usage: "organization boundary," "administrative domain." The classical analog is the autonomous system in BGP.
Tool failure. A tool returns an error, times out, or returns a syntactically valid but semantically wrong result. Distinguished by severity (transient vs. permanent) and visibility (whether the agent can tell something went wrong).
Coordination failure. A multi-agent system reaches a state where individual agents are functioning, but their collective behavior is incorrect — deadlock, livelock, oscillation, or collapse to a degenerate fixed point. Other usage: the MAST taxonomy (Cemri et al., 2025) breaks this into specification, inter-agent misalignment, and verification sub-categories.
Competence failure. A failure mode specific to agent systems: an agent is alive, responsive, and producing syntactically valid output, but the output quality has degraded — due to model overload, context pollution, provider degradation, or task-competence mismatch. Distinguished from tool failure (the tool itself is broken) and coordination failure (the collective behavior is broken): in a competence failure, the individual agent appears healthy by all liveness metrics but is producing degraded results. Detection requires output quality monitoring, not just health checks. The classical analog is a Byzantine fault, but softer — the agent is not malicious, just degraded. Other usage: "soft failure," "quality degradation," "silent failure."
Hallucination. The model produces output that is fluent and confident, but factually wrong or unsupported. From a systems perspective: a Byzantine-flavored fault that the producing agent does not detect.
Recursive delegation. A pattern where an agent delegates to a sub-agent, which delegates further, potentially without termination. A failure mode when not depth-bounded. Other usage: "agent recursion," "delegation loop."
Supervisor restart. A recovery pattern where a supervisor detects sub-agent failure and respawns the sub-agent from a clean state, optionally with the failed task. From Erlang/OTP. Variants: one-for-one (restart only the failed sub-agent), one-for-all (restart all peers), rest-for-one (restart the failed sub-agent and those started after it).
Saga. A pattern where a multi-step operation across boundaries is structured as a sequence of reversible steps, each with a compensating action that can be invoked if a later step fails. From Garcia-Molina & Salem (1987). The right primitive when shared state is not available — that is, in intra-domain and cross-domain settings.
Prompt injection. An attack in which an attacker introduces instructions into the model&039;s context that cause it to deviate from its intended behavior. Direct prompt injection is from a user input field; indirect prompt injection is from data the agent reads (web pages, documents, tool outputs).
Jailbreaking. An attack in which the attacker causes an agent (or the underlying model) to operate outside the security or behavioral boundaries set for it. In the agent-specific case, jailbreaking means escaping the security boundaries set for a specific agent by manipulating its environment. Classical model jailbreaks bypass safety training through crafted prompts (role-play, encoding, instruction reframing); agent jailbreaks exploit the broader attack surface — manipulating tool outputs, retrieved documents, file contents, or web pages the agent reads — to push the agent outside its intended scope. Distinguished from prompt injection: prompt injection names the mechanism (injecting instructions into the context); jailbreaking names the goal (escaping boundaries). A prompt injection may be the vehicle for a jailbreak, but not every prompt injection is a jailbreak (some merely redirect to another task), and not every jailbreak uses prompt injection (some exploit model behavior directly through user input). The classical analog is privilege escalation or sandbox escape. Other usage: "model jailbreak," "agent jailbreak," "boundary escape."
Confused deputy. The classical security pattern where an agent with delegated authority is tricked into using that authority on behalf of an attacker. Prompt injection is, structurally, a confused-deputy attack on an LLM agent. (Greshake et al. 2023 makes this connection explicit.)
Agent supply-chain attack. An attack where a component the agent relies on — a tool, a sub-agent, a model provider — is itself compromised or malicious.
Guardrails. Mechanisms that constrain an agent&039;s behavior to keep it within intended operational and safety boundaries. The term is broad and covers a range of techniques: input filters (blocking certain user inputs from reaching the model), output filters (blocking or modifying the model&039;s outputs), policy classifiers (separate models that judge whether an action is acceptable), tool-level restrictions (capability gating, allow-lists for tools and arguments), workspace sandboxing (limiting what the agent can read or write), and human-in-the-loop checkpoints. Other usage: "safety filters," "policy enforcement," "agent controls," "safeguards." Guardrails are the defensive counterpart to the adversarial vocabulary in this section — jailbreaks and prompt injections succeed when guardrails fail. The term is sometimes critiqued as imprecise, since "guardrails" gets applied both to hard technical constraints (a sandbox the agent cannot escape) and soft behavioral nudges (a system prompt asking the model to behave). When precision matters, name the specific mechanism rather than calling it a guardrail.
This glossary represents a working consensus, not a settled standard. As of 2026:
Terms with the widest adoption: model, agent, tool, context, ReAct, RAG, HITL, MCP, A2A, hallucination, prompt injection, jailbreaking, guardrails. Recently stabilized but rapidly: harness, workspace, skill.
Terms in active flux: agentic AI (split between the OECD&039;s precise multi-agent-coordination sense and looser marketing usage), agent runtime vs. framework, memory (sub-categories not standardized), swarm (used inconsistently across the literature), guardrails (widely adopted but imprecisely scoped, see entry), the entire protocol stack, capability (the agent-design sense overlaps confusingly with the security sense).
Terms specific to this glossary&039;s framing: the swarm / intra-domain / cross-domain trichotomy is our 2×2 reading of the field&039;s coordination regimes; it is not a standard taxonomy. Capability agent is in production use at Anthropic, Kealu, and elsewhere, but is not yet a settled term across the field. Competence failure (see Failure and recovery) names a failure mode widely observed but not yet standardized. Session (see Actors) is used informally everywhere but rarely defined precisely; our definition follows the process/program analogy.
For policy-side framing of this conceptual territory, see OECD AI Papers No. 56, The agentic AI landscape and its conceptual foundations (2026), which synthesizes definitions across vendor and academic sources from a governance perspective. The OECD document operates at a higher level of abstraction than this glossary (it does not engage with serving infrastructure, harness design, or coordination primitives), but it is the natural reference for readers whose work crosses into AI policy or regulation.
If you adopt this vocabulary, we&039;d suggest citing it as the “Kealu agent terminology (Bustamante & Birrer, 2026 working version)” and noting where you depart from it. The goal is shared vocabulary, not vocabulary monoculture.
Contributors: Fabián E. Bustamante (Professor of Computer Science, Northwestern University; Chief Scientist and Co-founder, Kealu, Inc.), with terminology contributions and corrections from Stefan Birrer (CTO and Co-founder, Kealu, Inc.), May 2026.