vCon for AI Agent Conversations: Requirements, Gaps and Extension Roadmap

Introduction AI agents act on behalf of people and other agents. They exchange prompts and responses with people, delegate to other agents and invoke tools. Several drafts define requirements for recording these interactions (e.g. and ). vCon is a container for conversation data and the analysis of it. A vCon captures the observation of a conversation from one or more points in the network. An agent conversation is not that different from a contact center conversation in this respect. We do not want to solve all of this with vCon. vCon is a good fit for some of the requirements, but some are better met with plain logging and some need other solutions. This document:

sorts the requirements into vCon, logging and other solutions
identifies the gaps between the vCon requirements and
proposes a strawman break down of vCon extensions to fill the gaps

This is a first cut and is surely incomplete. We would like feedback on what is missing or should not be included.

Example Observation Points The observation points in are examples, not an exhaustive list. A conversation may be observed from any point in the network that it passes through, such as a gateway (e.g. and ), a proxy or a platform. In back end scenarios where communications inside a silo are less secure, ordinary network entities may also be observers. Each observation may go in a single vCon or in separate vCons that are linked or merged later. This is the same as a contact center call, which may be observed by the carrier, the contact center platform or both.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology See section 2.1 of for terminology used in this document. Agent: As defined in , "a Workload whose behaviour is driven, in whole or in part, by a non-deterministic decision process (typically an LLM)". Tool: As defined in , "an external service invoked by an agent to retrieve data or perform operations. A tool is not necessarily an agent and may not participate in agent-to-agent communication." Observation Point: A point in the network from which a conversation, or part of it, is observed and recorded (see ).

Requirements and Split The requirements considered here come from two sources:

REQ-1 through REQ-11 in section 2.2 of
the four record types in section 5 of

Related work on AI logging includes . We only briefly summarize the requirements here, enough to jog the memory of someone who has read the source drafts. Each requirement is put into one or more of the following categories:

vCon - the conversation and the analysis of it
Logging - system and operational events
Other Solutions - existing or other IETF work

Some requirements are split across categories. The agent protocols themselves (e.g. and those in ) are not candidates for capture in vCon. The data exchanged over them, and the results of them that bear on the conversation (e.g. identity or the tools discovered), are candidates for observation and capture in vCon.

vCon From :

REQ-1, REQ-4 Event Logging and Type: conversation level events such as session start and end and permission requests and grants
REQ-3 Actor Identification: people, agents and tools as parties
REQ-5 Input/Output Recording: prompts, responses, agent to agent messages and tool invocations and results, with reasoning traces as analysis
REQ-7 Tamper-Evidence and Integrity: integrity of the record itself, signing and encryption
REQ-10 Human Oversight: a reviewable and redactable record of the conversation
REQ-11 Traceability: one vCon with one or more observation points, or separate vCons linked or merged later

The same conversation observed from different points may result in different, duplicate or conflicting data. vCon records observations, it does not reconcile them. Conflicting observations are kept, each attributed to its observer. Any reconciliation can be added as an Analysis. Token usage is partially captured in vCon today, as vendor responses (e.g. from a LLM or transcription service) are often attached as an Analysis and include token counts. A more formal definition of token usage would be useful to contact center as well as agent to agent and audit scenarios. From :

Interaction Records: prompts, responses, approvals, refusals and agent to agent dialog
Action Records: the agent view of a tool invocation, the tool or service side record is another observation point which may go in the same vCon, a linked vCon or a log
Delegation Records: only the structure of which agent delegated to which subagent (i.e. Session and Session_Reference)
Authorization Transition Records: only the parts requested of a person or agent in the conversation

Logging From :

REQ-1, REQ-4 Event Logging and Type: system level events such as configuration and prompt changes and infrastructure events
REQ-2 Timestamp: clock synchronization
REQ-8 Incident Response: queries over logs and vCons
REQ-9 Anomaly and Risk Detection: queries over logs and vCons

From :

Action Records: the tool or service side record, when not put in a vCon

and are examples of logging formats for agents.

Other Solutions From :

REQ-6 Retention Period: storage and policy
REQ-7 Tamper-Evidence and Integrity: non-repudiation and attestation (e.g. and )

From :

Delegation Records: the delegated authority itself (e.g. OAuth tokens and WIMSE)
Authorization Transition Records: token level state changes
propagation of audit context (e.g. trace ID) across domains

Out of Scope

TODO: code provenance
TODO: using vCon to make or enforce decisions during the conversation (e.g. allowing or blocking a tool invocation), as opposed to recording them
TODO: the transport between agents

Gap Analysis The following compares the vCon requirements in with what already provides. The gaps are filled by the strawman extensions in .

