Agent Execution Structured Interaction Vocabulary

Agent execution structured interaction is an Entity-addressed conversation between an AgentExecution instance and the Entity that owns it.

This decision exists because the current implementation has useful pieces but overloaded terms: Agent execution messages, Agent commands, message registries, daemon-normalized observations, workflow events, and Entity events all appear near the same execution path. Future implementation needs one precise vocabulary for the ways an AgentExecution instance can receive instructions, accept structured process output, and cause daemon-owned Entity behavior.

This vocabulary is closed unless explicitly extended through CONTEXT.md or an accepted ADR. The codebase, docs, and implementation notes must not invent new top-level AgentExecution interaction terms without explicit consent and a doctrine anchor. When a term is missing or ambiguous, the work must stop at the vocabulary boundary and resolve that term in doctrine before introducing it into code or documentation.

Vocabulary

An Entity command is an authoritative caller-to-Entity mutation request. It enters through entity.command, is validated by the target Entity contract, and is handled by the target Entity class or its aggregate delegate. Entity commands are the canonical operator and daemon mutation surface. A command is not the same thing as an AgentExecution message.

An Entity event is a daemon-emitted fact that an Entity publishes after accepted behavior or observed runtime state changes. Entity events cross daemon-client boundaries through Entity contracts and event envelopes.

An Agent execution message is the structured interaction unit that crosses the AgentExecution runtime boundary. It can be incoming to AgentExecution from an operator or daemon path, or outgoing from the running Agent/process toward daemon intake. Messages carry typed payloads and may later normalize into observations, journal records, decisions, and projections. A message is not the same thing as an Entity command, even when a command causes one to be accepted or delivered.

An Agent execution turn is one accepted and delivered turn-starting outgoing Agent execution message. Launch prompts, follow-up prompts, and turn-starting Agent execution messages such as resume, checkpoint, or nudge each begin a new turn. A turn begins from daemon-owned acceptance and delivery records, not from Agent-authored acknowledgement text.

An Agent execution message descriptor describes one incoming or outgoing Agent execution message kind that is available for a specific execution. It stays lean: direction, kind, payload shape or schema key, and delivery modes are required. Human label, short description, and whether the message starts a turn are optional when they materially improve live UX. Per-entry state such as transport health, attention, disabled reasons, or other execution-wide conditions does not belong inside each message descriptor.

An incoming Agent execution message is structured data emitted by the Agent process or provider side toward AgentExecution and then evaluated through the owning Entity path after daemon normalization. It may arrive through MCP, stdout markers, provider-structured output, or another transport. Stdout marker prefixes are derived from the owning Entity, such as @task::, @mission::, @repository::, or @artifact::, followed by strict JSON on the same line.

An Agent execution observation is a daemon-internal normalized representation of something observed from the Agent execution process, such as an incoming Agent execution message, provider-structured output, terminal output heuristic, or daemon-authored intake record. Observations are internal to daemon/AgentExecution processing: they carry normalized routing and evaluation data before policy affects AgentExecution state, owner Entity state, or published Entity events. Observation is not intended as a public runtime-boundary term; message remains the canonical public term.

Entity commands and AgentExecution messages are separate layers that must remain explicit in the model. Commands are the contract-level calls made against the Entity. Messages are the runtime-boundary interaction units handled by or emitted from the execution. Some commands validate and then cause message acceptance or delivery, such as sending a prompt, resume, or replying to needs_input. Other commands may only change local lifecycle or projection state and never emit a runtime-boundary message. Observations are a third, daemon-internal normalization layer after message intake, not a public peer to commands or messages.

An AgentExecution decision is the durable result of policy evaluation for a message or observation. It may reject input, record it without state effects, emit an AgentExecution event, update AgentExecution state, or route an owner effect. Decisions are recorded before their effects are applied so replay and audit can explain why state changed.

An AgentExecution log is append-only audit material for one AgentExecution. It records accepted AgentExecution messages, observations, decisions, state effects, owner effects, and projection material. It is owned by the AgentExecution instance and is separate from terminal recordings and Mission workflow event logs. It is not a separate Entity and not the owner of AgentExecution behavior.

An Agent execution timeline is the first-class projection surface for the Open Mission agent-chat interface and other human-facing review surfaces. It is derived from accepted messages, observations, decisions, state changes, and journal replay. It is not the source of truth for execution behavior, but it must preserve the full set of human-meaningful interaction possibilities needed to reconstruct and present the execution conversation and work narrative.

