Agentic AI Use Cases

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.

IETF scope guidance: Use cases MUST clearly indicate which protocol behaviors are expected to fall under the IETF’s domain (e.g., Internet-facing interoperability, transport/session semantics, media/session behavior, congestion and reliability considerations, security and privacy hooks) versus what is out of scope for the IETF (e.g., model internals, proprietary orchestration logic). Use cases SHOULD also identify where coordination with other SDOs or industry initiatives is required to achieve interoperable and scalable outcomes.
Ecosystem boundary mapping: Use cases SHOULD describe the relevant protocol ecosystem and interfaces between components (e.g., agent-to-agent vs. agent-to-tool) so the IETF can understand what can be standardized as Internet protocols and what is better treated as application/framework conventions. Where applicable, use cases SHOULD illustrate complementary roles of protocols such as agent-to-agent interaction (e.g., ) and agent-to-tool interaction (e.g., ).
Gap analysis readiness: Use cases MUST be structured so that an engineer can map them to existing proposals and then identify missing, underspecified, or insufficiently mature protocol capabilities that block deployment. Use cases SHOULD include enough detail to reveal gaps, and MUST distinguish between gaps that plausibly belong in IETF standardization versus gaps that are purely implementation choices.
Adoption and layering: Use cases SHOULD explain how non-IETF protocols that may be brought into the IETF (e.g., an A2A-like protocol) could be layered on top of, and interoperate cleanly with, existing IETF protocols (e.g., HTTP, QUIC, WebRTC, TLS). Use cases MUST identify assumed transport/bindings and the key interoperation points (e.g., discovery, session establishment, streaming, error handling) needed to assess architectural fit and integration impact.
Communication mode detail: Use cases MUST describe the communication modes required between agents and between agents and tools reachable over the Internet, such as interactive request/response, asynchronous workflows, bulk transfer, incremental streaming, and notification patterns. Use cases SHOULD also indicate modality needs (text, audio/video, files, structured artifacts) when relevant.
Performance and safety needs: Use cases SHOULD include explicit performance requirements when meaningful (e.g., latency sensitivity, bandwidth intensity, jitter tolerance, session duration, scalability expectations). Use cases MUST also call out safety-relevant requirements that have protocol implications (e.g., authorization and consent gates, provenance/citation needs, integrity and replay protection, isolation boundaries for tool invocation).
WG ownership signals: Use cases SHOULD be decomposable into protocol functions that can be mapped to existing IETF working groups (e.g., transport, security, applications, operations/management, identity). Use cases MUST highlight cross-area dependencies (e.g., session + media + security) so the IETF can assess whether coordination across existing WGs is sufficient or whether forming a new WG is justified.
Operational realism: Use cases SHOULD reflect real deployment constraints on the Internet. This requirement helps ensure the resulting protocol requirements are implementable and deployable at scale, rather than being tied to a single controlled environment.
Trust boundaries explicit: Use cases MUST identify administrative domains and trust boundaries (e.g., user device, enterprise perimeter, third-party tool providers, external agent providers) and SHOULD summarize the expected security posture at those boundaries (authentication, authorization, confidentiality, and auditability expectations). This helps ensure the IETF does not miss protocol hooks needed to safely operate agentic systems across domains.

Use Cases

Deep Search Deep Search refers to an agentic information‑seeking workflow in which an AI agent plans, executes, and iteratively refines multi‑step research across heterogeneous sources such as open web, enterprise knowledge bases, APIs, files, and computational tools, among others. Unlike one‑shot retrieval or a single RAG call, Deep Search is long‑horizon and goal‑directed: the agent decomposes a task into sub‑goals, issues searches and crawls, reads and filters evidence, runs auxiliary computations (e.g., code or math), verifies claims, tracks provenance/citations, and synthesizes a final answer---often over minutes or hours rather than milliseconds. This loop is typically implemented as think -> act (tool) -> observe -> reflect -> refine plan until success criteria (e.g., coverage, confidence, cost/time budgets) are met.

Building Blocks A Deep Search workflow may generally comprise the components shown in the next Figure:

Deep Search agentic workflow | (embed/rerank) |-->| (compute, eval) | | +-----------------------+ +----------------+ +-----------------+ | | | | | | | | | +------------- evidence & results returned to agents ---+ | | | v | +--------------------------------------------------------------+ | | DeepSearch Orchestrator: Iterative Improvement Loop | | | | | | Plan -> Act -> Observe -> Refine -> Re-plan |------+ | (query tuning, crawl adjustment, re-ranking, re-eval) | +--------------------------------------------------------------+ | v +--------------------------------------------------------------+ | Final Answer / Output | | (synthesis + citations + confidence) | +--------------------------------------------------------------+ ]]> Each building block in the DeepSearch architecture represents a logical function rather than a specific implementation, and multiple components may be co-located or distributed in practice.

User / Client The User / Client is the entry point to the system. It provides the initial goal or query, along with optional constraints (e.g., scope, freshness, format). The user does not interact directly with tools or agents; all interactions are mediated by the DeepSearch Orchestrator.

