Mission exposes Agent executions as controlled daemon Entities while many agents still run inside terminal-backed CLI applications. Raw terminal input remains available for native CLI interaction, but it is not the canonical channel for Mission-controlled operator intent or Agent execution journal changes.

Agent execution transport identity is daemon-issued and token-bound. The daemon registers an Agent execution with an opaque session token, and the agent process uses that token to communicate instead of passing taskId, agentExecutionId, or similar routing identity through environment variables. See ADR 0004.04 for the transport split.

Agent execution messages are structured non-terminal messages sent through the daemon. The base Agent adapter defines common Agent execution messages, and each Agent adapter may advertise additional supported messages through the live AgentExecution message registry. Surfaces must derive available structured controls from the current AgentExecution data, where the execution exposes its currently available command and message descriptors directly as first-class properties derived from the stable AgentExecutionContract plus current execution state.

Supported structured messages are advertised as Agent execution message descriptors, not as broad boolean capabilities or UI methods. A descriptor names the message type, label, input shape, delivery behavior, and whether it appends to or mutates Agent execution journal state. Delivery behavior is best-effort because Agent executions are indeterministic and may ignore, misunderstand, or fail to structurally acknowledge messages. This lets the daemon validate messages and lets surfaces render controls without knowing child-runtime implementation details.

Daemon-accepted Agent execution messages may append to or mutate the Agent execution journal before optional delivery to the Agent adapter. The journal mutation is canonical when accepted by the daemon, regardless of whether runtime delivery succeeds or receives a useful response. Operator-facing syntax such as slash commands is shorthand only: for example, /read @PRD.md should be parsed by Mission into a structured journal mutation against an Artifact Entity reference, not treated as a canonical message type or raw terminal text whose effect is inferred later. The daemon owns shorthand parsing and validation because it owns Entity identity, permissions, runtime message descriptors, journal mutation, delivery attempts, and audit records; surfaces may provide autocomplete or previews but do not define canonical parse results.

Mission must distinguish daemon-accepted journal mutation, runtime delivery attempt, runtime output observation, and operator/system interpretation of that output. Command and message payloads stay payload-only; eventId is daemon-owned audit metadata rather than part of the caller payload. Agent adapter responses are observations in the Agent execution log unless a future daemon-validated state model explicitly promotes them.

This preserves the terminal as the live CLI surface while keeping Mission authoritative over journal state, auditability, permissions, and structured operator commands.

External agent prompt fields always submit Agent execution messages, including plain text operator prompts. Raw terminal input is reserved for direct interaction inside the terminal pane.

Agent execution messages are not first-class durable Entities for now. Accepted messages are recorded as semantic records in the Agent execution journal. Runtime delivery remains best effort and is recorded separately from daemon acceptance. Raw terminal recordings are daemon-owned audit material, not Mission artifacts by default. Curated material derived from an AgentExecution log becomes an Agent-session artifact only through explicit daemon or operator promotion. A separate queryable message Entity can be introduced later if independent message lifecycle, addressing, permissions, or search requirements appear.