An Agent execution claim is an accepted observation where the Agent declares readiness, completion, failure, or another state assertion that requires Mission or operator verification. A claim may publish an Entity event or update AgentExecution audit state. Mission task completion follows the owning Entity’s workflow rules.

An Agent execution permission request is an accepted runtime or provider approval request that asks whether a capability use may proceed, such as a tool call, filesystem mutation, command execution, or other guarded action. It is distinct from needs_input: permission requests are about approval policy, while needs_input is about collaboration input needed to continue the work.

An Agent execution message registry is the current structured interaction catalog for one Agent execution. It contains only the incoming and outgoing message entries that are currently available for the execution’s owner Entity, selected Agent, current interaction mode, and Agent adapter.

An Agent execution transport state is the minimal current-state summary of whether the selected structured transport is usable for this execution. It exists to explain operator-visible communication health such as attached, degraded, unavailable, or recovering. It is not the place for backend choice, lease internals, protocol-version debugging, or other daemon-private reconciliation details unless a future ADR explicitly promotes those details onto a separate monitoring surface.

Source Of Truth

The source of truth for supported structured Agent execution interaction at runtime is the Agent execution message registry owned by the AgentExecution instance. The registry is derived from the AgentExecution Entity, the selected Agent adapter, the current interaction mode, and the owning Entity referenced by ownerEntity plus ownerId.

The stable universe of possible message kinds does not belong on the live execution registry. That broader universe belongs to the stable AgentExecutionContract and related schema definitions. The hydrated messageRegistry exists for real-time consumers such as the agent-chat UI, composer surfaces, and daemon delivery logic that need to know what is currently available now.

MCP is not a responsibility owned by AgentExecution. Base MCP capability is derived from the selected Agent through the Agent registry and adapter, while effective MCP availability for a specific execution is derived from that base capability plus daemon policy, launch/runtime conditions, and current degraded state. AgentExecution may reflect that effective availability, but it does not own MCP authority, bridge lifecycle, or tool catalog law.

The source of truth while an AgentExecution is active is the AgentExecution instance. AgentExecution logs defined by ADR-0006.08 record what was accepted, observed, decided, and applied so the instance can be audited, projected, and recovered without making the log a separate domain owner.

The registry covers both directions of Agent execution messages:

Incoming message descriptors: the owner-addressed message kinds that the daemon may accept from the Agent/process side for this execution.
Outgoing message descriptors: the structured messages that an operator or daemon module may send toward the execution.

Prompt-scoped instructions are rendered from this registry. The registry is the source of truth for supported message payloads, and rendered prompt text is a delivery view of that registry. Marker JSON carries only the Agent execution id, event id, version, and message payload; owner context comes from ownerEntity, ownerId, and the message registry.

The current AgentExecutionMessageDescriptor concept should cover both incoming and outgoing runtime-boundary messages so launch instructions, parser rules, policy, and surface documentation share one vocabulary. The registry should not duplicate unavailable-but-known message kinds by default. If advanced tooling later needs static introspection, that should be exposed through a separate surface rather than by bloating the live registry. The live descriptor shape should remain lean rather than turning into a second projection surface for execution state.

Effective MCP-backed semantic-operation availability should be visible in two ways at once: explicitly as a simple first-class top-level current-state field with values available | unavailable, and indirectly through the currently available semantic operation descriptors plus degraded behavior when those operations are unavailable. The first rebuild does not need a richer MCP status object with detailed reason taxonomy on AgentExecution.

Current-State Model

The top-level current-state model for AgentExecution should stay compact and explicit. The rebuild should group current execution truth into these buckets:

Identity and ownership: canonical Entity identity, ownerEntity, ownerId, agentExecutionId, and retry lineage.
Launch intent and governed process: selected Agent, durable launch intent, launch locator, and the current governed process/session truth.
Current interaction state: lifecycle, attention, activity, current input request, pending permission request, awaiting-response linkage, and other facts that answer what is true now for collaboration.
Current message and command availability: currently available Entity commands and the live messageRegistry for currently available incoming and outgoing messages.
Current transport and capability state: minimal transportState, current MCP availability, and other current capability facts that affect what the execution can do now.
Timeline projection: the first-class human-facing conversation and activity projection used by agent-chat and review surfaces.
Journal linkage and audit references: the durable journal identity and other audit/recording references needed to replay and inspect the execution.
Terminal linkage when present: terminal handle and terminal-specific linkage when the execution currently has a PTY-backed lane. Terminal state itself remains Terminal-owned.

