[Agentproto] Re: 回复：Re: Discussion topics

[Lionel Morand <[e-mail]>]

Hi Dapeng,

+1

As highlighted below, the most relevant part for this WG is: "Multiple AI agents across multiple agentic dialogs might be involved in the satisfaction of an initial user request (e.g., ‘book me a vacation’ spawns a research agent, a flight reservation agent and a hotel selection agent), requiring transmission of correlation identifiers to tie these dialogs together"[1].

A communication session would typically start from the initial user request and finish with the related explicit final answer (for simplification here). Multiple agents/tools may be involved to fulfil the request. Each communication (dialog) between agents/tools to fulfil the user request (or part of it) would be identified by a specific dialog identifier. All the communications related to a the same request would be identified by a correlation id (if context is too sensitive here 😊), especially useful in pause/resume or retransmission operations. And the management of these ids needs to be deterministic and consistent across domains.

Regards,

Lionel

From: 刘大鹏(鹏成) <max.ldp=[e-mail]>
Sent: mardi 1 septembre 2026 12:29
To: Leslie Daigle (ThinkingCat) <ldaigle=[e-mail]>; Leslie Daigle (ThinkingCat) <ldaigle=[e-mail]>
Cc: [e-mail]; agentproto-chairs <[e-mail]>
Subject: [Agentproto] 回复：Re: Discussion topics

Hi all,

Following up on Leslie's question, I'd like to respond by summarizing the key points from Jonathan's rewrite of the charter [1] and from the meeting chat [2].
I think these capture where much of the room converged, including Ted's, Brian's and Cullen's comments, and proposing it as a strawman is the fastest way to find out whether the list can reach consensus around this direction.

1. What are the concrete interoperability problems created by dynamic, multi-party, cross-domain and multimodal agent interactions

1) A long-lived task delegated across an administrative boundary. A task initiated on behalf of a principal is delegated from one party to another, in a different domain. The task may live for hours or days; it can be paused and resumed, and the machine doing the work on one side may change while the task continues: as Jonathan's rewrite says, "an AI agent running on one host may start a dialog with a downstream AI agent, and after that host crashes, it can be resumed from a different host in the same cluster with no loss of context."[1] Every participant must be able to recognize "this is the same ongoing task." Today there is no standard way to express that across boundaries.

2) "Multiple AI agents across multiple agentic dialogs might be involved in the satisfaction of an initial user request (e.g., ‘book me a vacation’ spawns a research agent, a flight reservation agent and a hotel selection agent), requiring transmission of correlation identifiers to tie these dialogs together"[1]. Today there is no standard way to bind and verify that tie across domains.

Such interactions are not limited to text: as raised in the chat, they involve voice, video, streaming output, etc., and carrying such multi-modal data across trust boundaries needs the same correlation handling as the scenarios above [2].
Jonathan's rewrite calls this "agentic dialog management" [1].

2. Can we identify the minimum context-propagation/session-management primitives that are genuinely missing from existing IETF and other AI agent work and develop those primitives through concrete use cases and prototypes.

Here are some primitives:
1) A mechanism for each interaction, consisting of an identifier bound to an envelope that proves the binding, carried with the interaction. As Ted said in the room chat, "an identifier alone is not enough (too easy to fake), but that plus some envelope that proves that the identifier was bound to the context is probably good."[2]
2) Lifecycle operations: start, end, pause, resume, and migration of multi-modal data across hosts [1]. These require binding to existing IETF transport standards such as MoQ. This also justifies why this work should be done by IETF.
3) Correlation: a way to link separate interactions to each other and back to their common origin, so the whole set can be tracked, cancelled or completed as one.
These can be validated through concrete use cases and prototypes.

On authorization, as Ted said in the room chat, "propagating a state token that says 'This is related to mission X' is different from the token which authorizes that recipient to do Foo. I agree that if you made those the same you would get very bad results. But I see no reason for you to do that; the protocols bound into to the common mission still need to pass authorization" [2]. This direction keeps the two strictly apart and authorization continues to pass through existing mechanisms.

Everything else reuses existing IETF transport and security protocols rather than redefining them. The protocol itself would not be AI agent-specific and it applies to any use case sharing these requirements.

So my question to the list is: can we reach consensus on this direction as the basis for reworking the charter?


Thanks,
Dapeng

[1] Jonathan's re-write: https://github.com/jdrosen/aiproto-wg/pull/48
[2] Meeting chat: https://zulip.ietf.org/#narrow/channel/432-agentproto

------------------原始邮件 ------------------
发件人:Leslie Daigle (ThinkingCat) <ldaigle=[e-mail]<mailto:ldaigle=[e-mail]>>
发送时间:Sat Aug 29 03:54:06 2026
收件人:Leslie Daigle (ThinkingCat) <ldaigle=[e-mail]<mailto:ldaigle=[e-mail]>>
抄送:[e-mail] <[e-mail]<mailto:[e-mail]>>, agentproto-chairs <[e-mail]<mailto:[e-mail]>>
主题:[Agentproto] Re: Discussion topics

