Agent Execution And Agent Adapter Vocabulary

Mission uses Agent, AgentAdapter, AgentExecution, and Terminal as distinct canonical execution concepts. AgentExecution is the authoritative in-memory Entity instance for a running or recoverable Agent execution process.

An Agent is the registered Mission capability that can perform work, such as Copilot CLI, Claude Code, Codex, Pi, or OpenCode. Agent is an Entity. Agent owns its identity, display name, configuration, availability policy, and exactly one AgentAdapter. AgentSchema owns the shared Agent payload and Agent id vocabulary. AgentRegistry is the first-class catalogue of available Agents. There is no separate AgentAdapter registry, catalog, or set: resolving an Agent through the AgentRegistry is the only domain lookup needed before execution.

An AgentAdapter is the provider or tool translation object owned by one Agent. It is not an Entity, is not independently registered, and is a stateless seam. The adapter validates adapter-specific metadata, translates AgentExecution launch intent into provider-specific command, args, env, initial input delivery, and optional MCP provisioning, parses provider-structured output when available, and describes adapter-scoped Agent execution messages. AgentAdapter does not own live execution state, runtime maps, process handles, AgentExecution lifecycle truth, TerminalRegistry, daemon-side message intake policy, Mission state transitions, or AgentExecution mutation.

AgentExecution is one concrete in-memory Entity instance for one execution of one Agent under an explicit owner reference. AgentExecution replaces the previous AgentSession concept as canonical vocabulary. AgentExecution owns execution identity, owner reference, journal state, AgentExecutionProcess lifecycle, launch-time process state, structured message handling, message intake, daemon-internal observation handling, message registry publication, progress, optional terminal transport attachment, log references, and audit-facing execution state. AgentExecution storage persists the selected Agent as agentId only, with agentId modeled as a direct reference to the Agent Entity. The hydrated AgentExecution Entity data may include the related current Agent catalogue data through the OGM hydration pattern. That hydration is generic: when the hydrated schema models a related Entity field with AgentSchema, the Entity factory and model catalogue materialize the field as Agent Entity data shape rather than Agent storage shape. Launch-time immutable Agent details belong in separate AgentExecution-owned audit fields only when they are needed for reproducibility or durable execution explanation. AgentExecution may use private collaborators for process IO, terminal transport, adapter translation, MCP provisioning, journal writing, or observation policy; those collaborators support AgentExecution lifecycle ownership. AgentExecution-local process concepts use AgentExecutionProcess vocabulary. Daemon runtime remains the process supervision layer outside the Entity.

Hydrated AgentExecution data is serializable Entity data. AgentExecution does not require a materialized agent: Agent property unless its behavior needs Agent Entity methods; hydrated data.agent is enough for current Agent catalogue metadata. AgentExecution runtime behavior does need the selected AgentAdapter. The AgentExecution instance may therefore expose a non-serialized agentAdapter runtime capability property instantiated from the selected Agent by Entity behavior or daemon runtime composition. The adapter instance is never persisted, never a field on AgentExecutionSchema, and never database-hydrated Entity data. AgentExecution may exist in a read-only hydrated state without agentAdapter; runtime methods that require provider translation must require the attached adapter and fail loudly when it is missing.

AgentExecution owns the Agent execution process. The process is the OS child process or process-like provider session started for the Agent execution, including command, args, working directory, process id when available, exit state, and process lifecycle operations. Terminal support is optional transport for that process.

Process launch, prompt preparation, command delivery, cancellation, termination, message routing, process ownership, and AgentExecution state mutation belong to AgentExecution. Small helpers are named for the mechanical capability they provide, such as process launch or terminal attachment, and stay behind AgentExecution.

AgentAdapter methods must be pure translation or parsing seams over explicit inputs. The implementation must not keep executionsById, process handles, lifecycle flags, or any other live execution-owned mutable state on the adapter.

The live AgentExecution instance is the process and state owner for one execution while that execution is active or recoverable. Instantiating the Entity is sufficient to make it the active in-memory authority for that execution. If a future lookup table or process-handle map becomes necessary, it remains private daemon implementation detail rather than canonical execution vocabulary. AgentExecution lifecycle, process, interaction, and state use the Entity’s type family.