These are current-state buckets, not a rule that every field must live at the top level forever. The purpose is to keep the rebuild aligned on the major kinds of truth AgentExecution owns, while leaving detailed schema shaping to the Entity, schema, and storage design work.

Launch intent and governed process truth must remain distinct. Durable launch intent records what the owner or daemon intended to launch, including the owner-approved launch locator and other replayable pre-launch choices. Governed process truth records what was actually realized at runtime, such as the concrete working directory, current transport attachment, provider/session identity, and other current process facts. Realized process facts must not overwrite durable launch intent, because replay, audit, and retry lineage depend on preserving both.

Ownership

The public architecture is owner-Entity resolution:

owner reference
  -> owning Entity
      -> Entity contract methods
      -> Entity contract events

For task-owned executions, the immediate owning Entity is the Task, while the Running Mission aggregate remains the delegate for workflow state changes. For mission-owned executions, the owning Entity is Mission. For repository-owned executions, the owning Entity is Repository. For artifact-owned executions, the owning Entity is Artifact, with optional Mission or Task adjacency carried by separate fields when present. Artifact ownership does not collapse into Task ownership when taskId is present.

AgentExecution owns launch, process lifecycle, terminal attachment decisions, provider output intake, and daemon-internal observation routing for its own execution. AgentExecutionRegistry is only the daemon-internal lookup and process-handle boundary for active AgentExecution Entity instances. Owner meaning belongs to the owning Entity referenced by ownerEntity plus ownerId. When a normalized observation can affect owner behavior, AgentExecution routes or delegates that internal observation to the owning Entity path and applies the accepted result from that Entity path. TerminalRegistry and terminal lifecycle management remain daemon/Terminal concerns rather than AgentExecution concerns.

AgentExecution construction is side-effect free. AgentExecution.start() is the owning launch method, and it realizes explicit pre-launch intent already stored durably on the execution, such as selected Agent, launch mode, an owner-resolved launch locator, optional owner-composed initialPrompt, requested terminal mode, and requested MCP provisioning. The launch locator is not a second global kind taxonomy; ownerEntity remains the only kind discriminator, and each owner path supplies its own launch-locator shape behind a common boundary. That owner-approved launch locator remains durable on AgentExecution for replay, audit, and reattachment semantics; daemon/runtime resolves it into a concrete sandbox path before spawn. The exact initialPrompt is stored as launch intent because it is essential when launch includes initial text, and the same content is also journaled as the first accepted outbound message when delivery is accepted. initialPrompt is optional so an execution may launch into a waiting state without sending text immediately. Actual spawn work is delegated to daemon/runtime launch capabilities. AgentExecution remains the lifecycle owner of the resulting process, while daemon runtime supervision owns lease tracking and cleanup fan-out. The realized process facts, such as the concrete working directory or realized transport details, are current process truth and must remain distinct from the durable launch-intent record that led to them.

attach, resume, and retry are distinct canonical concepts. attach reconnects a surface to an existing AgentExecution and is never a turn. resume is a turn-starting Agent execution message sent to an existing execution when the selected Agent/adapter supports continuation by reference. retry creates a new AgentExecution with a new identity, optionally carrying lineage such as retryOfAgentExecutionId. Owner-side convenience policies like “attach or create” or “attach only” belong to owner orchestration or daemon lookup commands, not to the semantic state model of a single AgentExecution.

Owning Entities may expose commands that start, ensure, or select an AgentExecution for their ownership boundary. Those commands return an AgentExecution reference or schema-validated AgentExecution data, but the ongoing structured interaction remains AgentExecution-addressed. Repository management, Mission work, Task work, and Artifact work must not each invent duplicate sendPrompt, sendRuntimeMessage, cancel, or complete owner commands for their child executions.

The implementation must not add owner-specific AgentExecution classes such as RepositoryAgentExecution, MissionAgentExecution, TaskAgentExecution, or ArtifactAgentExecution. Owner reference is data on AgentExecution, not a reason to create another execution model. Owner Entities may store workflow references to AgentExecution ids when their own state needs to remember participation, but the executable interaction state remains the single AgentExecution Entity state.

Mapping Rules

The structured runtime path is:

Agent process structured output
  -> owner-addressed message parser
  -> incoming Agent execution message
  -> Agent execution observation
  -> AgentExecution instance
  -> owning Entity policy/method
  -> AgentExecution state change, owner effect, Entity event, workflow event, or rejection

