Messages

`message`

A message is one conversational message: a user prompt, an assistant response, a system or developer instruction delivered as a message, context inserted by the agent software (the harness), a message from another session or another person in a chat, or a stored notice.

{
  "type": "message",
  "seq": 3,
  "id": "r3",
  "ts": "2026-10-26T14:02:12.031Z",
  "messageId": "msg_01",
  "role": "user",
  "author": "human",
  "origin": "prompt",
  "audience": "both",
  "content": [{"type": "text", "text": "Fix the failing parser test."}]
}

{
  "type": "message",
  "seq": 8,
  "id": "r8",
  "ts": "2026-10-26T14:02:29.118Z",
  "inferenceId": "inf_01C",
  "messageId": "msg_02",
  "role": "assistant",
  "author": "model",
  "audience": "both",
  "status": "complete",
  "content": [
    {
      "type": "reasoning",
      "visibility": "full",
      "text": "parse_empty expects Ok(vec![]) but the parser returns Err on empty input."
    },
    {
      "type": "text",
      "text": "The parser rejects empty input. I'll make it return an empty list."
    }
  ],
  "assembly": {
    "mode": "folded",
    "sourceIds": [
      "b81e2c47-1d0a-4c3e-9f6b-2a7d5e8c1f03",
      "c03f9a12-6e4b-4d81-a2c7-9b0e3f5d7a64"
    ]
  }
}

Field	Type	Req	Meaning
`messageId`	string	yes	Native message ID, or a derived one (ASR-067).
`role`	string, open	depends	`user`, `assistant`, `system` or `developer`: the role under which the content reached (or came from) the model. Required unless `capture.role` gives a capture state.
`author`	string, open	no	Who wrote the content: `human`, `model`, `harness`, `hook`, `tool` or `agent`. Absent means unknown.
`origin`	string, open	no	How the message entered the session (below).
`phase`	string, open	no	For assistant text: `commentary` (text written while working) or `final` (the answer).
`audience`	string	no	`model`, `user`, `both` or `unknown`. Absent means `unknown`.
`status`	string, open	no	`complete`, `interrupted`, `error`, `partial` or `withdrawn`. Absent means unknown.
`from`	Actor	no	Who sent the message (see Senders and recipients).
`recipients`	array	no	`[{actor, kind?}]`: who the message was addressed to.
`triggersTurn`	boolean	no	Whether delivering the message starts a turn for its recipient, as the source records it.
`conversation`	string	no	The ID of the conversation the message belongs to (see Conversations and platform IDs).
`platform`	object	no	`{messageIds?, replyTo?}`: the platform’s IDs for the message and for the message it replies to.
`addressed`	boolean	no	Whether the message was addressed to this session’s agent (a mention, a reply to it, a direct chat), as the source records it.
`via`	string, open	no	The client surface that submitted the message, when it differs per message: `cli`, `tui`, `ide`, `desktop`, `web`, `mobile`, `api` or `channel`.
`derivedFrom`	string[]	no	Records this message was rendered from (see Derived messages).
`content`	ContentPart[]	yes	The model-facing representation. May be empty (`[]`) when a capture state explains why.
`displayContent`	ContentPart[]	no	A separate user-facing representation, when the source keeps one.
`displayCorrespondence`	string, open	no	`native` (the source stores or links both representations itself) or `derived` (the producer associated them, for example by position).

Capture state keys: content, displayContent, role. ASR-200 A message MUST contain messageId and content, and MUST contain role unless capture.role is present. ASR-201 role describes the channel, not the writer: system and developer are instruction roles (Codex, for example, delivers harness instructions as developer messages); user and assistant are the conversational roles. Some sources decide a message’s role only when they build each request, differently for each provider (OpenClaw’s injected custom messages). When the stored record has no role, role is absent and capture.role is {"state": "absent"}.

Author

Value	Meaning
`human`	A person typed or chose the content.
`model`	The model generated it.
`harness`	The agent software inserted it (reminders, attachments, environment snapshots, notices).
`hook`	A user-configured hook produced it.
`tool`	A tool produced it and the source delivered it as a message rather than a tool result.
`agent`	Another agent produced it (a parent agent’s prompt to a subagent, a subagent’s report, a message from another session’s agent).