AgentExecution is owned by an owning Entity through an explicit owner reference. Repository, Mission, Task, Artifact, and System owners address the same AgentExecution Entity contract for prompt, command, cancellation, completion, terminal behavior, execution state, and interaction. A Mission may keep workflow references to the AgentExecution ids that participate in Mission workflow state. The single AgentExecution Entity data contract remains the shape exposed for execution state and interaction.

AgentExecution owner reference is the daemon-owned statement of which Entity owns the execution. Supported owner kinds are system, repository, mission, task, and artifact. The owner reference carries ownerEntity plus ownerId; task-owned executions participate in workflow request and event handling, mission-owned executions support Mission-level work without selecting a task, repository-owned executions support repository operations outside a specific Mission, system-owned executions support daemon/system maintenance, and artifact-owned executions support focused work on one artifact and may optionally reference the repository, Mission, or task that owns that artifact.

AgentExecution interaction and optional terminal transport are addressed by canonical AgentExecution id. ownerEntity plus ownerId remain explicit owner reference fields in hydrated and persisted data, but they are not duplicate self-identity or alternate method locators.

AgentExecution launch location is separate from AgentExecution identity. AgentExecutionInputSchema or the method-specific launch input defines the process working directory used when AgentExecution starts the Agent process. For a repository-owned execution, the working directory must be the repository root. For a Mission or task execution, the working directory may be the Mission worktree or another explicitly selected path owned by that launch request. Terminal snapshot and input queries must not infer launch location from owner reference fields.

AgentExecution communication schemas are provider-neutral Zod schemas for controlling, observing, and messaging an AgentExecution. First-class AgentExecution schemas belong in AgentExecutionSchema.ts, and the inferred TypeScript type name is obtained by replacing the final Schema suffix with Type. Lifecycle orchestration belongs to the AgentExecution Entity instance. AgentExecution, AgentExecutionProcess, and AgentAdapter cover the execution vocabulary.

TerminalRegistry is the Terminal Entity boundary owner of live Terminal objects. It is application-level and must not be bound to Mission as its root owner. A Terminal is one PTY-backed terminal transport with screen state, input, resize, exit observation, and snapshot/update behavior. Terminal may be attached to an AgentExecution, Mission, task, repository, or system-level operation through explicit owner metadata. Terminal modules provide terminal screen substrate behavior only; they do not own AgentExecution process lifecycle.

TerminalSession is not canonical Mission vocabulary. Terminal-related contracts must use TerminalHandle, TerminalSnapshot, TerminalUpdate, TerminalOwner, terminalId, or terminalName as appropriate. TerminalRuntime may exist only as a backend abstraction for terminal implementations such as NodePtyTerminalRuntime; it is not the same concept as Terminal.

The clean ownership graph is:

AgentRegistry
  -> Agent
      -> AgentAdapter

AgentExecution
  -> Agent
  -> AgentAdapter
  -> AgentExecution process
  -> owner reference
  -> optional Terminal transport

TerminalRegistry
  -> Terminal

The canonical execution vocabulary is Agent, AgentAdapter, AgentExecution, AgentExecutionProcess, and Terminal. Implementation classes align with those concepts or with small private capabilities behind them.

New execution vocabulary is frozen unless it is first anchored in CONTEXT.md or an accepted ADR. The implementation and docs must not invent fresh top-level AgentExecution terms, layers, or owner names without explicit consent and an accepted documentation anchor. If an existing canonical term is insufficient, the gap must be resolved in doctrine first and only then in code.

This decision requires clean-sheet convergence. The implementation uses one vocabulary per concept and one bounded change for vocabulary replacement. Persisted Mission runtime data changes are handled by an explicit runtime migration decision or by updating disposable mission state directly.

Owning Entities may create AgentExecution instances for their ownership boundary and may evaluate accepted observations that target their owned execution. They must not wrap AgentExecution prompt, command, cancellation, completion, or terminal behavior in owner-specific command vocabularies. After launch, operator follow-up input is addressed to AgentExecution through the AgentExecution Entity contract or through an explicitly documented non-command transport such as Terminal input, using canonical AgentExecution id.