Internet-Draft Agentic AI Use Cases February 2026
Schott, et al. Expires 1 September 2026 [Page]
Workgroup:
WG Working Group
Internet-Draft:
draft-scrm-aiproto-usecases-latest
Published:
Intended Status:
Informational
Expires:
Authors:
R. Schott
Deutsche Telekom
J. Maisonneuve
Nokia Bell Labs
L. M. Contreras
Telefonica
J. Ros-Giralt
Qualcomm Europe, Inc.

Agentic AI Use Cases

Abstract

TODO Abstract

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-scrm-aiproto-usecases/.

Source for this draft and an issue tracker can be found at https://github.com/https://github.com/giralt/draft-scrm-aiproto-usecases.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 1 September 2026.

▲

Table of Contents

1. Introduction

Agentic AI systems—software agents that use large language models to reason, plan, and take actions by interacting with tools and with other agents—are seeing rapid adoption across multiple domains. The ecosystem is also evolving quickly through open-source implementations and emerging protocol proposals; however, open source alone does not guarantee interoperability, since rapid iteration and fragmentation can make stable interoperation difficult when long-term compatibility is required. Several protocols have been proposed to support agentic systems (e.g., [A2A], [MCP], ANP, Agntcy), each with different design choices and strengths, targeting different functions, properties, and operating assumptions.

This document inventories a set of representative Agentic AI use cases to help the IETF derive protocol requirements and perform gap analysis across existing proposals, with a focus on Internet-scale interoperability. The use cases are intended to highlight protocol properties that matter in practice—such as long-lived interactions, multi-modal context exchange, progress reporting and cancellation, and safety-relevant security and privacy hooks—and to help the IETF determine appropriate scope as well as how related work should be organized across existing working groups or, if needed, a new effort.

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Use Cases Requirements

The use cases in this document are intended to inform IETF standardization work on Agentic AI protocols by clarifying scope, enabling gap analysis, and guiding working group ownership. The requirements below define the minimum level of detail and structure expected from each use case so that the IETF can derive actionable protocol requirements and identify where coordination with other SDOs is necessary. Use cases that do not meet these requirements risk being insufficiently precise for protocol design and evaluation.

4. Use Cases

4.2. Hybrid AI

Hybrid AI generally refers to an edge–cloud cooperative inference workflow in which two or more models collaborate to solve a task: (1) a smaller on‑device model (typically a few billion parameters) that prioritizes low latency, lower cost, and privacy; and (2) a larger cloud model (hundreds of billions to trillion‑scale parameters) that offers higher capability and broader knowledge. The two models coordinate over an agent‑to‑agent channel and may invoke tools locally or remotely as needed. Unlike single‑endpoint inference, Hybrid AI is adaptive and budget‑aware: the on‑device model handles as much work as possible locally (classification, summarization, intent detection, light reasoning), and escalates to the cloud model when additional capability is required (multi‑hop reasoning, long‑context synthesis, domain expertise). The models can exchange plans, partial results, and constraints over [A2A], and both sides can discover and invoke tools via [MCP].

4.2.1. Building Blocks

A Hybrid AI workflow may generally comprise the components shown in the next Figure:

  • On‑device Model (Edge). A compact LLM or task‑specific model (a few billion parameters) running on user hardware (e.g., phone, laptop). Advantages include: low latency for interactive turns, reduced cost, offline operation, and improved privacy by default (data locality). Typical functions: intent parsing, entity extraction, local retrieval, preliminary analysis, redaction/summarization prior to escalation.

  • Cloud Model (Hosted). A large, higher‑capability LLM (hundreds of billions to ~trillion parameters) with stronger reasoning, knowledge coverage, tool‑use proficiency, and longer context windows. Typical functions: complex synthesis, multi‑step reasoning, broad web/KG retrieval, code execution, and advanced evaluation.

  • A2A Inter‑Model Coordination. The edge and cloud models communicate via an Agent‑to‑Agent channel to exchange capabilities, cost/latency budgets, privacy constraints, task state, and partial artifacts. Common patterns include negotiate‑and‑delegate, ask‑for‑help with evidence, propose/accept plan updates, and critique‑revise cycles [A2A].

  • MCP Tooling (Edge and Cloud). Both models use the Model Context Protocol to discover and invoke tools with consistent schemas (e.g., local sensors/files, calculators, vector indexes on edge; search/crawling, KB/RAG, Python/services in cloud). MCP enables capability discovery, streaming/progress, cancellation, and explicit consent prompts across transports [MCP].

  • Policy, Budget, and Privacy Controls. Guardrails and policies that encode user/enterprise constraints (e.g., do not send raw PII to cloud; enforce token/time budgets; require consent for specific tools). The edge model may redact or summarize data before escalation; both sides log provenance and decisions for auditability.

  • Shared Task State and Provenance. A compact state (goals, sub‑tasks, citations, hashes, timestamps) that both models can read/update to enable reproducibility, debugging, and verifiable traces.