ASR-202 A producer MUST set author: "human" only when the source records that a person wrote the content. When the source does not distinguish, author MUST be absent. ASR-203 A producer MUST NOT use author: "human" for content that the source marks as inserted by the harness, a hook or a tool, even when it arrives under role: "user". When the source marks the boundary between human text and inserted text inside one item, the producer MAY split the text at that boundary into separate parts, each with its exact text and its own author and origin (see Part-level values); otherwise it keeps the text whole. A producer SHOULD keep one native item as one message, so that the native ID is kept.

Origin

Value	Meaning
`prompt`	A prompt submitted normally.
`queued`	Submitted while the agent was busy and delivered at the next opportunity.
`steer`	Inserted into a turn already in progress.
`command`	A slash command or similar command invocation, recorded as a message.
`injected`	Context inserted by the harness (reminders, attachments, environment, instruction text).
`memory`	Content loaded from a memory store.
`retrieval`	Content retrieved by search and inserted, including content retrieved from other sessions’ history.
`subagent_report`	A subagent’s result delivered as a message.
`inter_session`	A message from another session or its agent: a message between threads, a peer’s message, a team member’s message. The sending side is usually a tool call in the sender’s stream.
`notice`	A harness notice to the user.

origin: "retrieval" and origin: "memory" let search indexes recognize content that was retrieved from earlier history, so it is not counted again as new evidence. A prompt that a schedule, a webhook or another event caused keeps the author and origin the source records for it (often harness and injected). What started the turn is the turn’s trigger (see Turns and triggers).

Part-level values

One native message can mix content of different kinds: Codex tags each part of a user-role item (the person’s text, AGENTS.md, an environment snapshot, hook context). Splitting such an item into several messages would lose its native ID. Instead, a content part can carry its own author, origin and phase.

{
  "type": "message",
  "seq": 5,
  "id": "r5",
  "ts": "2026-10-26T09:12:41.003Z",
  "turnId": "019a3c2f-0b6e-7c11-a2d4-8e5f1c3b9a07",
  "messageId": "msg_0a7c3e91d2b45f68",
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "# AGENTS.md instructions for /work/acme-app\n\nRun cargo test before every commit.",
      "author": "harness",
      "origin": "injected"
    },
    {
      "type": "text",
      "text": "<environment_context>\n  <cwd>/work/acme-app</cwd>\n</environment_context>",
      "author": "harness",
      "origin": "injected"
    },
    {
      "type": "text",
      "text": "Fix the failing parser test.",
      "author": "human",
      "origin": "prompt"
    }
  ]
}

This record comes from a Codex session. Every part carries its own values, so the message has none. ASR-224 A content part MAY carry author, origin and phase, with the values defined for the message members. A part’s own value applies to that part; the message’s value applies only to the parts that do not carry one. When every part carries its own value, the message member MAY be absent. Readers MUST resolve a part’s effective value this way. ASR-202 and ASR-203 apply to each part’s effective author.

Audience

ASR-204 audience MUST be model, user, both or unknown, and absent means unknown. A producer MUST set model, user or both only when the source indicates who saw the content. It MUST NOT default to both. ASR-205 A stored harness notice MUST be a message with author: "harness", origin: "notice" and audience: "user". Messages with audience: "user" stay on the active path but are not entries in the context view (see Structure).

Status

ASR-206 status MUST be one of the values above or a vendor value. partial means the content is incomplete because generation did not finish or only part was captured; interrupted means the user or harness stopped generation; error means generation failed; withdrawn means queued input that was removed before it was delivered (Claude Code’s queue remove, an OpenClaw pending input that was cancelled). ASR-225 A producer MUST set status: "withdrawn" only when the source records that the input was removed before delivery. A withdrawn message stays on the active path but is not an entry in the context view, and readers MUST NOT present it as received by the model.

Phase

phase separates text that an assistant writes while it works (commentary) from its answer (final), as Codex and OpenClaw record it. The message’s phase is the default for its parts; a part can carry its own (ASR-224), because one response can hold both.

Senders and recipients

from names who sent a message, as an actor reference (see Identity): a participant in a chat, another session, an agent address. It is a separate fact from author (who wrote the words) and origin (how the message entered). recipients names who the message was addressed to; each entry is {actor, kind?}, where kind is primary or additional (open). triggersTurn records whether the source delivered the message so that it starts a turn (Codex trigger_turn).