The structured delivery path for daemon-to-AgentExecution turns is:

Agent execution message accepted by the daemon
  -> delivery attempted
  -> delivery recorded
  -> AgentExecution semantic activity set to awaiting-agent-response
  -> later Agent observation clears or refines the turn state

When an operator or daemon module wants to affect an AgentExecution, it does so by calling an Entity command on AgentExecution. That command may acknowledge locally, reject locally, or accept and materialize one or more AgentExecution messages. The command layer and message layer must not be collapsed into one vocabulary, because command availability and message availability answer different questions.

All semantic outgoing messages must enter through this single AgentExecution-owned delivery path before any transport-specific handling. All accepted inbound structured material must enter through a single AgentExecution-owned daemon-normalization path before any state mutation, owner effect, or publication occurs. MCP tool calls, stdout markers, provider events, and other structured transports must normalize into that one intake path.

When AgentExecution runs inside a sandbox, sandboxing changes transport mechanics but does not create a second interaction model. Stdout marker parsing remains valid through the sandbox boundary. The canonical MCP mode for sandboxed execution is a daemon-external bridge: the daemon-owned MCP authority remains outside the sandbox, and the sandboxed process reaches it through an execution-scoped, policy-controlled bridge. If that bridge is unavailable for a given execution mode, stdout-only structured observation remains a valid degraded mode.

Sandboxing is part of the intended runtime direction, but it is not a mandatory gate for the first clean-sheet rebuild slice. The rebuild must stay sandbox-ready by preserving sandbox-compatible launch intent, transport normalization, and capability/degraded-mode semantics, while the earliest implementation may still run unsandboxed if that is the fastest path to recovering the canonical AgentExecution model.

Launch substrate choice remains a daemon/runtime concern, not an AgentExecution concern. AgentExecution may reflect effective capabilities and degraded behavior, but it must not expose user-facing data that reveals whether the daemon used sandboxed or unsandboxed launch. If later system-monitoring surfaces need substrate detail, that belongs to daemon/system monitoring models rather than to the canonical AgentExecution user surface.

transportState stays minimal and user-behavior-facing. It answers whether structured interaction is currently healthy enough to use and whether the surface should expect degraded behavior or temporary recovery. It must not become a general dump of reconciliation internals, lease state, backend mechanics, or protocol-debug metadata.

Surface attachment is not a turn. Attaching Open Mission or another surface to an existing AgentExecution only resolves transport and live state. If a surface-triggered action also starts work, it must do so by sending an explicit resume or other Agent execution message that begins a new turn and therefore enters awaiting-agent-response through the same daemon-owned delivery path as any other turn.

Interactive execution may imply a PTY-backed terminal attachment when the selected launch mode requires it. Even in that case, terminal specifics remain Terminal-owned. AgentExecution keeps only the linkage and the minimal execution-facing facts needed to expose the separate terminal lane correctly, such as whether terminal input is available and how to address the attached terminal.

An incoming Agent execution message may produce an AgentExecution Entity event after policy acceptance. When an incoming message represents a request for owner action, daemon/AgentExecution logic evaluates its normalized internal observation form and the owning Entity decides the resulting domain behavior through its own methods, policies, and workflow delegate. Upstream propagation is semantic owner-effect propagation, not blind bubbling of every AgentExecution event to every ancestor. The Agent is not asked to echo Mission, Task, Artifact, Repository, or owner ids in the marker payload; the daemon attaches the active owner route and rejects markers whose agentExecutionId does not match the active execution.

AgentExecution lifecycle truth remains daemon-owned. completed_claim and failed_claim are claims that become lifecycle transitions through daemon-authoritative owner behavior. ready_for_verification is a claim that the owning Entity or operator may use to surface verification work.

Turn state is separate from lifecycle truth. When the daemon accepts and delivers an Agent execution turn, AgentExecution enters semantic activity awaiting-agent-response immediately and remains there until a meaningful Agent observation clears it, replaces it with another activity, or requests input. Surfaces must not wait for an incoming initializing message before showing that a turn is in flight.

needs_input is an incoming message observation that keeps AgentExecution lifecycle running, sets attention: awaiting-operator, attaches a current input-request id, and may publish an Entity event. Its message payload carries a required question and required choices array. Each choice is either kind: "fixed" with label and value, or kind: "manual" with label and optional placeholder for freeform operator input. The operator response is a dedicated typed AgentExecution message on the normal AgentExecution message path. It must include the current input-request id and either a fixed choice value or manual text.