DeepSearch Orchestrator The DeepSearch Orchestrator acts as the control plane of the system. Its responsibilities include:

Planning and task decomposition of the user’s request.
Coordinating agents via Agent-to-Agent (A2A) communication.
Managing shared state and memory across iterations.
Controlling iterative execution, including retries and refinements.

The orchestrator does not perform retrieval or computation directly; instead, it delegates work to agents and manages the overall execution flow.

A2A Agent Communication Bus The A2A Agent Communication Bus provides a standardized messaging layer that enables agent-to-agent coordination. It supports:

Task dispatch and response exchange.
Collaboration among specialized agents.
Decoupling of agent implementations from orchestration logic.

This bus allows agents to operate independently while still contributing to a coherent end-to-end workflow.

Agents Mesh The Agents Mesh block represents a set of specialized, cooperative agents operating over the A2A bus. Typical agent roles include:

Research and query expansion.
Retrieval and summarization.
Analysis and computation.
Validation and fact-checking.

Agents are responsible for invoking tools, interpreting results, and returning structured observations to the orchestrator.

MCP Tooling Layer The MCP Tooling Layer provides a standardized interface between agents and external tools. It enables:

Discovery and invocation of tools using a common protocol.
Consistent input/output schemas across heterogeneous tools.
Isolation of agent logic from tool-specific details.

MCP acts as an abstraction boundary that simplifies integration and evolution of external capabilities.

Web Search & Crawling The Web Search & Crawling component combines content discovery and acquisition. It typically includes:

Search engine or SERP APIs for identifying relevant sources.
Focused crawling or fetching to retrieve selected content.

This component supplies raw external data that can be further processed and indexed.

Knowledge Base (KB) / Retrieval Augmented Generation (RAG) Index The KB / RAG Index component manages knowledge representation and retrieval. Its responsibilities include:

Embedding and indexing retrieved content.
Ranking or re-ranking results based on relevance.
Supplying context to agents for retrieval-augmented generation (RAG).

This block provides structured, queryable knowledge derived from external sources.

Python / Tools The Python / Tools component represents general-purpose computation and evaluation capabilities. Examples include:

Data processing and transformation.
Numerical analysis or simulations.
Quality evaluation, scoring, or consistency checks.

These tools are typically invoked by analysis-oriented agents via the MCP layer.

Iterative Improvement Loop The Iterative Improvement Loop captures the system’s ability to refine results over multiple passes and is also implemeted by the DeepSearch Orchestrator. Conceptually, it follows a cycle of: Act -> Observe -> Refine -> Re-plan ]]> Observations and intermediate results are fed back into the orchestrator, which may adjust plans, agent assignments, or tool usage before producing the final output.

Final Answer / Output The Final Answer / Output is the synthesized result returned to the user. It may include:

A consolidated response or report.
References or citations to supporting evidence.
Confidence indicators or stated limitations.

This output reflects the outcome of one or more iterative refinement cycles.

Why This Use Case Matters Deep Search is inherently compositional: it coordinates multiple agents and many tools over extended time. Without standard protocols, systems devolve into brittle, one‑off integrations that are hard to test, secure, or reuse. Two complementary interoperability layers in the DeepSearch are especially relevant:

Agent‑to‑Tool standardization. The Model Context Protocol (MCP) defines a standardized mechanism by which agents and hosts can discover, describe, and invoke tools, resources, and prompts using JSON-RPC over multiple transports (e.g., stdio, HTTP with Server-Sent Events, and WebSocket). MCP enables portable and reusable tool catalogs (including search, crawling, retrieval-augmented generation (RAG), and general-purpose computation) with consistent schemas, capability negotiation, progress reporting, cancellation semantics, and explicit security prompts and user consent. Further details are specified in the MCP specification and related project documentation .
A2A Agent Communication Bus. The Agent2Agent (A2A) protocol focuses on standardized inter-agent collaboration. It defines mechanisms for agent capability discovery (e.g., Agent Cards), task lifecycle management (creation, cancellation, and status reporting), and streaming updates for long-running operations. A2A is designed to support opaque collaboration among agents while avoiding the need to disclose proprietary internal implementations. An overview of the protocol, along with its specification and design rationale, is available from the A2A project documentation .

Implications for Deep Search. Using A2A and MCP together lets implementers compose portable Deep Search stacks:

Tools like crawlers, scholarly search, RAG, and Python are exposed via MCP with typed inputs/outputs and consent flows.
Long‑running research tasks, delegation to specialized researcher/verifier agents, background execution, progress streaming, and result handoff occur via A2A.
Provenance (URIs, hashes, timestamps) and citation schemas can also be standardized at the protocol boundary to enable verifiable research traces across vendors.
Enterprise requirements (authn/z), quotas, observability/tracing, policy enforcement (robots/copyright), and safety reviews—become portable rather than per‑integration glue.