All — following up the Discussion Topics thread, I wanted to put a sharper focus on where we had momentum coming out of the IETF 126 AGENTPROTO BoF meeting (minutes are here [0] ). Specifically, there was momentum in the room to do something with this work, and the key areas needing clarification were in the problem statement (the session poll results [1] show strong support in question 1, but also significant disagreement), and that the scope needed to be changed.

In the room, on the day, the direction of scoping seemed best expressed by Ted Hardie, Brian Trammell and Jonathan Rosenberg — see a transcript quote from Ted Hardie at [2].

We need to keep that direction, and level of detail, in mind as we work through:

With that, can we focus on:

  *   what are the concrete interoperability problems created by dynamic, multi-party, cross-domain and multimodal agent interactions;
  *   can we identify the minimum context-propagation/session-management primitives that are genuinely missing from existing IETF and other AI agent work and develop those primitives through concrete use cases and prototypes.

Leslie.

[0] https://datatracker.ietf.org/meeting/126/materials/minutes-126-agentproto-202607230700-01

[1]Poll results, as captured in the IETF 126 AGENTPROTO BoF:

Do you think that the problem statement is well-understood, solvable, and useful to solve?
Yes: 124, No: 72, No_opinion: 14 (Total: 320)
Is the need for interoperability clear?
Yes: 155, No: 30, No_opinion: 8 (Total: 318)
Do you think the IETF is the right place to do this work?
Yes: 158, No: 30, No_opinion: 14 (Total: 315)
Do you think the initial scope from the charter we just discussed is correct?
Yes: 38, No: 124, No_opinion: 40 (Total: 316)
Do you think the initial deliverables from the charter we just discussed are correct?
Yes: 92, No: 58, No_opinion: 49 (Total: 316)
Do you think a WG should be formed on this topic, with a charter based on the draft charter we just discussed?
Yes: 154, No: 51, No_opinion: 5 (Total: 316)
Are you willing to help write and/or review drafts in this potential WG?
Yes: 137, No: 17, No_opinion: 40 (Total: 317)
Are you willing/planning to implement the protocols of the eventual WG?
Yes: 42, No: 28, No_opinion: 40 (Total: 314)

[2] Excerpt from IETF 126 AGENTPROTO BoF Transcript:

[Ted Hardie:]
I think it was a very important description of the problem space because I think he was describing this not in terms actually of a session layer, but in terms of a context which needs to be propagated. And that context needs to be propagated in a multiparty way across trust boundaries and across modalities. That's a pretty complicated thing, but it is actually a tractable problem. And I think what we are looking for in a charter is a way of describing that that says what this working group will do is enable a signaling protocol that will allow the setup and management of context propagation through these trust roundies in a multimodal way for these multiparties. And I keep coming back to multi party because of something very important Jonathan Rosenberg said in chat. When we have done session initiation in the past, we have typically focused on endpoints. SIP allows this call to go from this place to that place, WebRTC from this browser to that browser. In this case, we are actually going to need multi party because you're going to want to be able to move the context with the party as they move from one device to another or over time. So I think looking at the charter, I would reframe this as context propagation, and I would particularly bring the framework up to doing that first. The way this is written right now, the charter has those two items moving in parallel, the development of the technical work and the development of the framework. And I think it would really help the rest of the industry, particularly the folks working on MCP or A2A, to understand how this differs from what they do if they see it as a signaling protocol for this context propagation rather than necessarily a replacement for the actual communication protocols that are already in play. Overall, I I feel this BOF has been really helpful for me to understand what the work the ITF could take on here is. And with the kind of tremendous second thing going on in the chat, as usual, I actually think that this is something that we could tackle and do well.

On 22 Aug 2026, at 16:26, Leslie Daigle (ThinkingCat) wrote:

Hi,

At the IETF 126 meeting of AGENTPROTO (see [0]), we had considerable momentum on some aspects of the proposed charter for a WG (with some noted concerns about other areas). We’d like to continue with the momentum here, to work the charter into good shape for an IETF WG.

At IETF 126, the room seemed reasonably aligned around a concrete interoperability/context-propagation problem (more than around building an overarching framework). We haven’t quite gotten crisp with the terminology or specific need here.

With that, can we focus on:

  *   what are the concrete interoperability problems created by dynamic, multi-party, cross-domain and multimodal agent interactions;
  *   can we identify the minimum context-propagation/session-management primitives that are genuinely missing from existing IETF and other AI agent work and develop those primitives through concrete use cases and prototypes.

We’ll focus on those higher level questions for now, and return to the charter text [1] discussion after we have a clearer signal from the mailing list on these issues.

Regards,

Chairs — Leslie & Orie.

[0] Meeting materials, including minutes: https://datatracker.ietf.org/meeting/126/session/agentproto

[1] Current charter draft https://github.com/ietf-artarea/charters/blob/main/agentproto/charter.md

--

________________________________
Leslie Daigle
Principal, ThinkingCat Enterprises
[e-mail]<mailto:[e-mail]>
________________________________

Agentproto mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

--

________________________________
Leslie Daigle
Principal, ThinkingCat Enterprises
[e-mail]<mailto:[e-mail]>