+--------------------------------------------------------------+
|                        User / Client                         |
|              (Goal, Query, Constraints)                      |
+--------------------------------------------------------------+
                             |
                             v
+--------------------------------------------------------------+
|                 On-Device Model (Edge)                       |
|  - few-B params; low latency, privacy by default             |
|  - local reasoning, redaction/summarization                  |
|  - local tools via MCP (sensors, files, crypto)              |
+--------------------------------------------------------------+
         |                           \
         | local MCP tools            \ when escalation is needed
         v                             \
+----------------------+                \
| Edge MCP Tools       |                 \
+----------------------+                  v
                                   +----------------------------------+
                                   |   A2A Session (Edge <-> Cloud)   |
                                   |   - capability/budget exchange   |
                                   |   - task handoff & updates       |
                                   +----------------------------------+
                                                |
                                                v
+--------------------------------------------------------------+
|                    Cloud Model (Hosted)                      |
|  - 100B–1T+ params; higher capability & breadth              |
|  - complex synthesis, long-context reasoning                 |
|  - cloud tools via MCP (search, KB/RAG, Python)              |
+--------------------------------------------------------------+
                             |
                     cloud MCP tool calls
                             v
+----------------------+   +------------------+   +------------------+
| Web Search & Crawl   |-->| KB / RAG Index   |-->| Python / Services|
+----------------------+   +------------------+   +------------------+
                             ^
                             |
                 results/evidence via A2A to edge/cloud
                             |
                             v
+--------------------------------------------------------------+
|                 Final Answer / Output                        |
|   (synthesis + citations + privacy/consent notes)            |
+--------------------------------------------------------------+

Each building block in the Hybrid AI architecture represents a logical function rather than a specific implementation, and components may be co‑located or distributed in practice.

4.2.2. Interaction Model

A typical Hybrid AI session proceeds as follows:

  1. Local First. The on‑device model interprets the user goal, applies local tools (e.g., retrieve snippets, parse files), and attempts a low‑cost solution within configured budgets.

  2. Escalate with Minimization. If the local model estimates insufficient capability (e.g., confidence below threshold, missing evidence), it redacts/summarizes sensitive data and escalates the task—along with compact evidence and constraints—over [A2A].

  3. Cloud Reasoning + Tools. The cloud model performs deeper reasoning and may invoke [MCP] tools (web search/crawl, KB/RAG, Python) to gather evidence and compute results.

  4. Refine & Return. Intermediate artifacts and rationales flow back over [A2A]. The edge model may integrate results, perform final checks, and produce the user‑facing output.

  5. Iterate as Needed. The models repeat plan‑act‑observe‑refine until success criteria (quality, coverage, cost/time budget) are met.

4.2.3. Why This Use Case Matters

Hybrid AI is inherently trade‑off aware: it balances privacy, latency, and cost at the edge with capability and breadth in the cloud. Without standard protocols, inter‑model negotiations and tool interactions become bespoke and hard to audit. Two complementary interoperability layers are especially relevant:

  • Inter‑Model Coordination (A2A). A2A provides a structured channel for capability advertisement, budget negotiation, task handoffs, progress updates, and critique/revision between edge and cloud models. This enables portable escalation policies (e.g., “do not send raw PII”, “cap tokens/time per turn”, “require human consent for external web calls”) and consistent recovery behaviors across vendors [A2A].

  • Tool Invocation (MCP). MCP standardizes tool discovery and invocation across both environments (edge and cloud), supporting consistent schemas, streaming/progress, cancellation, and explicit consent prompts. This allows implementers to swap local or remote tools—search, crawling, KB/RAG, Python/services—without rewriting agent logic or weakening privacy controls [MCP].