Example: Open Deep Search (ODS) Open implementations illustrate agentic architectures for Deep Search. Open Deep Search (ODS) is a modular, open-source framework developed by Sentient that augments a base large language model with a dedicated Reasoning Agent and an Open Search tool. The framework is designed to support extensible, agentic search workflows in which an agent iteratively plans, invokes search tools, and synthesizes results to answer complex queries. Further details are available in the ODS publication and accompanying reference implementation . ODS exemplifies the building blocks described earlier in this document and is consistent with the proposed interoperability layering, using standardized tool invocation for search and retrieval and agent-centric coordination to manage planning, execution, and refinement.

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 , and both sides can discover and invoke tools via .

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

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.

Interaction Model A typical Hybrid AI session proceeds as follows:

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.
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 .
Cloud Reasoning + Tools. The cloud model performs deeper reasoning and may invoke tools (web search/crawl, KB/RAG, Python) to gather evidence and compute results.
Refine & Return. Intermediate artifacts and rationales flow back over . The edge model may integrate results, perform final checks, and produce the user‑facing output.
Iterate as Needed. The models repeat plan‑act‑observe‑refine until success criteria (quality, coverage, cost/time budget) are met.

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

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.

AI-based troubleshooting and automation Telecom networks have significantly increased in scale, complexity, and heterogeneity. The interplay of technologies such as Software-Defined Networking (SDN), virtualization, cloud-native architectures, network slicing, and 5G/6G systems has made infrastructures highly dynamic. While these innovations provide flexibility and service agility, they also introduce substantial operational challenges, particularly in fault detection, diagnosis, and resolution. Traditional troubleshooting methods, based on rule engines, static thresholds, correlation mechanisms, and manual expertise, struggle to process high-dimensional telemetry, multi-layer dependencies, and rapidly evolving conditions. Consequently, mean time to detect (MTTD) and mean time to repair (MTTR) may increase, impacting service reliability and user experience. Artificial Intelligence (AI) and Machine Learning (ML) offer new capabilities to enhance troubleshooting. AI-driven approaches apply data-driven models and automated reasoning to detect anomalies, determine root causes, predict failures, and recommend or execute corrective actions, leveraging telemetry, logs, configuration, topology, and historical data. Beyond troubleshooting, it is essential to further exploit network and service automation to enable coordinated, policy-based actions across multi-technology (e.g., RAN, IP, optical, virtualized), multi-layer, and dynamic environments. As degradations and faults often span multiple devices, domains, and layers, effective handling requires intelligent and increasingly autonomous mechanisms, ranging from proactive service assurance to automated fault-triggered workflows. This use case envisions a multi-agent AI framework that enhances network and service automation. Agents perform diagnosis and root cause analysis (RCA), while also supporting anomaly prediction, intent-based protection, and policy-driven remediation. The proposed multi-agent interworking autonomously maintains the network in an optimal operational state by correlating heterogeneous data sources, performing collaborative reasoning, and interacting with network elements and operators through standardized protocols, APIs, and natural language interfaces. AI agents form a distributed and scalable ecosystem leveraging advanced AI/ML, including generative AI (Gen-AI), combined with domain expertise to accelerate RCA, assess impact, and propose corrective actions. Each agent encapsulates capabilities such as data retrieval, hypothesis generation, validation, causal analysis, and action recommendation. Designed as composable and interoperable building blocks, agents operate across diverse domains (e.g., RAN, Core, IP, Optical, and virtualized infrastructures), while supporting lifecycle management, knowledge bases, and standardized interfaces.

Building Blocks The use case relies on decentralized multi-agent coordination, where agents exchange structured, context-enriched information to enable dynamic activation and collaborative troubleshooting workflows. A resource-aware orchestration layer manages agent deployment, scaling, and optimization across the network–cloud continuum. Policy frameworks ensure security, compliance, trustworthiness, and explainability, supporting resilient AI-driven network operations.

Why this use case matters This use case highlights the need for interoperable, protocol-based integration of AI-driven troubleshooting and automation components within heterogeneous, multi-vendor environments. Telecom networks are inherently composed of equipment and control systems from different providers, spanning multiple administrative and technological domains. A multi-agent AI framework operating across such environments requires standardized mechanisms for data modeling, telemetry export, capability advertisement, and control interfaces. In particular, consistent information models (e.g., YANG-based models), secure transport protocols, and well-defined APIs are needed to ensure that AI agents can reliably discover, interpret, and act upon network state information across vendor boundaries. Service discovery and capability negotiation are also critical. AI agents must be able to dynamically identify available data sources, peer agents, orchestration functions, and control points, as well as understand their supported features and policy constraints. This implies the need for standardized discovery procedures, metadata descriptions, and context exchange formats that enable composability and coordinated workflows in decentralized environments. Without such interoperability mechanisms, multi-agent troubleshooting systems risk becoming vertically integrated and operationally siloed. Furthermore, governance, security, and trust frameworks are fundamental considerations. AI-driven agents capable of recommending or executing remediation actions introduce new requirements for authentication, authorization, accountability, and auditability. Secure communication channels, role-based access control, policy enforcement, and explainability mechanisms are necessary to prevent misuse, contain faults, and ensure compliance with operational and regulatory constraints.