REQ-1, REQ-4 Event Logging and Type
- Covered: Session start and duration, join and drop Events
- Gap: permission and directive requests and responses ->
- Gap: policy decisions on whether an operation may be performed ->
REQ-3 Actor Identification
- Covered: Party Object, including type "bot", uuid, did and validation
- Gap: agent attributes such as model, provider, framework, version and workload identity ->
- TODO: is the Party type "bot" sufficient, or are there kinds of agents that need to be distinguished beyond these attributes?
- Gap: tools, which are named resources rather than Parties ->
REQ-5 Input/Output Recording
- Covered: text Dialog for prompts, responses and agent to agent messages
- Gap: structured agent to agent content that is not just text, audio or video ->
- Gap: tool invocations and results ->
- Gap: the tools available to an agent and their definitions ->
- Partial: reasoning traces can be an Analysis today, but there is no Analysis type for them ->
- Partial: token usage is often in an attached vendor response, but is not formally defined ->
REQ-7 Tamper-Evidence and Integrity
- Covered: signed and encrypted forms and content_hash
- Gap: none
REQ-10 Human Oversight
- Covered: redacted and amended
- Gap: none beyond the other gaps listed here
REQ-11 Traceability
- Covered: Session and Session_Reference, including the AI Agent example in the sessions Objects Array section of
- Covered: an observer can be a Party
- Gap: which observer captured which Dialog, Event or Analysis, and where it was in the network ->
- Gap: grouping or linking separate vCons, as Session_Reference only refers to Sessions in the same vCon ->
- Gap: correlation with audit context outside of the vCon ->
General, also applies to contact centers
- Covered: Analysis mediatype, vendor, product and schema
- Gap: no standard media types for the data of common analysis (e.g. transcripts), making it hard to use one analysis as input to another ->

The record types map onto the same gaps. Interaction Records are covered by Dialog and , and the policy decisions which precede them by . The agent view of an Action Record is covered by , the tool or service side by . The structure of Delegation Records is covered by Session and Session_Reference. The conversation parts of Authorization Transition Records are covered by , and the policy decisions by .

Strawman vCon Extensions TODO: one subsection per extension: gap and a sketch. Each of the following is listed as a separate extension. Some could be bundled into a single draft, for example:

AI Agent: and
Tools: and
Analysis Data: , and
Multiple vCons: and , with

Agent Party TODO: model, provider, framework, version and workload identity. TODO: the model may change mid conversation, so it may be a Session or Dialog parameter, with an Event to mark the change. TODO: workload identity (e.g. WIMSE), possibly via the existing did parameter or a new one.

Agent Dialog Content TODO: a new Dialog type, or at least a new media type for Dialog content, for structured agent to agent exchanges (e.g. a JSON container). TODO: tweak the text Dialog definition in , or justify agent messages as transcribable text. TODO: the media type covers a whole record, not a single one directional message, ask for a single entry media type or define one.

Tool Definitions TODO: revisit with more detail.

Tool Invocation Events Defined in draft-petrie-vcon-tool-invocation, with as the first protocol mapped:

Event Object types for each step of a tool invocation, from the request sent to the tool to its result, failure, protocol error, denial by the tool, timeout or cancellation, including pending operations, progress and requests for input from the tool
a policy-decision Event Object type, recording whether an operation is allowed, disallowed or requires permission, for one operation or standing
an operation_id which correlates the policy decision, the attempts of a tool invocation and, in future, permission requests and responses
the server and tool which identify a tool, without the tool definitions themselves (see )

Before an agent performs an operation (e.g. invoking a tool), the agent or its host makes a policy decision whether the operation may be performed. The outcome may be that no permission is needed, that permission is required or that the operation is disallowed. No one is asked, so there is no conversation, only the decision and what it applies to. In some cases it is likely desirable to also capture the reason for the decision (e.g. why the operation was disallowed). The policy decides whether the decision applies to one operation only or is standing. Recording the decision is in scope, making or enforcing it is not (see ).

Permission and Directive Events Permission and directive requests occur within tool invocations (e.g. elicitation), as well as directly in dialog with an AI agent. This covers a request for permission or input to the person or agent on whose behalf the agent is acting, and their response. This is part of the conversation. The response may be more than yes or no (e.g. allow once, allow for the Session, always allow or a choice from a menu). The request is distinct from the policy decision in , and is recorded separately. Only a decision that permission is required is followed by a request. and partially capture this distinction. The requirements identified so far are outlined in draft-petrie-vcon-tool-invocation, including requests passed along a chain of agents, requests which end without an answer, directives no one asked for, answers given out of band and more than one approver. TODO: elicitation (form and URL modes, accept, decline and cancel) as a model. TODO: does not define a message for tool invocation approval, that is left to the host.

Agent Analysis Types TODO: reasoning traces.

Token Usage TODO: supplemental data on the Analysis Object, separate from the analysis content, and on Dialog generated by a LLM. TODO: applies to contact centers as well.

Standard Analysis Media Types TODO: standard media types for the data of common analysis, starting with transcripts. TODO: applies to contact centers as well.

Observer TODO: applies to contact centers as well. TODO: may be mostly a definition of how to use the existing schema (e.g. observer as a Party), rather than new parameters, plus observer location or entity.

Group TODO: a Group Object that refers to zero or more vCons, grouping vCons in a similar way that Session groups Dialog. TODO: the "group" parameter is reserved in the vCon Object Parameter Names Registry in . TODO: different from Observer perspectives, but may need to support them.

Correlation TODO: AUDIT trace ID, parent ID and delegation chain.

Open Issues

TODO: is the Party type "bot" sufficient for agents, or are there kinds of agents to distinguish beyond model, provider, framework, version and workload identity
TODO: where the tool side record of an invocation goes
TODO: Observer as an extension or later in core
TODO: overlap between Agent Analysis Types and Standard Analysis Media Types
TODO: linking, merging and de-duplicating vCons of the same conversation from different observation points, and handling conflicts
TODO: policy decisions for operations other than tool invocations, and whether operation names need a registry

Security Considerations

TODO

Privacy Considerations

TODO

IANA Considerations TBD