Status: 0.1 Draft. Streams written to this version carry "formatVersion": "0.1". This draft is complete enough to implement and test against, and it will change in response to review. It is not frozen: version 1.0 requires the golden corpus, the validator, and two independent implementations that agree on the corpus (see Conformance).

What ASR is

Agent Session Record (ASR) is a vendor-neutral, append-only JSON Lines format for keeping a record of one agent session. A stream records:
  • what people and other agents sent, and what the model received and produced;
  • what started each turn: a person, a schedule, an event, another agent;
  • which tools ran, with what input and what result, and which approvals and questions they needed;
  • which model calls were made, with what usage and cost;
  • what the agent wrote to memory, and which replies were delivered to which conversations;
  • which files changed, and which commits and pull requests resulted;
  • which sessions were spawned, forked or continued from which other sessions;
  • how the context was compacted, rewound or branched;
  • what is missing, truncated, redacted or unknown.
ASR is to the Agent Client Protocol (ACP) what SARIF is to the Language Server Protocol’s diagnostics: ACP is the live channel between an editor and an agent, and ASR is the archival record of what happened. A live ACP v2 stream can be recorded into ASR with declared, tested losses (see ACP mapping). The machine token is agent-session everywhere: in the media type application/vnd.agent-session+jsonl, in directory names, and in the Agent-Session commit trailer defined by the integration companion. “ASR” appears only in prose.

Scope

ASR covers general agent sessions:
  • coding agents that read and change a workspace (Claude Code, Codex);
  • personal assistants that talk to people on messaging apps, run on schedules and keep memory (OpenClaw);
  • apps that run other agents and keep their own record of each conversation (T3 Code, which drives Claude Code and Codex).
The 0.1 draft is fitted first to four tools, in this order: Claude Code, T3 Code, Codex and OpenClaw. Everything these tools record has a place: a standard field or record, or a destination the tool’s registry entry documents. The core (identity, ordering, revisions, triggers, approvals, questions, memory, lineage, compaction, usage) is not specific to any domain. Domain profiles add promises for one kind of work: coding for workspaces and version control, messaging for chat channels and delivery (see Profiles). ASR is built so that:
  1. native logs from existing harnesses can be converted now, without vendor help, with any losses declared;
  2. a harness can adopt it with little work, up to making its native log a conformant stream;
  3. a live ACP v2 stream can be recorded into it with declared losses;
  4. ATIF trajectories, OpenTelemetry spans and line-attribution notes can be generated from it according to companion specifications, instead of being captured separately.

Non-goals

  • Not a live protocol. ASR does not negotiate, request or respond. ACP and the Model Context Protocol (MCP) do that.
  • Not a resume format. A record does not restore processes, credentials, sandboxes, file systems or provider-private continuation state (encrypted reasoning, prompt caches). Runnable native resume (continuing a session in its original harness) is an adapter capability, qualified per harness. Displaying a record never re-executes tools.
  • Not telemetry. ASR records are complete and ordered, not sampled spans. Spans can be generated from a record (see the OpenTelemetry companion).
  • Not an attribution format. Records carry literal facts (this tool call changed this file; this command produced this commit). Line attribution is a derived view (see the attribution companion).
  • Not a judgment of the session. ASR does not say which session “produced” a commit, how trustworthy a producer is, or how good a session was.
  • Not a guarantee that a record is safe to share. A conformant stream can contain secrets. Sharing requires a redaction policy (see Privacy and security).

Relation to other formats and protocols

Use cases

  1. Search and memory across harnesses.
  2. Portable handoff: seed a new session, in any harness, from a prior record. Resuming in the original harness is something an adapter may support, stated separately for each harness.
  3. Review and audit of what an agent did and why: approvals, questions, memory writes and the replies it delivered.
  4. Attribution and blame evidence that links code to the session and tool call that wrote it.
  5. Evaluation and training export.
  6. Cost and usage analytics without double counting.
  7. Replay viewers that show a session without re-executing anything.
A field or record joins the core when a use case needs it and at least two of the four priority tools record it, or when it is the only way to keep a concept ASR already has. Every other recorded fact gets a documented destination in the agent’s registry entry (see Extensibility).

Design principles

  1. Record what happened. Interpretations, such as which session produced a commit, are left to the tools that read records.
  2. Keep native IDs. Producers keep the source’s own identifiers verbatim.
  3. Declare what is missing. An absent field means unknown. Truncation, masking and missing history are stated, never hidden.
  4. Append-only and crash-safe. Records never change once written; a torn final line is ignored.
  5. A small required core, with capability-based profiles.
  6. Aligned with the live protocol. ACP v2 maps onto ASR with declared losses.
  7. Links need evidence. No lineage, copy or link is inferred from similar text or timing.
  8. Designed for redaction. Paths are relative to workspace roots, roots can be redacted, opaque content is never indexed, and sharing requires an explicit policy.
  9. Preserve what you do not understand when storing or rewriting in the same format.
  10. Ship with a validator, converters and real fixtures. Every normative statement that can be checked has a requirement ID.

Document map

Companion documents are versioned separately and are not part of core conformance: integration (commit trailers, notes ref, export command, discovery file), ATIF, OpenTelemetry, attribution, UAS and Entire.

Status and process

This specification follows the stages that ACP uses for its proposals: Draft → Preview (with a working implementation) → Completed (with conformance tests). This document is the 0.1 Draft.
  • The format version is 0.1. The document revision is separate from the format version: editorial fixes to this text do not change formatVersion.
  • Every feature in this draft is a normal feature with one JSON Schema. There is no experimental tier. A feature that is not ready is left out and listed below.
  • Version 1.0 requires: the normative algorithms covered by fixtures, a golden corpus of sanitized real sessions from at least ten harnesses, the validator and the JSON Schema, the agent identity registry, the published ACP v2 support matrix, and two independent converters that produce matching results for the same five harnesses.
  • Streams written as 0.1 may need migration to later versions. A central migration tool will be provided.

Not in 0.1

These are left out of the 0.1 draft. Each can come back when a priority tool records it or a companion needs it. Until then, a source that records one of them keeps it at the destination its registry entry documents.
  • principal, tenant and on-behalf-of identity;
  • payments;
  • a person taking over a browser from the agent;
  • tamper-evidence seals;
  • guardrail verdicts as their own records;
  • export coverage, retention policies and legal holds;
  • provider-verified versus client-asserted provenance;
  • agent-to-agent tasks across vendors (A2A);
  • live voice sessions;
  • streams for a memory store itself;
  • standalone records of resource access;
  • the uncommitted changes of a root when it was declared (dirtyPatch);
  • general effect and task records;
  • lineage for sessions imported from another harness.