Permission requests remain a separate first-class AgentExecution state rather than collapsing into needs_input. They also place the execution into operator attention, but they differ in source, policy, reply shape, and automation semantics. A clean-sheet implementation may apply owner or daemon policy such as auto-approve to permission requests without auto-answering needs_input. Auto-approval changes whether a permission request waits for an operator; it does not answer collaboration questions on the Agent’s behalf.

Rich execution happenings follow a three-surface default. They are recorded in the journal for audit and replay, reflected in current state when they change what is true now, and projected into the timeline when they matter to human-facing UX. They do not automatically become first-class public AgentExecution events. permission-requested follows this default: it stays journal + state + timeline rather than becoming a dedicated public Entity event.

progress can update AgentExecution activity or telemetry after policy evaluation. It should not be modeled as a semantic state transition unless it changes lifecycle, attention, activity, or current input request. blocked can update attention or owner-visible claim state. message can update audit-facing projection state. Any Mission workflow effect flows through an explicit owning Entity rule covered by tests.

Timeline projection law is explicit. Accepted observations may project into timeline items for progress, status, blocked state, needs-input prompts, permission requests, verification readiness, completion or failure claims, and agent-authored messages. Artifact-bearing progress or message observations must preserve those artifact references in the projected timeline items so the agent-chat interface can surface what the Agent read, edited, created, or otherwise touched.

Current attention on the timeline is sticky for unresolved operator requests. Once needs_input establishes the active input request, later status, progress, or other lower-priority projection updates must not clear or overwrite that current attention item until the request is answered, cancelled, or superseded by a stronger terminal condition such as completion, failure, or an explicit replacement input request.

AgentExecution status must separate lifecycle, attention, activity, and runtime capabilities. awaiting-input is collaboration attention and input-request state, not a lifecycle state. Clean-sheet implementations must reject old awaiting-input lifecycle values rather than preserve compatibility readers or aliases.

All accepted semantic messages and accepted observations must carry or normalize into daemon-level correlation/idempotency ids before policy effects. Duplicate detection happens before state mutation, owner effects, and subscriber publication.

Event Listener Discipline

Owning Entities may listen to AgentExecution events for executions they own. Those listeners are part of the owning Entity’s behavior. A listener may coordinate local reactions, such as refreshing command views or applying workflow events through the Running Mission aggregate.

Daemon-internal owner handling for normalized incoming-message observations remains internal by default. It is not exposed as a normal public Entity contract method unless a concrete client-facing need later justifies promoting a specific owner-handling path into the public contract.

Entity events publish accepted facts. Owning Entity methods and policies validate whether an observation is allowed and decide what state changes follow.

AgentExecution data.changed events always publish accepted execution-state changes. Owner Entities publish their own events only when explicit owner effects change their own state. Subscriber publication follows accepted writes; it does not bypass owner-effect discipline. Public AgentExecution events stay intentionally small; rich execution happenings normally surface through journal, current state, timeline, and data.changed rather than through additional named public events.

Consequences

