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

[tirumal reddy <[e-mail]>]

Hi Orie and Leslie,

On 3GPP: the 6G architecture study (TR 23.801-01 v0.9.0) describes agent
patterns that map to draft-agentic-ai-usecases-requirements:

   - Gateways and intermediaries map to the mediator use case: a gateway
   through which third-party agents use the network (clause 6.18.5), a gateway
   through which network agents use third-party tools and services (clause
   6.18.18), and an intermediary that translates and authorizes tool
   invocations (clause 6.18.16).
   - Planning and execution agents (clause 6.18.16) map to the orchestrator
   use case.
   - Coordination between visited and home network agents (clause 6.18.8)
   maps to cross-domain delegation.
   - Suspending, updating, and resuming a task (clause 6.18.16) maps to the
   dialog lifecycle (CMN-11).

We are closely following the work in 3GPP and will address any gaps as it
progresses.  We welcome input on any 3GPP requirements the draft has
missed.

Cheers,
-Tiru

On Mon, 12 Oct 2026 at 20:35, Orie <[e-mail]> wrote:

> 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]
>>> > >>>
>>> > >>
>>> >
>>>
>>