{
  "type": "message",
  "seq": 31,
  "id": "r31",
  "ts": "2026-10-26T14:06:12.540Z",
  "messageId": "e2b7c9d1-4f3a-4e86-b0c5-7a1d9e2f3b48",
  "role": "user",
  "author": "agent",
  "origin": "inter_session",
  "from": {"session": "claude-code:0f3c2a7e-91b4-4d6a-8c2e-5a7b3d1e9f04"},
  "content": [{"type": "text", "text": "Also check the CLI entry point."}]
}

{
  "type": "message",
  "seq": 77,
  "id": "r77",
  "ts": "2026-10-26T09:31:05.662Z",
  "messageId": "msg_0c18e4a7b95d2f30",
  "role": "user",
  "author": "agent",
  "origin": "inter_session",
  "from": {
    "session": "codex:019a3c2e-5d10-7aa2-8b4e-2f6c9d1a3b58",
    "address": "/root"
  },
  "recipients": [
    {
      "actor": {
        "session": "codex:019a3c2e-5d10-7aa2-8b4e-2f6c9d1a3b58",
        "address": "/root/worker"
      },
      "kind": "primary"
    },
    {
      "actor": {
        "session": "codex:019a3c2e-5d10-7aa2-8b4e-2f6c9d1a3b58",
        "address": "/root/reviewer"
      },
      "kind": "additional"
    }
  ],
  "triggersTurn": true,
  "content": [
    {"type": "text", "text": "Run the parser tests again after the fix."}
  ]
}

The first record is in the stream of the example session’s subagent: the parent sent it with a tool call, and the subagent received it as a user-role message. The second comes from a Codex worker thread. Codex addresses agents by path inside one agent tree, so each address carries the tree’s root session as its scope. ASR-226 from, recipients, triggersTurn, conversation, platform, addressed and via MUST come from the source. A producer MUST NOT set author: "human" because from names a person, MUST NOT set from because of author, and MUST NOT invent a recipient or the turn a message started. ASR-228 from and each recipient’s actor MUST be actor references (ASR-076), and each element of derivedFrom MUST be a ref (ASR-062) or a session reference with a # part.

Conversations and platform IDs

In a chat, conversation names the conversation a message belongs to, by an ID from the header’s conversations (see Session records). platform keeps the messaging app’s own IDs: messageIds (one message can arrive or leave as several platform messages) and replyTo (the platform ID of the message it answers). addressed records whether the message was meant for this agent, which matters in a group where the agent also sees messages not meant for it.

{
  "type": "message",
  "seq": 12,
  "id": "r12",
  "ts": "2026-10-26T07:41:19Z",
  "tsPrecision": "s",
  "messageId": "a41f0c9e",
  "role": "user",
  "origin": "prompt",
  "from": {"participant": "p2"},
  "conversation": "c1",
  "platform": {
    "messageIds": ["3EB0C431D5A2F1B7E8"],
    "replyTo": "3EB0B2A9C4D61E05F3"
  },
  "addressed": true,
  "via": "channel",
  "content": [
    {
      "type": "text",
      "text": "@Molty what time is the dentist on Thursday?"
    }
  ]
}

This record comes from the OpenClaw session whose header is shown under Participants. The sender is participant p2, whose kind OpenClaw does not know, so author is absent. ASR-227 conversation MUST name a conversation declared in the header or in a declaration with a lower seq.

Derived messages

derivedFrom lists the records a message was rendered from, when the source records them: a handoff summary built from another session’s history, a merge-back of a fork, a summary written for a switch to another provider. Entries are refs to records in this stream, or session references with a # part for records in other sessions. A derived message is new content of this session, not a copy: copies of records use copiedFrom (see Lineage).

{
  "type": "message",
  "seq": 58,
  "id": "r58",
  "messageId": "message:handoff:7c2e",
  "role": "user",
  "author": "harness",
  "origin": "injected",
  "derivedFrom": ["r40", "r41", "r44"],
  "content": [
    {
      "type": "text",
      "text": "Context from the earlier provider: parse_empty failed on empty input; a fix that returns an empty list is in progress."
    }
  ]
}

This record comes from a T3 Code thread that switched from Codex to Claude Code. T3 Code rendered a summary of three earlier records and sent it to Claude Code as the first prompt. ASR-229 A producer MUST write derivedFrom only when the source records which records the message was rendered from. It MUST NOT infer derivedFrom from similar text.

