The Open Mission system persists AgentExecution semantic interaction in ordered AgentExecution journal entries that are separate from terminal recordings and Mission workflow event logs.

The AgentExecution instance is the canonical execution object while it is active. AgentExecution journal entries are durable audit and recovery material for accepted messages, observations, decisions, state effects, owner effects, and projection material. Terminal recordings remain raw PTY transport audit. Mission workflow event logs remain orchestration truth. Open Mission chat and timeline views are projections over AgentExecution state, journal rows, and live process state, not independent sources of truth.

Context

Mission already separates AgentExecution, AgentAdapter, Terminal, Mission workflow state, stdout markers, MCP tools, observations, Entity events, and terminal recordings. That separation is correct, but the persistence model has not yet caught up with the current interaction vocabulary and the AgentExecution-owned process model.

The current implementation records useful facts in several places:

  • Mission workflow runtime stores AgentExecution lifecycle participation and terminal recording references.
  • Terminal recordings store raw PTY input, output, resize, and exit records.
  • AgentExecution data can include timeline projection material, but that projection is derived read material.
  • AgentExecution observation duplicate detection is currently process-local.
  • Mission workflow event logs record orchestration facts, not interaction transcripts.

Without canonical AgentExecution journal rows, recovery and UI code would need to reconstruct execution history from terminal scrollback, process memory, or surface state. That would violate repository-owned truth, deterministic validation, and Entity ownership.

Decision

AgentExecution owns durable journal entries for semantic execution records. Journal identity is AgentExecution-scoped and owner-addressed: System, Repository, Mission, Task, and Artifact ownership may influence storage adapters, but it must not create different journal schemas, append/read behavior, replay behavior, or idempotency rules.

The first clean-sheet implementation persists AgentExecution current state and AgentExecution journal entries in separate SurrealDB tables. Storage adapter concerns such as Mission record checkpoints, filesystem mirrors, or future export formats come later and must not change the core journal identity or write discipline.

Journal rows carry full owner-qualified identity so they remain self-describing and queryable:

ownerEntity
ownerId
agentExecutionId
sequence
recordedAt
entryType
payload

sequence is the canonical replay order for one AgentExecution. recordedAt remains audit metadata, not the ordering law.

AgentExecution journal rows record schema-validated facts such as:

  • journal header and launch-time communication snapshot.
  • accepted AgentExecution messages.
  • message delivery attempts and outcomes.
  • normalized AgentExecution observations.
  • policy decisions, including rejected and recorded-only observations.
  • duplicate-handled message or observation decisions that intentionally skip repeated effects.
  • semantic state changes for lifecycle, attention, activity, and current input request.
  • AgentExecution activity and telemetry updates for progress, token usage, active tools, streaming state, active targets, and other compressible execution metadata.
  • owner effects that link accepted observations to Entity events or Mission workflow events.
  • projection material such as chat or timeline items when useful for efficient reads.

Every canonical AgentExecution current-state change must have a corresponding journal entry in the same accepted write path. That same accepted write path also publishes the resulting subscriber notifications, such as SSE updates for the UI. Current-state mutation without a matching journal entry is forbidden.

Duplicate-handled journal rows are part of audit truth, but they do not publish outward unless canonical current state also changes.

AgentExecution messages are owner/operator/daemon-to-AgentExecution input. Agent runtime output is not an AgentExecution message. Runtime output becomes an AgentExecution observation, optionally carrying an Agent-authored structured message when the Agent emitted one. The policy result becomes a durable journaled decision record before state or owner effects are applied.

Mission must keep these ledgers distinct:

Ledger Owner Truth
AgentExecution journal AgentExecution semantic interaction history, recovery, audit, projection source
Terminal recording Terminal raw PTY transport input/output/resize/exit audit
Mission workflow event log Mission workflow runtime orchestration state and workflow legality

Mission workflow runtime stores workflow participation and references to AgentExecution journal state and terminal recordings. It must not store full message transcripts or UI chat state.

Terminal recording remains a distinct replay lane from the semantic journal. Raw terminal input and output are durably replayable as transport truth, but they do not become semantic journal truth unless later accepted through a structured Mission path.

Status Model

AgentExecution status is modeled as multiple dimensions rather than one overloaded lifecycle enum.

Lifecycle is orchestration truth: starting, running, paused, completed, failed, cancelled, terminated.

Attention is collaboration truth: none, autonomous, awaiting-operator, awaiting-system, blocked.

Activity is current semantic work posture: idle, planning, reasoning, communicating, editing, executing, testing, reviewing.

Progress, token counts, streaming summaries, active file labels, active tool names, and transient execution metadata are AgentExecution activity or telemetry. They are recorded separately from semantic state.changed records so they can be compacted, sampled, or summarized without changing lifecycle replay.

Capabilities are runtime affordances and observed activity flags, such as terminal attached, streaming, active tool call, or filesystem mutation. Capabilities are snapshots, not lifecycle states.

AgentExecutionProcess is represented by the serializable AgentExecution instance shape while the execution is active. That shape may include process identity, attached terminal transport identity, active tool calls, in-flight delivery attempts, exit state, and heartbeat data. It is not an AgentExecution runtime snapshot. AgentExecutionStorageSchema decides which process fields are durable enough to persist; live facts that must survive restart need explicit log records or storage fields.

awaiting-input is not a lifecycle state. Input requests are represented as a running execution with attention: awaiting-operator and a current input-request journal record.

Consequences

  • AgentExecution state can be reconstructed from current-state storage plus journal rows after daemon restart or reconcile.
  • Semantic replay does not require retaining every noisy progress or telemetry update.
  • Duplicate observation detection is hydrated from durable journal rows, not only in-memory sets.
  • Duplicate handling remains auditable without turning retries or resubmits into subscriber noise.
  • Open Mission timelines and chat views become projections over AgentExecution truth.
  • Terminal output can be displayed and audited without becoming semantic truth.
  • Mission workflow state stays focused on tasks, AgentExecutions, gates, launch queues, and lifecycle transitions.
  • Agent-authored file activity can be recorded as semantic observation or activity, but filesystem/git truth must come from filesystem/git observation or explicit daemon state.
  • AgentExecution journal schema changes are Mission runtime data changes and must follow ADR-0003.01 rather than fallback parsing or compatibility aliases.

Implementation Rules

  • Do not create a standalone Message Entity unless independent message lifecycle, addressing, querying, or permissions become real requirements.
  • AgentExecution semantic state comes from AgentExecution journal records.
  • Do not store raw private reasoning as semantic thinking content.
  • Do not put high-frequency progress, token usage, streaming summaries, or transient target metadata inside semantic state.changed records.
  • Do not let Open Mission write transcript truth.
  • Do not let MCP, stdout markers, provider SDK events, terminal heuristics, filesystem observation, or git observation bypass the observation to decision to journal path.
  • Do not apply semantic state changes, owner effects, or subscriber publication more than once for the same idempotency/correlation id.
  • Do not encode filesystem backend kinds such as Mission record, Repository control state, or local config folder as AgentExecution journal domain identity.
  • Do not fork AgentExecution journal storage behavior by owning Entity scope; only storage adapter path/table resolution may vary by scope.
  • Do not start a new AgentExecution when durable current-state storage or journal write capability cannot be established.
  • Do keep AgentSignal as the precise name for Agent-authored structured signals; use AgentExecutionObservation for the broader normalized observed fact.
  • Do keep log replay deterministic and covered by tests.