[Agentproto] Re: Topic: Existing practice, use cases, and deployment models

[Orie <[e-mail]>]

Hi all,

Thanks for the contributions. Our goal for this topic is to identify
candidate starting points for the Use Cases and Requirements document.

The discussion has identified two drafts for consideration:

- draft-rosenberg-agentproto-usecases-00
- draft-agentic-ai-usecases-requirements-03

Thanks to the authors and reviewers for the recent updates to the latter
draft and the proposed follow-up revisions addressing recovery and
authorization.
We have useful contributions toward a working group document, but have not
yet established which draft should be its starting point.

We would also welcome more input on telecom and 3GPP use cases.
Please identify relevant drafts and sections, including updates to
draft-stephan-ai-agent-6g and draft-ly-multi-agent-in6g, and explain what
they would add to either candidate.

Please comment on whether either draft provides a suitable starting point
for adoption, what essential material is missing, or whether another draft
should be considered.

Regards,

Orie and Leslie
agentproto co-chairs

On Mon, Oct 12, 2026 at 2:01 AM tirumal reddy <[e-mail]> wrote:

> Hi Girish, Iman, Nicholas, Bradley,
>
> Thanks. For -04 I propose the following.
>
> Resumption, split in two:
>
>   B1-7: On resumption, the protocol is required to enable the receiving
>   participant to verify that (1) the party resuming the dialog is the
>   participant whose exchange was interrupted, (2) the dialog context
>   presented is the current state of that dialog, and (3) the dialog has
>   not been terminated and its authorization has not been revoked.
>
>   B1-8: If any check in B1-7 fails or cannot be completed, the dialog
>   is not resumed and the protocol is required to signal the reason.
>
> Authorization for any change to a dialog, as a common requirement:
>
>   CMN-12: Before accepting a change to a dialog, a participant is
>   required to be able to verify that the change is authorized at that
>   time. If it cannot verify this, it is required to reject the change
>   and signal the reason.
>
> Operations in progress at an interruption, as text in Section 4.2:
>
> If a dialog is interrupted before the result of an operation reaches the
> delegating agent, the
> operation may or may not have completed. Resuming the dialog does not tell
> the delegating
> agent which. Before resending the operation, the delegating agent checks
> its outcome with
> the delegated agent or tool that performed it.
>
> Cheers,
> -Tiru
>
> On Sun, 11 Oct 2026 at 05:55, Iman Schrock <[e-mail]> wrote:
>
>> Hi Girish,
>>
>> Yes, both additions capture what I meant. Thank you for writing them up.
>>
>> The deciding participant needs to know before admission that a
>> required input couldn't be established. Recording that only afterward
>> doesn't close the gap.
>>
>> Tiru, could we carry these into the requirements text? The
>> unresolved-operation case also fits mediator recovery under B5-2. The
>> participant can retain operation state locally, with retry guarantees
>> remaining with the tool or provider.
>>
>> Best,
>> Iman
>>
>> On Sat, 10 Oct 2026 16:35:36 -0700, Girish Konda <[e-mail]>
>> wrote:
>> > Hey Folks,
>> >
>> > I've read draft-agentic-ai-usecases-requirements-03
>> > <
>> https://datatracker.ietf.org/doc/html/draft-agentic-ai-usecases-requirements-03
>> >,
>> > and the resumption checks in B1-7 look good. Iman, here are the two
>> > additions I offered to write up.
>> >
>> >    1. *Unresolved Downstream Operations:* "On resumption, the task
>> >    preserves the identity and unresolved status of a downstream
>> operation
>> >    until its outcome can be established. Resuming the dialog does not by
>> >    itself justify submitting that operation again." Restoring dialog
>> context
>> >    isn't evidence that the earlier operation didn't happen. This doesn't
>> >    require carrying task context in the protocol.
>> >    2. *Unavailable Authorization Inputs:* "If a required authorization
>> >    input cannot be established, the deciding participant accounts for
>> that
>> >    fact in its admission decision under local policy. The protocol
>> makes that
>> >    state available before admission, directly or by reference,
>> separately from
>> >    an evaluated refusal, even when both lead to denial."
>> >
>> > Section 8 of my draft-konda-agentproto-evaluation-state-01
>> > <
>> https://datatracker.ietf.org/doc/html/draft-konda-agentproto-evaluation-state-01#section-8
>> >
>> > maps these cases to B1-6/B1-7. Doug, Lars, we should keep the
>> > authorization-context carry-or-reference requirement alongside this,
>> > including what happens when a reference can't be resolved in time or
>> > returns stale state.
>> >
>> > Thanks,
>> > Girish
>> >
>> > On Fri, Oct 9, 2026 at 11:36 PM tirumal reddy <[e-mail]>
>> wrote:
>> >
>> > > Hi Nikhil,
>> > >
>> > > Most of this is now covered in
>> > > draft-agentic-ai-usecases-requirements, updated to align with the
>> charter:
>> > > https://github.com/tireddy2/agentic-ai-ucreq2/pull/72
>> > >
>> > > - Resumption after network interruption or change: B1-6
>> > > - On resumption, checking that the dialog has not been terminated or
>> its
>> > > authorization revoked, so continuity does not imply continued
>> > > authorization: B1-7
>> > > - Correlation across hops: B3-13
>> > > - Recovery after intermediary failure: B5-2
>> > > - Identifier linkability across domains: Security Considerations
>> > >
>> > > The draft notes the linkability risk of identifiers shared across
>> domains
>> > > in Security Considerations.
>> > > Comments on the text are welcome.
>> > >
>> > > -Tiru
>> > >
>> > > On Fri, 9 Oct 2026 at 16:47, Nikhil D <[e-mail]>
>> wrote:
>> > >
>> > >> Dear Orie, Leslie, and colleagues,
>> > >>
>> > >>
>> > >> Following my earlier note on dialog continuity across multiple
>> agents and
>> > >> trust boundaries, I have worked on a more detailed use case that I
>> would
>> > >> like to share for discussion.
>> > >>
>> > >> *Proposed use case: Privacy-Preserving Dialog Resumption Across
>> > >> Administrative Trust Boundaries*
>> > >>
>> > >> Consider an enterprise AI agent that receives a task from a user and
>> > >> delegates part of it to an agent operated by another organization.
>> The
>> > >> second agent may use external tools to complete its work.
>> > >>
>> > >>
>> > >> Now suppose the task is interrupted because of a network failure or
>> > >> gateway restart. When communication resumes, the agents need to
>> identify
>> > >> the original dialog and continue from the appropriate state.
>> > >>
>> > >>
>> > >> The concern I see is that sharing the same persistent dialog
>> identifier
>> > >> across organizations could allow participants to correlate
>> interactions
>> > >> beyond what is necessary for the task. At the same time, removing or
>> > >> changing identifiers without a reliable mapping could break dialog
>> > >> continuity.
>> > >>
>> > >>
>> > >> *Interoperability gap*
>> > >>
>> > >> Existing agent communication mechanisms may support task
>> identification
>> > >> and status recovery, but it is worth examining whether interoperable
>> dialog
>> > >> resumption can be achieved across administrative boundaries without
>> > >> requiring every participant to use the same globally visible
>> identifier.
>> > >>
>> > >> *Candidate requirements*
>> > >>
>> > >> I suggest considering the following:
>> > >>
>> > >>    1. Participants should be able to resume an existing dialog using
>> the
>> > >>    minimum correlation information necessary.
>> > >>    2. Dialog identifiers should be scoped appropriately when
>> information
>> > >>    crosses administrative trust boundaries.
>> > >>    3. The protocol should support recovery after intermediary
>> failures
>> > >>    without incorrectly associating unrelated dialogs.
>> > >>    4. Participants should be able to distinguish dialog continuity
>> from
>> > >>    authorization to continue performing delegated actions.
>> > >>    5. The system should define how to handle missing, stale, or
>> invalid
>> > >>    correlation information during resumption.
>> > >>
>> > >> *Failure cases worth examining*
>> > >>
>> > >> A few situations may help evaluate these requirements:
>> > >>
>> > >>    - An intermediary restarts and loses its local dialog mapping.
>> > >>    - A participant receives an outdated correlation reference.
>> > >>    - A dialog resumes after delegated authorization has expired or
>> been
>> > >>    revoked.
>> > >>    - Two unrelated dialogs are incorrectly associated during
>> recovery.
>> > >>    - A downstream participant receives more correlation information
>> than
>>
>> > >>    its role requires.
>> > >>
>> > >> I see this as a possible extension to the dialog lifecycle
>> discussion in
>> > >> Section 3.3.3 of draft-rosenberg-agentproto-usecases-00, with related
>> > >> privacy and authorization considerations.
>> > >>
>> > >>
>> > >> My intention is not to introduce a new authorization mechanism, but
>> to
>> > >> identify what dialog-management information is needed for safe and
>> > >> interoperable resumption.
>> > >>
>> > >> I would appreciate feedback on whether this use case would be useful
>> for
>> > >> the Use Cases and Requirements document. I would also be happy to
>> refine
>> > >> the technical text based on the group's comments.
>> > >>
>> > >>
>> > >> Best regards,
>> > >>
>> > >>
>> > >> Nikhil Reddy Donapati
>> > >> Software Engineer
>> > >> NeuroNet Solutions Inc.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Thu, 8 Oct 2026 at 17:56, Iman Schrock <team=
>> > >> [e-mail]> wrote:
>> > >>
>> > >>> Hi Girish,
>> > >>>
>> > >>> Yes, please carry both into the revision. Keeping the resubmission
>> > >>> restraint as its own sentence makes the distinction clearer.
>> > >>>
>> > >>> You're also right about the decision itself. If a required
>> > >>> authorization input cannot be established, that has to affect
>> > >>> admission, not just leave a note afterward. It should remain
>> > >>> distinguishable from an evaluated refusal, even when both lead to
>> > >>> local denial.
>> > >>>
>> > >>> Thank you for offering to write this up.
>> > >>>
>> > >>> Best,
>> > >>> Iman
>> > >>>
>> > >>> On Wed, 7 Oct 2026 12:49:08 -0700, Girish Konda <
>> [e-mail]>
>> > >>> wrote:
>> > >>> > Hey Iman,
>> > >>> >
>> > >>> > Thanks for the write up. A couple of comments on the two bullets.
>> The
>> > >>> split
>> > >>> > keeps retrying an evaluation separate from repeating an operation
>> with
>> > >>> side
>> > >>> > effects, which is the distinction that matters at the tool
>> boundary.
>> > >>> >
>> > >>> >    1. *Submission Is Not Resubmission:* Your 3.3.3 wording says
>> > >>> resuming
>> > >>> >    the dialog doesn’t by itself justify submitting the operation
>> > >>> again. I’d
>> > >>> >    keep that as its own sentence. The preservation is a state
>> > >>> requirement and
>> > >>> >    the restraint is a behavioural one, and they won’t always be
>> read
>> > >>> together.
>> > >>> >    2. *Availability to the Decision, Not Only the Record:* 3.3.5
>> says
>> > >>> >    preserve that fact separately from an evaluated refusal.
>> Preserving
>> > >>> it in
>> > >>> >    the record is the audit half. Douglas Wadkins’s three-part
>> split on
>> > >>> the
>> > >>> >    charter thread has the same distinction reaching the admission
>> > >>> decision,
>> > >>> >    since otherwise "could not establish" becomes a field without
>> > >>> becoming an
>> > >>> >    input.
>> > >>> >
>> > >>> > I’m happy to write both up for whichever revision takes them.
>> > >>> >
>> > >>> > Thanks,
>> > >>> > Girish
>> > >>>
>> > >>> On Wed, 07 Oct 2026 12:49:08 -0700, Girish Konda <
>> [e-mail]>
>> > >>> wrote:
>> > >>> > Hey Iman,
>> > >>> >
>> > >>> > Thanks for the write up. A couple of comments on the two bullets.
>> The
>> > >>> split
>> > >>> > keeps retrying an evaluation separate from repeating an operation
>> with
>> > >>> side
>> > >>> > effects, which is the distinction that matters at the tool
>> boundary.
>> > >>> >
>> > >>> >    1. *Submission Is Not Resubmission:* Your 3.3.3 wording says
>> > >>> resuming
>> > >>> >    the dialog doesn’t by itself justify submitting the operation
>> > >>> again. I’d
>> > >>> >    keep that as its own sentence. The preservation is a state
>> > >>> requirement and
>> > >>> >    the restraint is a behavioural one, and they won’t always be
>> read
>> > >>> together.
>> > >>> >    2. *Availability to the Decision, Not Only the Record:* 3.3.5
>> says
>> > >>>
>> > >>> >    preserve that fact separately from an evaluated refusal.
>> Preserving
>> > >>> it in
>> > >>> >    the record is the audit half. Douglas Wadkins’s three-part
>> split on
>> > >>> the
>> > >>> >    charter thread has the same distinction reaching the admission
>> > >>> decision,
>> > >>> >    since otherwise "could not establish" becomes a field without
>> > >>> becoming an
>> > >>> >    input.
>> > >>> >
>> > >>> > I’m happy to write both up for whichever revision takes them.
>> > >>> >
>> > >>> > Thanks,
>> > >>> > Girish
>> > >>> >
>> > >>> > On Mon, Oct 5, 2026 at 7:21 AM Iman Schrock <
>> [e-mail]>
>> > >>> wrote:
>> > >>> >
>> > >>> > > Hi Girish,
>> > >>> > >
>> > >>> > > I’d use two linked bullets, following the split already in
>> Section 8
>> > >>> > > of your draft:
>> > >>> > >
>> > >>> > > 3.3.3: “On resumption, the task preserves the identity and
>> unresolved
>> > >>> > > status of a downstream operation until its outcome can be
>> > >>> established.
>> > >>> > > Resuming the dialog does not by itself justify submitting that
>> > >>> > > operation again.”
>> > >>> > >
>> > >>> > > 3.3.5: “If a required authorization input cannot be established,
>> > >>> > > preserve that fact separately from an evaluated refusal, even
>> when
>> > >>> > > both lead to local denial.”
>> > >>> > >
>> > >>> > > That keeps retrying an evaluation or status query separate from
>> > >>> > > repeating an operation with side effects. The tool or provider
>> still
>> > >>> > > supplies the retry guarantees.
>> > >>> > >
>> > >>> > > Best,
>> > >>> > > Iman
>> > >>> > >
>> > >>> > >
>> > >>> > > On Mon, 05 Oct 2026 02:41:00 -0700, Girish Konda <
>> > >>> [e-mail]>
>> > >>> > > wrote:
>> > >>> > > > Hey Folks,
>> > >>> > > >
>> > >>> > > > A couple of comments on the Topic 1 input set and I agree
>> with the
>> > >>> shape
>> > >>> > > of
>> > >>> > > > the replies so far. Iman's response-loss case fits 3.3.3,
>> Henri's
>> > >>> MCP
>> > >>> > > proxy
>> > >>> > > > model is a useful deployment point, and Nikhil's continuity
>> note
>> > >>> belongs
>> > >>> > > > with the dialog lifecycle. Lars has a candidate for the 3.3.5
>> > >>> grant gap
>> > >>> > > and
>> > >>> > > > Sumit has the cross-domain policy gap in 3.3.2.
>> > >>> > > >
>> > >>> > > > I don't think the missing piece is another authorization
>> artifact
>> > >>> yet.
>> > >>> > > It's
>> > >>> > > > an operational state the architecture has to preserve when
>> any of
>> > >>> those
>> > >>> > > > artifacts cannot be evaluated. An unestablished input is a
>> > >>> different fact
>> > >>> > > > from a negative one, and collapsing them changes retry,
>> ownership
>> > >>> and
>> > >>> > > > blast-radius accounting. I've written it up as
>> > >>> > > > draft-konda-agentproto-evaluation-state-00,
>> > >>> > > >
>> > >>> > >
>> > >>>
>> https://datatracker.ietf.org/doc/draft-konda-agentproto-evaluation-state/
>> > >>> .
>> > >>> > > >
>> > >>> > > > We should settle which of 3.3.3 and 3.3.5 carries the
>> > >>> unestablished-input
>> > >>> > > > case, and I'm happy to write the bullet for whichever section
>> it
>> > >>> lands
>> > >>> > > in.
>> > >>> > > >
>> > >>> > > > Thanks,
>> > >>> > > > Girish
>> > >>> > > >
>> > >>> > > > On Sat, Oct 3, 2026 at 11:01 PM tirumal reddy <
>> [e-mail]>
>> > >>> wrote:
>> > >>> > > >
>> > >>> > > > > Hi,
>> > >>> > > > >
>> > >>> > > > > "Agentic AI Use Cases and Requirements" draft
>> > >>> > > > >
>> > >>> > >
>> > >>>
>> https://datatracker.ietf.org/doc/draft-agentic-ai-usecases-requirements/
>> > >>> > > derives
>> > >>> > > > > session (dialog) management, transport and security
>> requirements
>> > >>> from
>> > >>> > > use
>> > >>> > > > > cases reflected in A2A, MCP and deployed multi-agent
>> frameworks.
>> > >>> > > > >
>> > >>> > > > > Candidate use cases (Section 4) are:
>> > >>> > > > >
>> > >>> > > > > a) Single agent invoking tools across domains
>> > >>> > > > > b) Orchestrator delegation
>> > >>> > > > > c) Long-running delegated task
>> > >>> > > > > d) Multi-hop peer delegation
>> > >>> > > > > e) Group consensus
>> > >>> > > > > f) Mediator between agents and tools, including translation
>> to
>> > >>> MCP and
>> > >>> > > A2A
>> > >>> > > > >
>> > >>> > > > > The use cases are deployment-agnostic, so no
>> deployment-specific
>> > >>> use
>> > >>> > > cases
>> > >>> > > > > are included. Each use case lists its session (dialog)
>> > >>> management,
>> > >>> > > > > transport and security requirements; common requirements
>> are in
>> > >>> > > Section 3.
>> > >>> > > > >
>> > >>> > > > > Thanks,
>> > >>> > > > > -Tiru
>> > >>> > > > >
>> > >>> > > > > On Fri, 2 Oct 2026 at 22:40, Orie <[e-mail]> wrote:
>> > >>> > > > >
>> > >>> > > > >> Hi,
>> > >>> > > > >>
>> > >>> > > > >> This is the first in a series of topics, as noted here:
>> > >>> > > > >>
>> > >>> > > > >>
>> > >>> > > > >>
>> > >>> > >
>> > >>>
>> https://mailarchive.ietf.org/arch/msg/agentproto/3_WBraJwt-jwDpZYb3uUoCRMrA0/
>> > >>> > > > >>
>> > >>> > > > >> Please identify Internet-Drafts describing existing
>> systems,
>> > >>> > > protocols,
>> > >>> > > > >> use cases, or deployment models relevant to agentproto.
>> > >>> > > > >>
>> > >>> > > > >> Point to the sections that explain how users, agents, and
>> tools
>> > >>> > > interact,
>> > >>> > > > >> what works today, and where interoperability gaps arise.
>> > >>> > > Implementation and
>> > >>> > > > >> deployment experience will help us assess these
>> contributions.
>> > >>> > > > >>
>> > >>> > > > >> The expected output is a set of candidate use cases,
>> deployment
>> > >>> > > models,
>> > >>> > > > >> and supporting references for **Use Cases and
>> Requirements**,
>> > >>> > > together with
>> > >>> > > > >> deployment assumptions for the **Reference Architecture**.
>> > >>> > > > >>
>> > >>> > > > >> Regards,
>> > >>> > > > >>
>> > >>> > > > >> Orie and Leslie
>> > >>> > > > >> agentproto co-chairs
>> > >>> > > > >>
>> > >>> > > > >> _______________________________________________
>> > >>> > > > >> Agentproto mailing list -- [e-mail]
>> > >>> > > > >> To unsubscribe send an email to [e-mail]
>> > >>> > > > >>
>> > >>> > > > > _______________________________________________
>> > >>> > > > > Agentproto mailing list -- [e-mail]
>> > >>> > > > > To unsubscribe send an email to [e-mail]
>> > >>> > > > >
>> > >>> > >
>> > >>> _______________________________________________
>> > >>> Agentproto mailing list -- [e-mail]
>> > >>> To unsubscribe send an email to [e-mail]
>> > >>>
>> > >>
>> >
>>
>