Content and display content

content is what the model received or produced. displayContent is what the user saw, when the source keeps a different representation: Gemini CLI’s displayContent, Cline’s UI message array, an interface rendering of a tool-heavy turn. An app that wraps a prompt before sending it to the model (T3 Code adds its own instructions around a person’s first prompt) keeps what the person typed. Its stream records that text in displayContent, with content empty and capture.content set to absent unless the app also recorded the wrapped text. ASR-207 When the source holds only a user-facing representation of a message, the producer MUST put it in displayContent, leave content empty, and set capture.content to absent. It MUST NOT copy display text into content unless the source states that the two are the same. ASR-208 When displayContent is present, content is non-empty and the source links the two, displayCorrespondence SHOULD state how. Absent means correspondence is unknown. A validator does not report its absence, because it cannot establish whether the source links the two representations. Any asserted correspondence remains subject to its type and content rules. ASR-209 When the source rewrote stored content after the model saw it (for example by masking a large output), the producer MUST set the capture state of the affected field to masked (see Missing data and revisions).

Content parts

Content parts are the content blocks of MCP revision 2026-07-28, as reused by the Agent Client Protocol (ACP) schema v2.0.0-alpha.9, with the additions and deviations listed below. MCP tool output passes through unchanged. ASR-210 Every content part MUST be an object with a string type. ASR-211 Text MUST be kept exactly as the source stored it: no trimming, reflowing, Unicode normalization or line-ending conversion. Streaming deltas MUST be joined only by direct concatenation, and a final snapshot MUST NOT duplicate text already received as deltas.

`text`

{"type": "text", "text": "Fix the failing parser test."}

Field	Type	Req	Meaning
`text`	string	yes	The text.
`annotations`	object	no	MCP annotations (`audience`, `priority`, `lastModified`), preserved verbatim.

`image` and `audio`

{
  "type": "image",
  "mimeType": "image/png",
  "blob": {
    "blob": "sha256:4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce",
    "size": 20311,
    "mimeType": "image/png"
  }
}

Field	Type	Req	Meaning
`mimeType`	string	yes	Media type.
`data`	string	no	Base64 bytes (MCP’s field).
`blob`	BlobRef	no	The bytes as a blob (ASR addition).
`annotations`	object	no	MCP annotations.

ASR-212 image and audio parts MUST have mimeType and MUST NOT have both data and blob. A part with neither carries no bytes; the record’s capture state for the field says why.

`resource_link` and `resource`

resource_link is MCP’s ResourceLink: {type, uri, name, title?, description?, mimeType?, size?, annotations?}. resource is MCP’s EmbeddedResource: {type, resource, annotations?}, where resource is {uri, mimeType?, text} or {uri, mimeType?, blob} with blob as base64, exactly as in MCP. ASR-213 A resource_link MUST have uri and name. A resource MUST have resource.uri and at most one of resource.text, resource.blob (base64, as in MCP) and resource.blobRef (a BlobRef, an ASR addition). URIs in content are data. Readers never fetch them automatically (ASR-562).

`reasoning`

{
  "type": "reasoning",
  "visibility": "summary",
  "summary": ["Checked the empty-input path first."],
  "signature": "EqQBCkgIBRABGAIiQHkx"
}

Field	Type	Req	Meaning
`visibility`	string, open	no	What the provider exposed: `full`, `summary`, `omitted`, `encrypted` or `redacted`. Absent means unknown.
`text`	string	no	The reasoning text, when `visibility` is `full` or absent.
`summary`	string[]	no	Provider-written summary segments, each kept exactly, when `visibility` is `summary` (or alongside other forms when the source has both).
`opaque`	object	no	`{format?, data? \| blob?}`: ciphertext or provider-native reasoning state. `format` names it (for example `anthropic.redacted_thinking`, `openai.encrypted_content`).
`signature`	string	no	A provider signature over the reasoning.

Visibility values:

full: the provider exposed the reasoning text.
summary: the provider exposed only a summary.
omitted: the provider or harness withheld the text (often leaving an empty text and a signature).
encrypted: the reasoning exists only as ciphertext.
redacted: the provider redacted it, leaving opaque data.