Agent launch instructions are generated from Agent execution message registries.
AgentExecution exposes incoming and outgoing message descriptors in its protocol snapshot or data model.
AgentExecution records semantic interaction in AgentExecution logs, while Terminal persists raw PTY recordings and Mission workflow runtime persists orchestration events.
AgentExecution chat or timeline views are projections over AgentExecution state, logs, and live process state, not source-of-truth transcripts.
Timeline projection remains first-class because it is the basis of the Open Mission agent-chat interface. The rebuild must preserve the full range of human-facing interaction possibilities rather than collapsing timeline output to a minimal audit feed.
Artifact-bearing progress and message observations preserve artifact references in timeline projection so surfaces can show file and artifact activity inline.
An unresolved needs_input request remains the current timeline attention item until it is answered, cancelled, or superseded by a stronger terminal condition or explicit replacement request.
AgentExecution routes accepted daemon-normalized observations through owner-Entity resolution.
AgentExecution exposes current available command and message descriptors directly in hydrated Entity data as the currently realized subset of the stable AgentExecutionContract surface.
messageRegistry is real-time and available-only. The stable contract owns the broader universe of possible message kinds.
Each live message descriptor stays lean: direction, kind, payload schema, and delivery modes are core; richer execution state belongs elsewhere.
Command availability and message availability remain separate surfaces. Commands describe which Entity mutations are legal now; messages describe which runtime-boundary interactions are legal now.
MCP capability is not owned by AgentExecution, but effective MCP availability is reflected on AgentExecution current state as a simple first-class top-level field and also through the currently available semantic operation descriptors and degraded behavior.
transportState is intentionally minimal on the canonical AgentExecution surface. Deeper reconciliation or backend-debug detail belongs to daemon or monitoring surfaces, not to normal execution UX state.
AgentExecutionRegistry indexes active AgentExecution instances by AgentExecution id and owner-derived key. It must not duplicate AgentExecution lifecycle management, expose its own runtime data shape, or become an owner-specific session controller.
AgentExecution command, query, terminal snapshot, and terminal input locators use ownerId plus agentExecutionId. Hydrated and persisted AgentExecution data also carry ownerEntity as a closed enum over sanctioned owner kinds so owner meaning does not depend on string parsing.
AgentExecution launch requests carry an owner-resolved launch locator rather than an arbitrary raw workingDirectory. Repository-owned executions resolve within Repository-owned roots; Mission and Task executions resolve within Mission-owned worktrees or other owner-approved workspaces; Artifact-owned executions resolve within Artifact-approved work areas. The launch locator remains durable on AgentExecution; daemon/runtime turns that approved locator into the concrete process working directory before spawn. That realized working directory is current process truth, not a replacement for the original launch-intent record. Terminal interaction after launch addresses the execution by ownerId and agentExecutionId, not by recomputing a process location.
Launch failure still leaves behind a durable AgentExecution with journaled failure state and subscriber publication. Retry creates a new AgentExecution with a new agentExecutionId; it must not reuse the failed execution identity.
attach, resume, and retry are the only canonical recoverability terms on AgentExecution itself. Owner or daemon selection policies such as “attach only” or “attach or create” stay outside the AgentExecution state model.
Permission requests remain distinct from needs_input so UI policy can treat approvals differently from collaboration questions. Auto-approve may resolve permission requests automatically, but it must not auto-answer needs_input.
Raw terminal input remains a separate non-semantic transport lane. It is durably replayable as terminal recording, but it does not become semantic command truth unless later accepted through a structured Mission path.
Interactive execution can require terminal attachment, but terminal state and full terminal capability modeling remain Terminal-owned. AgentExecution keeps only terminal linkage and minimal execution-facing lane facts.
Sandboxed execution uses a daemon-external MCP bridge as the canonical MCP mode. MCP authority stays daemon-owned outside the sandbox, while stdout markers and provider output still normalize through the same observation intake path.
Stdout-only structured observation is an allowed degraded mode when MCP bridging is unavailable or intentionally disabled for a given execution capability set.
Sandboxing remains optional for the earliest rebuild implementation, provided the runtime and data model preserve the same canonical interaction paths and remain compatible with later sandbox adoption.
Launch substrate choice is daemon-private. AgentExecution user-facing data must not reveal sandboxed versus unsandboxed backend choice unless a later ADR explicitly adds a monitoring-only surface for that concern.
Duplicate semantic messages or observations are explicitly journaled as duplicate-handled records rather than silently dropped. Duplicate-handled records do not publish outward unless canonical current state changes.
Public AgentExecution events stay intentionally small. permission-requested remains journal + state + timeline, not a first-class public event.
Owner Entities may initiate Agent executions for their ownership boundary, but they do not persist full AgentExecution data inside their own Entity data schemas unless a separate ADR explicitly makes that Entity the durable owner of that child record. Runtime attachment is represented by AgentExecution owner reference and daemon runtime lookup, not by owner-specific session maps.
Artifact-owned executions remain Artifact-owned even when they carry missionId or taskId adjacency. Those adjacent ids inform routing and projection; they do not reassign immediate ownership.
Owner-specific AgentExecution wrapper classes and owner-specific execution record models are forbidden. They multiply layers for every future owner and obscure the single AgentExecution contract.
The incoming Agent message parser remains strict and deterministic. Domain acceptance happens in daemon/AgentExecution logic and then, when needed, in the owning Entity path.
The word command names Entity commands only. Commands may cause messages, but they are not themselves messages.
The word event names accepted daemon-published facts. Raw Agent stdout becomes an event only after daemon code accepts and publishes it as one.
The word message names the runtime-boundary interaction unit. Implementation terms like marker parsing or delivery mode may remain transport details, but signal is not canonical AgentExecution vocabulary.

Remaining Open Questions

Which accepted observations should publish first-class AgentExecution Entity events beyond data.changed and terminal updates` if a future exception to the small-event-surface rule is ever needed?