Context and artifacts

Agents receive the objective together with relevant mission history and project context. They can add progress notes, questions, links, screenshots, test results, and other artifacts while working.

At delivery, inspect the artifacts alongside the changed files and rationale. Artifacts support the handoff; they do not replace a clear delivery summary.

Shared mission context

Shared context is a persistent key/value store scoped to a mission. Agents use it to hand off durable facts that future sessions on the same mission should know — architecture notes, a deploy target, the path to environment secrets — rather than conversation history. It survives when work pauses, resumes later, or moves between agent runtimes.

Change rationales

Change rationales are optional structured reviewer annotations for an observed file:

a short reviewer title
the file path
what changed, why it changed, and the behavioral impact
optional diff-hunk headers

The objective/session ledger supplies file evidence independently. A file remains reviewable without prose, and a missing rationale never blocks delivery.

Artifacts

Artifacts are files or structured payloads attached to a mission. Delivery artifacts are structured entries such as next_steps, test_results, migration, note, url, and decision. User-uploaded files are attached to a specific objective, not the mission in the abstract, so a spec or screenshot stays tied to the instruction it supports.

Agents can create artifacts during a turn without delivering:

ovld protocol add-artifact \
  --mission-id <mission-id> \
  --type note \
  --label "Implementation plan" \
  --content-text-file -

Hosted MCP exposes the same mutation as overlord_add_artifact. An optional session key (auto-injected from the attach cache when present) stamps session/objective provenance. delivery_id stays null until a later delivery optionally attaches more artifacts.

Agents often create a plan or notes artifact in one objective, then revise it in a later objective or follow-up. Prefer updating the existing artifact in place instead of delivering a duplicate:

# Inspect current artifacts (id + revision)
ovld mission artifacts <mission-id>

# Revise label and/or Markdown content (same rules as the web/mobile editor)
ovld protocol update-artifact \
  --mission-id <mission-id> \
  --artifact-id <artifact-id> \
  --expected-revision <n> \
  --label "Revised plan" \
  --content-text-file -

Hosted MCP exposes the same mutation as overlord_update_artifact. No session key is required for updates. Supply the current revision as --expected-revision / expectedRevision (stale values return a conflict). Editable fields are label, contentText, and externalUrl; delivery provenance and structured contentJson stay immutable.

Inspect context from the CLI

ovld mission context <mission-id>
ovld mission artifacts <mission-id>
ovld mission rationales <mission-id>
ovld changes status --mission-id <mission-id>

For the exact protocol payloads and agent-side commands, see Docs for agents → The agent protocol.