ASR-214 A producer MUST NOT put text the source marks as a summary in text, or label a summary as visibility: "full". It MUST set visibility when the source states it. Readers MUST NOT present text as full reasoning unless visibility is full. ASR-215 opaque and signature MUST be excluded from text indexing and from metadata exports. Readers MUST NOT render them as text. ASR-216 Visibility and capture state are independent. visibility says what the provider exposed; the record’s capture state says how much of the source’s stored content is included in the record. A full reasoning part can be truncated; an encrypted one can be complete.

`refusal`

{"type": "refusal", "text": "I can't help with that request."}

ASR-217 A refusal part MUST have text: the refusal message the model returned through a dedicated refusal channel. Refusals expressed in ordinary text stay text parts.

`data`

A data part holds structured data the source attached to a message: an IDE selection, an environment snapshot, a terminal excerpt, a page element, review findings. It is an ASR part type.

{
  "type": "data",
  "data": {
    "file": "crates/parser/src/lib.rs",
    "lineStart": 38,
    "lineEnd": 44
  },
  "schema": "com.anthropic.claude-code/attachment/selected_lines_in_ide"
}

Field	Type	Req	Meaning
`data`	any	yes	The data, as JSON.
`schema`	string	no	A name for the data’s structure: a reverse-DNS name, as the agent’s registry entry documents it, or a URI (never fetched).

ASR-230 A data part MUST contain data. A data part in displayContent says what the user saw. It is not evidence that the model received the data, or received it as JSON. When the source keeps structured data but not the text the model received (Claude Code renders attachments into the request at send time), the message holds the data part in content. The message’s capture state describes the structured content it holds, rather than the rendered text that was not kept. ASR-238 Structured source content does not establish the exact rendered input the model received. Readers MUST NOT present a data part as the exact text the model saw. A nonempty content array MUST have a compatible capture state (ASR-506). Data known only as a UI representation MUST be in displayContent (ASR-207).

`opaque`

An opaque part holds content that the source keeps only in a form that cannot be read: an encrypted message part, encrypted content from another agent. Encrypted reasoning stays a reasoning part with opaque state (see reasoning).

{
  "type": "opaque",
  "format": "openai.encrypted_content",
  "data": "Z0FBQUFBQnBhWGhoYlhCc1pTMWxibU55ZVhCMFpXUmZiV1Z6YzJGblpRPT0="
}

Field	Type	Req	Meaning
`format`	string	yes	The format of the opaque content, as a name (for example `openai.encrypted_content`).
`data`	string	no	The content, as the source stores it.
`blob`	BlobRef	no	The content as a blob.

ASR-231 An opaque part MUST contain format and MUST NOT contain both data and blob. ASR-232 Opaque parts MUST be excluded from text indexing and from metadata exports. Readers MUST NOT render them as text.

Derivation

When a source replaced content by a derived form (a transcript of a voice note, a caption, a translation), the derived part can say so with derivation.

[
  {
    "type": "text",
    "text": "Can you move the dentist to Friday?",
    "derivation": {"method": "transcription", "from": 1}
  },
  {"type": "audio", "mimeType": "audio/ogg"}
]

Here a voice note was transcribed. The audio part keeps its media type; the record’s capture state says why its bytes are not included.

Field	Type	Req	Meaning
`method`	string, open	yes	`transcription`, `caption`, `ocr`, `translation` or `summary`.
`from`	integer	no	The 0-based index of the part it was derived from, in the same array, when the record keeps that part.

ASR-233 A derivation MUST contain method, and a producer MUST set it only when the source records that the content was derived. from, when present, MUST be the index of another part in the same array.

Unknown parts and deviations

ASR-218 Readers MUST skip content parts whose type they do not recognize, and storage tools MUST preserve them. MCP annotations and _meta on parts MUST be preserved verbatim. Deviations from MCP 2026-07-28 and ACP schema v2.0.0-alpha.9 content blocks:

image and audio accept blob (a BlobRef) instead of data, and may carry neither when the bytes were not captured.
resource.resource accepts blobRef.
reasoning, refusal, data and opaque are ASR part types. ACP carries reasoning as separate agent_thought messages (see Reasoning-only messages).
Any part may carry the ASR members author, origin, phase and derivation.
Tool calls and tool results are records (tool_call, tool_result), never content parts.

Reasoning-only messages

ACP v2 sends reasoning as agent_thought messages with their own messageId, and Codex stores reasoning items with their own IDs. A reasoning-only message is a message whose content is exactly one reasoning part. It keeps the native ID.

