For the complete documentation index, see llms.txt. This page is also available as Markdown.

🤖Agent Session

Captures an AI agent's session trace — prompts, tool calls, results, artifacts — alongside the human-facing conversation.

Draft: draft-howe-vcon-agent-session · Extension name: "agent_session"

What it is

A growing number of "conversations" involve an AI agent on at least one side. The human-facing surface of that interaction — the words exchanged, the time, the parties — fits cleanly into a normal vCon. The agent's internal session — the prompts it received, the tools it called, the responses those tools returned, the files it touched, the reasoning it produced — does not. That data is just as important for audit, debugging, training, and compliance, but it sits in a different shape.

The Agent Session extension brings that data into the vCon as a peer to the human dialog. It uses vCon's existing primitives:

  • The agent is represented as a party with role: "agent" and structured metadata describing the model.

  • The session trace lives in analysis as a Verifiable Agent Conversations (VAC) document.

  • Agent-produced artifacts and environment snapshots live in attachments.

That means agent sessions inherit everything vCon already has — consent, signing, redaction, lifecycle, SCITT.

When to use it

  • Documenting LLM-driven contact-center deflection: the LLM's full prompt-and-tool-call trace is auditable alongside the call recording.

  • Coding-agent sessions (Claude Code, Cursor, etc.) where the conversation, the tool invocations, and the file edits are all part of the same record.

  • AI-assisted workflows where the agent's output needs to be reproducible: the trace tells you exactly what the agent did and why.

  • Bridging vCon and VAC (Verifiable Agent Conversations) — the two specs are designed to compose.

Spec surface

Agent Session adds data in three places.

1. Party metadata

Each agent participant is a normal party, distinguished by role: "agent" and a structured meta.agent_session block:

2. Session trace in analysis[]

The full VAC session trace is a JSON document stored as an analysis entry with type: "agent_trace":

The body is the VAC document, encoded as a JSON string. vendor, product, and schema identify the agent and the trace format.

3. Artifacts in attachments[]

Files the agent produced, environment snapshots, and tool-call payloads go in attachments[] with one of these purposes:

Purpose
Meaning

agent_file_change

A file the agent created, modified, or deleted

agent_artifact

A standalone artifact the agent produced (e.g. a generated document)

agent_environment

A snapshot of the agent's runtime environment at the time of the session

Declare the extension at the top level:

Relationship to other extensions

  • Lawful basis. Agent-session data is personal data when the agent participated in a conversation with a real person. Use the Lawful Basis extension the same way you would for the human-only case.

  • Lifecycle. Agent traces benefit especially from a Lifecycle ledger — being able to prove what the agent saw and did, when, is the entire compliance story for AI-assisted workflows.

  • WTF. If the agent session also produced spoken output (TTS), that recording is normal vCon dialog, optionally transcribed via WTF.

See also

  • The vcon-anthropic-chats adapter (see Tools) converts Claude AI conversation exports into vCons using this extension.

  • The vcon-vac project is the reference implementation tying VAC traces into vCons.

Last updated

Was this helpful?