Several existing formats describe parts of an agent session, and each is well suited to the job it was designed for. None was designed to be the lasting, cross-harness record of a whole session, whether the agent writes code, runs other agents or answers people on messaging apps. ASR does not try to replace any of them. A session is recorded once in ASR, and trajectories, spans and attribution are derived from the record through companion specifications. Descriptions below reflect each project’s public documentation as of October 2026.

What ASR adds

The gaps above describe the requirements for keeping a session record:
  • Append-only and crash-safe. A session is written as it happens. Readers ignore a partially written final line and report a diagnostic and a gap for a damaged line in the middle.
  • Structure as recorded. Subagents, forks, continuations, compactions and rewinds are explicit records or lineage facets, each with its own evidence.
  • Coding facts. File changes, workspace state, checkpoints, commits and pull requests are separate records, each with stated precision and evidence.
  • Assistant facts. Who sent each message in a group chat, which conversation it belongs to, whether each reply was delivered, what started a turn that no person typed, who or what approved each action, the questions the agent asked and their answers, and what it wrote to memory.
  • Apps that run other agents. An app’s stream links to the sessions of the agents it ran (executedBy), so model calls and cost are counted once and authorship comes from the app, which knows which prompts a person typed.
  • Declared loss. Capture states, gap records and declared lossy features describe what a record does not contain. Converters never fill holes with guesses.
  • Vendor neutrality. Native IDs are canonical, the agent identity registry documents each harness’s ID rules, and no single product owns the format.

What ASR borrows

ASR reuses what already works:
  • From ACP: content blocks shared with the Model Context Protocol (MCP), tool kinds, _meta extension keys, _-prefixed vendor enum values, open enums, and staged proposals.
  • From GitHub UAS: “absence is not zero”, no fabricated IDs or timestamps, exact text, explicit dangling and orphan tool calls, numbered requirements and conformance classes.
  • From OpenTelemetry: the rule that an identifier is recorded only when one is actually available, never synthesized from a hash or a fresh UUID.
  • From Git AI: a deterministic join key built from the tool name and the native session ID.
  • From Entire: keeping the native transcript next to the normalized record, and an append-only record log.
  • From MCP: a feature lifecycle with a minimum deprecation window of 12 months.

Why these four tools

Version 0.1 is fitted first to four tools that between them cover the kinds of session ASR needs to record:
  • Claude Code and Codex, coding agents that write detailed local session logs: subagents, background processes, plans, questions to the user and, in Claude Code, hook runs and approval decisions.
  • T3 Code, an app that runs Claude Code and Codex sessions and adds its own queues, approvals, delegated tasks and messages between threads.
  • OpenClaw, an open-source personal assistant on messaging apps, with group chats, senders, scheduled turns, reply delivery and memory files.
Everything these four tools record has a place in ASR: a standard field or record type when at least two of them record it, and otherwise a documented vendor key or record type in the tool’s agent registry entry. Other agents, such as Gemini CLI, Cursor or Hermes Agent, use the same records. The roadmap lists what 0.1 leaves out. See the FAQ for common questions, such as why ASR does not extend ATIF.