{
  "type": "message",
  "seq": 412,
  "id": "r412",
  "inferenceId": "resp_7a19c3e2",
  "messageId": "rs_0c41f2a9d8e7",
  "role": "assistant",
  "author": "model",
  "content": [
    {
      "type": "reasoning",
      "visibility": "encrypted",
      "summary": [],
      "opaque": {
        "format": "openai.encrypted_content",
        "data": "Z0FBQUFBQnBaWGhoYlhCc1pTMWxibU55ZVhCMFpXUQ=="
      }
    }
  ]
}

This example comes from a Codex session; its empty summary array is preserved literally. ASR-219 A producer MUST keep a reasoning item that has its own native ID as a reasoning-only message with that ID, rather than folding it into an adjacent assistant message. ASR-220 Readers MUST treat a reasoning-only message the same way as a reasoning part inside an assistant message. Visibility, capture, redaction and indexing rules apply identically.

`plan`

A plan is the agent’s current task list, plan document or goal, as recorded by the source: ACP plan_update, Codex update_plan, a to-do tool, a plan-mode document, a long-running goal with a budget. Each plan record is a complete snapshot. A changed plan is a revision with the same planId.

{
  "type": "plan",
  "seq": 23,
  "id": "r23",
  "planId": "plan_1",
  "idSource": "derived",
  "planType": "items",
  "callId": "call_P3",
  "entries": [
    {"content": "Reproduce the parse_empty failure", "status": "completed"},
    {
      "content": "Return an empty list for empty input",
      "status": "in_progress"
    },
    {"content": "Run the parser test suite", "status": "pending"}
  ]
}

This example comes from a Codex session, where the plan is set by an update_plan tool call and has no native plan ID. Plan documents and goals:

{
  "type": "plan",
  "seq": 17,
  "id": "r17",
  "planId": "quiet-amber-falcon",
  "planType": "document",
  "callId": "toolu_01P",
  "source": {
    "root": null,
    "path": "/home/dev/.claude/plans/quiet-amber-falcon.md"
  },
  "content": [
    {
      "type": "text",
      "text": "1. Reproduce parse_empty.\n2. Return Ok(vec![]) for empty input.\n3. Run the parser tests."
    }
  ]
}

{
  "type": "plan",
  "seq": 62,
  "id": "r62",
  "planId": "goal-v1-thread-created",
  "idSource": "derived",
  "planType": "goal",
  "status": "active",
  "content": [
    {"type": "text", "text": "Keep the parser test suite green on main."}
  ],
  "budget": {"tokens": 2000000},
  "used": {"tokens": 412870, "seconds": 1834}
}

{
  "type": "plan",
  "seq": 70,
  "id": "r70",
  "planId": "tasks_main",
  "idSource": "derived",
  "planType": "items",
  "entries": [
    {
      "entryId": "1",
      "content": "Fix parse_empty",
      "status": "completed",
      "owner": "main"
    },
    {
      "entryId": "2",
      "content": "Check other empty-input call sites",
      "status": "in_progress",
      "owner": "explorer",
      "blockedBy": ["1"]
    }
  ]
}

The first record is a Claude Code plan-mode document, named by the plan file. The second is a Codex goal whose ID is derived from its stable, unique (threadId, createdAt) tuple under the registry rule. The third is a Claude Code task list with entry IDs, owners and dependencies.

Field	Type	Req	Meaning
`planId`	string	yes	Native plan ID, or a derived one.
`planType`	string, open	yes	`items` (a list of entries, as ACP’s `items` plan type), `document` (a written plan), `goal` (an objective the agent keeps working toward), or a vendor type.
`status`	string, open	no	The plan’s own status. For goals: `active`, `paused`, `blocked`, `usage_limited`, `budget_limited` or `complete`.
`entries`	array	when `items`	`[{entryId?, content, status, priority?, owner?, blockedBy?}]`. `priority` is `high`, `medium` or `low`; `status` is `pending`, `in_progress` or `completed` (all open). `owner` names the agent that owns the entry, as the source records it. `blockedBy` lists the `entryId`s of entries that must finish first.
`content`	ContentPart[]	depends	The document, or the goal’s objective. Required for `document` and `goal` unless `capture.content` gives a capture state.
`source`	PathRef	no	The file that holds a plan document.
`budget`	object	no	`{tokens?, seconds?}`: a goal’s budget.
`used`	object	no	`{tokens?, seconds?}`: how much of it was used, as the source records it.
`callId`	string	no	The tool call that set the plan, when the plan came from a tool.