Implications for Hybrid AI. Using standardized protocols lets implementers compose portable edge–cloud stacks:

  • Edge‑first operation with escalation only when needed, guided by budgets and confidence.

  • Data minimization (local redaction/summarization) and consent workflows at protocol boundaries.

  • Consistent provenance (URIs, hashes, timestamps) and observability across edge and cloud for verifiable traces.

  • Seamless tool portability (local/remote) and policy enforcement that travel with the task rather than the deployment.

5. Use Cases

5.1. AI based operation models

5.1.1. AI-based improvement of Operation Models and increase of Customer Experience

AI agents are seen as potential to improve customer experience in future. The idea is that AI agents or multiple AI agents are integrated into the telecom networks offering services to the user. These services could, for example, be that AI agents are able to perform multi-level of Internet or Intranet search independently, are coordinating calendar entries and emails or multi-step workflows with multiple AI agents and offer pre-built domain agents for areas such as HR, procurement, finance. This will lead to a fundamental change in operating models of companies. The agents are going to help with decision making or have the ability to act on behalf of employees or of the company itself. In a multi-agent scenario various agents of various vendors are communication over the networks and need to interact. The communication flows need to be coordinated and require a standardized AI agent communication protocol and AI framework. Since it is very likely that regulatory aspects – not only network regulatory - need to be obeyed, a standardized and open solution is beneficial compared to proprietary implementations. Multiple AI agents of different vendors need to communicate with each other over different operators and it is required that this eco system is open. Therefore, a standardized AI agent protocol is mandatory.

5.1.2. Voice comes back from the Ashes

It is very likely that with the integration of AI and AI agents into the network the voice services are going to see a revival. Human voice communication with AI agents is simple and a fast way of interaction. ChatBots might give telephone communication a push. By taking this into account a voice human-to-AI agent communication is an additional use case. Regarding this, additional issues need to be considered e.g., security, permission or charging aspects. Since voice is a regulated service the need for a standardized framework and a standardized AI protocol is obvious. AI agents as part of the network communication being integrated in the networks are going to assist the user and will increase its user experience.

5.1.3. AI for Network Management and autonomous Networks

AI agents will also change the network operation model of operators. AI agents are going to analyze network behavior, detect performance issues and implement network reliability by themselves and have the ability to act autonomously. The vision is to have an autonomous and automated Root Cause Analysis and that the network is operated by itself. This can be achieved by using agents that interwork together and are orchestrated by the network operator by an AI agent orchestrator. AI-powered network agents are detecting network anomalies in real time and are making corrections on their own. An example of the RAN (Radio Access Network) where AI agents are monitoring the network behavior during major events and load peaks to ensure high network quality. Agentic AI in this scenario is beneficial because not for every event the required capacity is predictable and acting in real-time by changing RAN or network configuration is helping to ensure the QoE (Qualitiy of Experience) for the customers.

6. Security Considerations

TODO Security

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

8.2. Informative References

[A2A]
"Agent2Agent (A2A) Protocol Specification", n.d., <https://a2a-protocol.org/latest/>.
[A2A-GITHUB]
"Agent2Agent Protocol – GitHub Repository", n.d., <https://github.com/a2aproject/A2A>.
[MCP]
"Model Context Protocol (MCP) Specification", , <https://modelcontextprotocol.io/specification/2025-03-26>.
[MCP-GITHUB]
"Model Context Protocol – GitHub Organization", n.d., <https://github.com/modelcontextprotocol>.
[ODS]
"Open Deep Search", , <https://arxiv.org/abs/2503.20201>.
[ODS-GITHUB]
"OpenDeepSearch", n.d., <https://github.com/sentient-agi/OpenDeepSearch>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Roland Schott
Deutsche Telekom
Julien Maisonneuve
Nokia Bell Labs
L. M. Contreras
Telefonica
Jordi Ros-Giralt
Qualcomm Europe, Inc.