Capture state key: content. ASR-221 A plan MUST contain planId and planType. When planType is items it MUST contain entries, and each entry MUST contain content and status. When planType is document or goal it MUST contain content or a capture.content state. ASR-222 A plan record MUST be a complete snapshot. A later state of the same plan MUST be a new plan record with the same planId and supersedes naming the previous one. ASR-236 The entryId values in one plan record MUST be unique, and every value in an entry’s blockedBy MUST be the entryId of another entry in the same record. Questions to the user, delegation to other agents and plans are separate record types (input_request, subagent, plan). Consumers find them by record type, not by the kind of the tool call that produced them (see Tools).

`delivery`

A delivery records what happened to a message the agent sent to a conversation: queued, sent, delivered, held back, or failed. On a messaging app, an assistant message says what the agent wrote; it does not say that anyone received it. A reply can be held back (OpenClaw’s NO_REPLY), cancelled by a hook, or fail on the platform.

{
  "type": "delivery",
  "seq": 15,
  "id": "r15",
  "ts": "2026-10-26T07:41:31.882Z",
  "message": "messageId=b7e2d940",
  "conversation": "c1",
  "status": "sent",
  "platformMessageIds": ["3EB0D7F21A9C4E6B20"]
}

{
  "type": "delivery",
  "seq": 27,
  "id": "r27",
  "ts": "2026-10-26T08:02:10.450Z",
  "message": "messageId=c03a5f18",
  "conversation": "c1",
  "status": "suppressed",
  "reason": "NO_REPLY"
}

These records come from the OpenClaw session under Participants. The first reply was sent to the group. The agent chose not to answer the second message, so its final text was not sent.

Field	Type	Req	Meaning
`message`	Ref	no	The message the delivery is for.
`conversation`	string	no	The ID of the conversation it was sent to.
`status`	string, open	yes	`queued`, `sent`, `delivered`, `suppressed`, `failed` or `unknown` (below).
`reason`	string	no	Why it was suppressed or failed, as the source records it.
`platformMessageIds`	string[]	no	The platform’s IDs for what was sent.
`attempt`	integer	no	The attempt number, when the source records retries.

Status	Meaning
`queued`	Waiting in the outbound queue.
`sent`	Handed to the platform.
`delivered`	The platform confirmed delivery.
`suppressed`	Not sent, on purpose (a silent reply, a hook cancelled it).
`failed`	Sending failed.
`unknown`	The source records an attempt but not its outcome.

A change of status is a revision of the delivery record (supersedes). ASR-234 A delivery MUST contain status. ASR-235 A delivery’s message and conversation follow the reference-resolution table. Their targets MUST be a message record and a declared conversation, respectively (ASR-227). ASR-237 A producer MUST write delivery records only from the source’s record of an outbound attempt or its outcome, never from the existence of a message. Readers MUST NOT present a message as delivered unless a delivery for it has status sent or delivered.

Introduction

Format

Records

Trust

Extending and conforming

Agent registry

`message`

Author

Origin

Part-level values

Audience

Status

Phase

Senders and recipients

Conversations and platform IDs

Derived messages

Content and display content

Content parts

`text`

`image` and `audio`

`resource_link` and `resource`

`reasoning`

`refusal`

`data`

`opaque`

Derivation

Unknown parts and deviations

Reasoning-only messages

`plan`

`delivery`

​message

​Author

​Origin

​Part-level values

​Audience

​Status

​Phase

​Senders and recipients

​Conversations and platform IDs

​Derived messages

​Content and display content

​Content parts

​text

​image and audio

​resource_link and resource

​reasoning

​refusal

​data

​opaque

​Derivation

​Unknown parts and deviations

​Reasoning-only messages

​plan

​delivery

`message`

Author

Origin

Part-level values

Audience

Status

Phase

Senders and recipients

Conversations and platform IDs

Derived messages

Content and display content

Content parts

`text`

`image` and `audio`

`resource_link` and `resource`

`reasoning`

`refusal`

`data`

`opaque`

Derivation

Unknown parts and deviations

Reasoning-only messages

`plan`

`delivery`