A Framework for Network- and Compute-Aware Cross-Domain Agentic Systems
draft-zhao-rtgwg-agentic-systems-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dan Zhao , Qing Li , Yu Wang , Changlin Jiang | ||
| Last updated | 2026-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhao-rtgwg-agentic-systems-00
Routing Area Working Group D. Zhao
Internet-Draft Q. Li
Intended status: Informational Y. Wang
Expires: 24 April 2027 C. Jiang
Pengcheng Laboratory
21 October 2026
A Framework for Network- and Compute-Aware Cross-Domain Agentic Systems
draft-zhao-rtgwg-agentic-systems-00
Abstract
Agentic systems can carry out tasks using agents, model services,
data services, tools, and computing environments distributed across
sites and administrative domains. Dependencies among these
components create communication and computing requirements that may
evolve during execution. Whether a proposed collaboration can
satisfy those requirements depends on network connectivity and
performance, computing capacity and readiness, data and model
locality, and the policies governing resource use and data movement.
This document describes a framework for cross-domain agentic
collaboration that accounts for task dependencies and the network and
computing conditions affecting communication and execution. It
outlines the roles and interactions of agents and their runtimes,
infrastructure information functions, and resource-management
functions. The framework relates task dependencies to communication
and computing requirements, with consideration of execution
locations, data movement, and constraints spanning dependent
activities. It discusses the use of appropriately scoped domain
information to assess alternative combinations of agents, services,
and tools, together with the abstraction and updating of that
information under partial visibility and independent domain policies.
The framework also addresses adaptation to evolving dependencies and
infrastructure conditions, including information overhead and the
stability of decisions in large agent populations.
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/.
Zhao, et al. Expires 24 April 2027 [Page 1]
Internet-Draft Cross-Domain Agentic Systems October 2026
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 24 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Illustrative Scenario . . . . . . . . . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Requirements Arising from Collaboration . . . . . . . . . 7
4.2. Requirements That Change During Execution . . . . . . . . 7
4.3. Information Across Administrative Boundaries . . . . . . 7
5. Framework Architecture . . . . . . . . . . . . . . . . . . . 8
5.1. Agent and Infrastructure Functions . . . . . . . . . . . 8
5.2. Deriving and Exchanging Requirements . . . . . . . . . . 9
5.3. Delegation and Domain Responsibility . . . . . . . . . . 10
6. From Dependencies to Infrastructure Requirements . . . . . . 10
6.1. Communication Requirements . . . . . . . . . . . . . . . 10
6.2. Computing and Service Readiness . . . . . . . . . . . . . 11
6.3. Data Location and Movement . . . . . . . . . . . . . . . 12
6.4. Locality and Combined Requirements . . . . . . . . . . . 12
7. Cross-Domain Information Exposure . . . . . . . . . . . . . . 13
7.1. Information Relevant to an Activity . . . . . . . . . . . 13
7.2. Abstraction and Administrative Control . . . . . . . . . 13
7.3. Queries, Summaries, and Updates . . . . . . . . . . . . . 14
8. Selection and Runtime Adaptation . . . . . . . . . . . . . . 14
8.1. Choosing an Alternative . . . . . . . . . . . . . . . . . 14
8.2. Responding to New Dependencies . . . . . . . . . . . . . 15
8.3. Responding to Infrastructure Changes . . . . . . . . . . 15
9. Operational Considerations . . . . . . . . . . . . . . . . . 16
Zhao, et al. Expires 24 April 2027 [Page 2]
Internet-Draft Cross-Domain Agentic Systems October 2026
10. Relationship to Existing Work . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
An agentic system pursues a goal through reasoning, delegation,
retrieval, and tool use. An agent may invoke a model service, obtain
data, or delegate part of its work to another agent. These
operations can involve resources at multiple sites and in different
administrative domains. Intermediate results may introduce further
dependencies or change the work that remains to be done.
Functional capability alone does not establish whether these
activities can be completed together. For example, selecting a
remote agent for analysis can also require access to a particular
model, transfer of input data, and permission to process that data at
the destination. Each component may be available while the proposed
collaboration cannot meet its connectivity, completion-time, or data-
handling requirements. Selection therefore needs to consider the
dependencies introduced by an agent, service, or tool and the
interactions required to satisfy them.
These dependencies create distinct network demands, ranging from
latency-sensitive exchanges to bulk data transfers and streamed model
output. Their execution also requires suitable computing resources,
model readiness, and capacity at the relevant locations. Changes in
either the communication paths or execution conditions can alter
which arrangements remain suitable.
Administrative boundaries affect what can be known about these
conditions. A domain determines how resources are used and which
information is exposed to other parties. Agents and their runtimes
therefore make decisions using information that may be abstracted,
incomplete, and valid for a limited period. For systems with large
agent populations or activities that persist over extended periods,
information exchange and reassessment need to remain scoped to
relevant dependencies.
This document describes a framework for deriving communication and
computing requirements from evolving task dependencies, obtaining
relevant information across domains, and using that information to
select and adapt execution arrangements. It addresses data and model
locality and restrictions on data movement and execution alongside
network and computing conditions. The logical functions can be
realized by agent runtimes, service platforms, gateways, information
Zhao, et al. Expires 24 April 2027 [Page 3]
Internet-Draft Cross-Domain Agentic Systems October 2026
services, and resource-management systems. Their interactions
provide a basis for deployment-specific selection and resource-
control mechanisms.
2. Terminology
The following terms are used in this document:
*Agent:* A software entity that selects actions toward a goal using
task context and available capabilities, and can revise those actions
in response to results or changes in its environment.
*Agent runtime:* Software that supports an agent's execution through
functions such as maintaining task context, invoking services and
tools, and managing interactions with other agents and
infrastructure.
*Agentic system:* A system comprising one or more agents together
with the model services, data services, tools, and computing
resources used to pursue goals. The required capabilities and
interactions may change during execution.
*Service:* Functionality made available through a defined interface
for use by another software component. Model inference, data access,
and remotely invoked operations are examples.
*Model service:* A service that provides model inference, accepting
input and returning or streaming the resulting output.
*Data service:* A service that provides access to data through
operations such as queries, retrieval, or streaming.
*Tool:* A callable function used to perform a specific operation,
such as computation, interaction with an external system, or control
of a device. A tool may be implemented locally or exposed through a
service interface.
*Computing environment:* The hardware and software resources that
host and execute agents, services, or tools, including processing,
memory, execution software, and isolation facilities.
*Administrative domain:* An administrative scope governed by an
organization or other authority that determines resource use and
information disclosure. A domain may include any combination of
agents, model services, data, tools, computing resources, and network
infrastructure.
Zhao, et al. Expires 24 April 2027 [Page 4]
Internet-Draft Cross-Domain Agentic Systems October 2026
*Site:* A deployment location relevant to communication, execution,
or policy. A domain may contain several sites, and several domains
may operate resources at one site.
*Endpoint:* A network-accessible interface through which an agent or
service can be reached. An agent or service may be accessible
through multiple endpoints.
*Dependency:* A relationship through which an activity requires an
agent, service, tool, resource, or result. A dependency may become
active only when a particular result or execution condition occurs.
*Alternative:* A proposed way to perform an activity, including the
agents, services, and tools involved, their relevant dependencies,
and the arrangement of execution and data movement. An alternative
may include choices that are resolved later.
Agent, model service, data service, and tool describe functional
roles that can overlap in a deployment. An agent can expose its
capabilities through a service interface, and a service can provide
access to multiple tools. An agent runtime uses the resources of a
computing environment to support the agent's execution.
3. Illustrative Scenario
Agent A in Domain 1 delegates an analysis task to agent B in Domain
2. B uses model service M, also in Domain 2, to perform the
analysis. The initial exchange contains an event description and a
small amount of context. Both agents can meet the initial
communication and execution requirements.
During analysis, B identifies a need for detailed records held by
data service D in Domain 1. B can obtain the information needed for
its analysis in two ways:
1. Retrieve the relevant records from D and process them using
resources in Domain 2.
2. Invoke processing tool P in computing environment E, located near
D in Domain 1, and transfer the resulting features to B.
The first alternative depends on the bulk-transfer performance
between D and Domain 2, together with computing capacity at the
receiving site. The second depends on P's execution capability, its
access to D, available capacity in E, and the size and usefulness of
its output. Both alternatives remain subject to the domains' access
and data-handling policies.
Zhao, et al. Expires 24 April 2027 [Page 5]
Internet-Draft Cross-Domain Agentic Systems October 2026
Data policy can constrain this choice. For example, if raw records
must remain within an approved region, the second alternative is
eligible only when E is in that region and release of the resulting
features to B is permitted.
Domain 1 Domain 2
+-----------------------------+ +-----------------------+
| Agent A | | Agent B |
| Data service D | | Model service M |
| | +-----------------------+
| +-------------------------+ |
| | Computing environment E | | Domain 3
| | Tool P | | +-----------------------+
| +-------------------------+ | | Tool T |
+-----------------------------+ +-----------------------+
Logical exchanges (request / response):
A <-> B : delegation / analysis result
B <-> M : inference request / output
B <-> D : retrieval request / records (alternative 1)
B <-> P : processing request / features (alternative 2)
P <-> D : data access / records (alternative 2)
B <-> T : simulation request / result (later dependency)
Each outer box denotes an administrative domain. The nested box
places P in computing environment E within Domain 1. The exchanges
below the boxes identify the endpoints of each interaction.
Alternatives 1 and 2 are the two data-access options; invocation of T
arises later. Request and return traffic may follow different
network paths. B may select the data-access option itself or
coordinate it with A, according to the scope of the delegated task.
Acceptable latency for the initial agent exchange says little about
the time required to transfer the records. Conversely, proximity to
D does not make P the preferred choice if E has a long execution
queue or lacks required execution software. To choose between these
alternatives, B or its runtime uses information about both the
relevant network relationships and the corresponding execution
capabilities.
A subsequent result may lead B to invoke simulation tool T in Domain
3. Using T adds requirements for input transfer, simulation
execution, and result delivery. The example illustrates how a task's
infrastructure requirements can develop over time, even while A, B,
M, D, and P remain available.
4. Problem Statement
Zhao, et al. Expires 24 April 2027 [Page 6]
Internet-Draft Cross-Domain Agentic Systems October 2026
4.1. Requirements Arising from Collaboration
Selecting an agent, service, or tool independently provides an
incomplete view when its use introduces additional dependencies.
Reachability between A and B does not establish reachability between
B and D or between B and T. Similarly, spare compute capacity at B's
site does not establish that a required model is ready or that
necessary data can be delivered in time.
The relevant unit of consideration is the alternative and its
associated interactions. End-to-end completion can depend on several
communication and processing stages, while concurrent activities may
contend for the same network or computing resources. Information
about individual components needs to be related to these dependencies
before it can guide the choice of an alternative.
4.2. Requirements That Change During Execution
Reasoning, retrieval, and delegated work can reveal new dependencies,
change input sizes, or make previously considered branches
unnecessary. Communication requirements consequently include both
current exchanges and additional exchanges that become relevant as
execution progresses. The relationships may include iteration,
streaming, parallel activity, and feedback.
Agents and their runtimes therefore need to refine infrastructure
requirements incrementally. Early decisions may use operation
classes or demand ranges; later decisions can use actual data sizes,
selected endpoints, and observed execution behavior. The same
process also identifies which existing information remains applicable
after a change.
4.3. Information Across Administrative Boundaries
An organization, such as a research institution, university,
hospital, company, or service provider, can operate one or more
administrative domains. Each domain may manage a combination of
agents, models, data, tools, computing resources, and network
infrastructure. The relevant boundaries follow administrative
responsibility and policy.
Zhao, et al. Expires 24 April 2027 [Page 7]
Internet-Draft Cross-Domain Agentic Systems October 2026
Each domain determines what information it exposes, to which
requesting parties, at what granularity, and under what conditions.
The information available to an external agent or runtime may
therefore be partial even when the domain has a comprehensive
internal view. An alternative can depend on resources governed by
several domains with different disclosure and access policies.
Agents and their runtimes use the information made available by those
domains to evaluate the relevant interactions.
Large agent populations amplify this problem. A global view of raw
network and device state would be expensive to distribute, quickly
outdated, and frequently irrelevant to a given activity. Information
exposure needs to follow the dependencies and decisions for which the
information is useful.
5. Framework Architecture
5.1. Agent and Infrastructure Functions
The framework relates three sets of existing functions:
* *Agent and runtime functions* maintain task context, identify
dependencies, obtain candidate agents, services, or tools, and
choose or revise an alternative. These functions may be
distributed among participating agents and their runtimes.
* *Infrastructure information functions* collect or derive network,
computing, service-readiness, and locality information. They
expose selected information or answer operation-specific queries
under the relevant domain policy.
* *Resource-management functions* authorize and admit operations,
provision resources where needed, and manage their execution.
Observed outcomes and resource changes provide feedback to agents,
their runtimes, and information functions.
A gateway can perform some of these functions for local agents. A
service platform can integrate them into its existing control and
execution components. The placement of the functions follows
ownership, trust relationships, and the information already available
within a deployment.
Zhao, et al. Expires 24 April 2027 [Page 8]
Internet-Draft Cross-Domain Agentic Systems October 2026
+-----------------------------------------------------------+
| Agents and their runtimes |
| Dependencies -> requirements -> selection and adaptation |
+-----------------------------------------------------------+
| requirements ^ information | invocations
v | v
+----------------------------+ +-------------------------+
| Infrastructure information | | Resource management |
| Network and computing | | Admission and execution |
| capabilities and conditions| | within each domain |
+----------------------------+ +-------------------------+
^ |
+---- measurements and feedback ---+
The lower functions operate within the participating domains; their
interfaces follow the domains' disclosure and access policies.
Communication with remote agents, services, and tools uses the
selected endpoints and network services. Infrastructure information
can be obtained through service interfaces, management systems, or
dedicated information services, independently of that traffic.
5.2. Deriving and Exchanging Requirements
An agent or its runtime derives requirements from the intended
operations. Input and output descriptions, service profiles, task
deadlines, and expected concurrency provide initial values.
Measurements from completed or ongoing operations can refine them.
The agent runtime associates requirements with the dependencies that
produced them, so that changes in the selected agent, service, tool,
or input can trigger updates to the affected requirements.
A request for information can concern one service, a set of endpoint
pairs, or several activities that share resources. For the scenario
above, B or its runtime may request network information for D-to-B
transfer and execution information for P, then compare the resulting
alternatives. The request can use a workload class or a bounded
demand description when exact demand is unavailable.
Providers can return capabilities, constraints, performance
estimates, or a direct indication of whether the described operation
is supportable. These forms accommodate different levels of
requester knowledge and provider disclosure. Useful exchanges
identify the subject, workload assumptions, and period to which the
information applies.
Zhao, et al. Expires 24 April 2027 [Page 9]
Internet-Draft Cross-Domain Agentic Systems October 2026
5.3. Delegation and Domain Responsibility
A delegated agent can manage its own internal dependencies. In the
scenario, Domain 2 may expose a completion estimate for B's analysis
that includes its use of M, while Domain 1 exposes P's execution
behavior without identifying E's individual devices. The caller can
use these estimates without needing details of the internal
execution.
External dependencies that affect data recipients, required
connectivity, or the caller's objectives are reflected in the
information exchanged with the caller. When B introduces T, B or its
runtime updates the transfer requirements and completion estimate and
obtains any additional authorization from the responsible domain.
Changes affecting A's requirements are reported through the existing
delegation relationship.
Network ownership may differ from service ownership. End-to-end
information therefore identifies the endpoints or attachment points
it covers, and agents or their runtimes account for any remaining
access or inter-domain segments. Each authority supplies information
and controls resources within its own responsibility; the requesting
agent or runtime combines the parts relevant to the proposed
activity.
6. From Dependencies to Infrastructure Requirements
6.1. Communication Requirements
Dependencies give rise to different communication patterns:
* Agent-to-agent interactions may carry task descriptions, context,
intermediate results, and completion notifications. Repeated
exchanges make round-trip latency relevant; parallel delegation
introduces aggregate traffic and synchronization at result
collection.
* Agent interactions with model services may upload substantial text
or multimodal input and receive streamed output. Input delivery
time, time to first output, output delivery rate, and interruption
behavior can affect different stages of execution.
* Agent interactions with data services include queries, selective
retrieval, bulk transfer, and continuous streams. Data volume,
transfer direction, source locality, and access method influence
the required throughput and completion time.
Zhao, et al. Expires 24 April 2027 [Page 10]
Internet-Draft Cross-Domain Agentic Systems October 2026
* Agent-to-tool interactions range from short calls to asynchronous
jobs with callbacks and artifact transfers. Ordering, timeliness,
and reliable result delivery depend on the operation, especially
when the tool changes external state.
One logical dependency may produce several flows, and a result may
travel directly between services rather than through the initiating
agent. Requirement derivation identifies the actual senders,
receivers, directions, and relevant concurrency. Request, response,
callback, and state-transfer paths are included where the selected
interaction uses them.
Network requirements may express reachability for the required
protocol and security context, delay, delay variation, throughput,
loss tolerance, continuity, or transfer completion objectives. They
can be expressed as ranges or service classes when precise values are
unavailable. Existing path-property vocabulary supports consistent
descriptions [RFC9473].
In the illustrative scenario, changing from records to features
changes the communication demand even if B's endpoint remains the
same. Adding T creates another relationship whose conditions cannot
be inferred solely from the quality of the original A-to-B exchange.
6.2. Computing and Service Readiness
Computing requirements describe the capability needed to execute an
operation and the capacity needed for the intended workload.
Relevant properties include compatibility with required software and
models, accelerator capability, memory, supported input or context
size, concurrent execution, and isolation.
Service readiness connects those capabilities to actual use. A model
may already be loaded, require initialization, or need transfer to an
eligible environment. A tool may have an available execution slot or
a substantial queue. Startup, state restoration, and execution
waiting can dominate processing time and influence service selection.
Agents and their runtimes can use service-level information such as
supported operation profiles, expected waiting and execution times,
or current admission conditions. These descriptions relate more
directly to a request than raw utilization of individual devices.
They also allow a provider to account for internal resources without
exposing their arrangement.
For the data-local alternative, P's availability and E's readiness
are considered together with D access and the result-transfer
requirements. For remote processing, the receiving environment's
Zhao, et al. Expires 24 April 2027 [Page 11]
Internet-Draft Cross-Domain Agentic Systems October 2026
memory and processing capacity are considered together with the
record transfer. Network and computing conditions thus influence the
same choice of execution and data movement.
6.3. Data Location and Movement
Data location describes where the input or state needed for an
operation is available, at the site, domain, or region granularity
relevant to the decision. A data-service endpoint can front remote
storage or several replicas, so its location alone may be
insufficient to estimate transfer requirements.
Policy can separately constrain where data may be stored or
processed, which recipients may receive it, and whether it may be
copied, cached, or forwarded. These constraints apply to the
transfers and processing required by an alternative, including remote
reads that return data to a caller.
Location and movement constraints determine the candidate data
sources and eligible computing environments. When transfer is
allowed, the runtime can compare transferring data for remote
processing with processing near its source, accounting for network
performance and compute readiness in both arrangements. Where
transfer is restricted, a permitted local operation may produce an
output suitable for release.
6.4. Locality and Combined Requirements
Locality also concerns model artifacts, execution state, and tools.
Moving an operation may require transferring or reconstructing state,
and an eligible computing environment needs access to the required
artifacts.
Some requirements apply to the combination: a deadline spanning
retrieval, inference, and a tool call; aggregate demand from parallel
invocations; or a policy restricting every recipient of a data
object. Shared bottlenecks and compute pools affect simultaneous
execution even when each operation is supportable alone.
Task requirements distinguish mandatory constraints from preferences.
Agents or their runtimes can compare expected performance among
permitted alternatives, with suitable treatment of serial and
parallel stages. Estimates identify whether they include
communication, queueing, initialization, or processing, avoiding
double counting when stages are combined. Statistical measures
retain their meanings; independently reported percentile delays are
not generally additive.
Zhao, et al. Expires 24 April 2027 [Page 12]
Internet-Draft Cross-Domain Agentic Systems October 2026
7. Cross-Domain Information Exposure
7.1. Information Relevant to an Activity
A domain can expose information about a service, a site, an endpoint
pair, or a group of resources. The appropriate granularity depends
on the proposed activity. Selecting an initial service may need only
a supported workload class and a broad latency estimate. Comparing
the two data-processing alternatives may require transfer estimates
for specific attachment points and execution estimates for a
specified input size.
Network information describes the relevant source-to-destination
relationship. Useful information includes permitted connectivity,
expected delay, achievable throughput, and availability of a
requested network service. Its scope includes the direction and
traffic class, where these affect the result. A site's general
connectivity advertisement can help identify candidates; information
about the intended data path supports a more specific choice.
Computing information describes supported operations and their
current execution conditions. A domain may expose model readiness, a
waiting-time range, expected execution time for an operation profile,
or an admission response for a proposed workload. A service estimate
can incorporate shared capacity and local contention. When several
requested operations use the same resource pool, the provider can
evaluate the combined demand.
Data information can describe available source regions, permitted
processing locations, and allowed transfers for the requesting
principal and intended operation. A domain can expose a region label
or an answer about a proposed transfer without revealing the
underlying storage location. These constraints help construct
acceptable alternatives before more detailed network and computing
estimates are requested.
7.2. Abstraction and Administrative Control
Providers choose how to represent their resources. A domain may
identify an eligible service region instead of a physical device,
expose a transfer class instead of a path, or answer a bounded
workload query without disclosing internal utilization. The
abstraction needs to preserve distinctions that affect the request:
for example, whether an estimate includes a remote data transfer or
whether two advertised services share limited execution capacity.
Zhao, et al. Expires 24 April 2027 [Page 13]
Internet-Draft Cross-Domain Agentic Systems October 2026
Each response has an identifiable source and subject. Units,
workload assumptions, and observation or validity information allow
recipients to interpret and combine it. Aggregated information
retains the scope of the contributing domains and any conditions
needed to interpret the result. These properties can be carried by
existing information models and service interfaces.
A domain controls disclosure and admission independently.
Information that an operation appears supportable can guide
selection; any resource commitment follows the responsible domain's
admission procedure. If a remote service obtains further resources
internally, its external estimate can cover that work under the
service's own terms.
7.3. Queries, Summaries, and Updates
Stable capability summaries support initial discovery and can be
cached. Queries refine information for the alternatives currently
under consideration. Notifications or subscriptions can then track
conditions affecting selected services and active dependencies. This
sequence limits both disclosure and the amount of information that
each agent or runtime must process.
Update rates follow the property's role in the decision. Supported
software or deployment eligibility often changes less frequently than
queueing delay, available throughput, or endpoint health. Policy
changes may require prompt invalidation even when the underlying
policy is usually stable. A provider can publish a change in an
advertised range or service condition rather than distribute every
underlying measurement.
8. Selection and Runtime Adaptation
8.1. Choosing an Alternative
Agents and their runtimes relate the available information to the
proposed arrangement of work. They consider the senders and
receivers of each data exchange, where processing occurs, and which
constraints span several stages. Candidates obtained through
discovery can be refined as their dependencies become known.
In the illustrative scenario, an available model in Domain 2 favors
remote processing only if the record transfer and receiving resources
meet the task requirements. Processing near D may reduce inter-
domain traffic, but queueing in E can consume the time saved by that
reduction. B or its runtime compares these combined effects using
the objectives and tradeoffs appropriate to the delegated task.
Zhao, et al. Expires 24 April 2027 [Page 14]
Internet-Draft Cross-Domain Agentic Systems October 2026
The information used for a choice needs to describe a compatible
arrangement. A network estimate for one data source cannot be
combined with a computing estimate that assumes another source
without accounting for the change. Similarly, independently
acceptable requests may exceed a shared limit when issued together.
A combined query to the responsible provider, or sufficiently
informative resource constraints, can resolve such dependencies.
The required depth of evaluation depends on the activity. Best-
effort work may proceed using coarse estimates and execution
feedback. A time-bounded or policy-constrained activity may need
more specific information or admission before a consequential step.
When information is missing, the responsible agent or runtime can
request clarification, choose an alternative with known properties,
or defer the affected operation according to the task requirements.
8.2. Responding to New Dependencies
Execution results can reveal additional work to the agent performing
a task. Adding T introduces requirements for its invocation, inputs,
execution, and result delivery, including permission to provide the
intended input to T. A change in the expected output volume of P can
instead modify an existing transfer requirement. Completed
activities and abandoned branches remove demands that are no longer
relevant.
An agent runtime can associate information with the dependencies it
supports and revisit the affected part of an alternative when those
dependencies change. Independent portions of the activity can
continue. A delegated agent can perform this refinement locally and
report changes that affect its caller's objectives or permissions.
Possible responses include selecting another service, processing data
nearer its source, changing permitted concurrency, adjusting an input
representation, or waiting for capacity. Task semantics determine
which substitutions and transformations are acceptable. For example,
a smaller feature representation is useful only if it preserves the
information needed for the analysis.
8.3. Responding to Infrastructure Changes
Network degradation, compute contention, service failure, and changes
in data availability or deployment eligibility can affect active or
pending work. Updates identify the affected services, data
dependencies, or communication relationships. A change in the data
source or in permitted processing locations can require new transfer
estimates and a revised execution arrangement.
Zhao, et al. Expires 24 April 2027 [Page 15]
Internet-Draft Cross-Domain Agentic Systems October 2026
In the scenario, reduced throughput on the D-to-B path may favor
processing near D. A failure of E may favor remote processing or
another eligible environment. If a network operator restores the
required performance through local resource management, the selected
arrangement may remain suitable. Adaptation occurs at the level
where the change can be handled while meeting the activity's
requirements.
The cost of changing an active arrangement also matters. Model
startup, state transfer, repeated data retrieval, and partially
completed tool operations can outweigh an expected performance
improvement. Agents and their runtimes account for these costs and
use appropriate damping to avoid repeated changes in response to
short-lived fluctuations.
Information age affects the confidence of a decision. Execution-time
admission and observed behavior close the gap between earlier
estimates and actual conditions. Feedback can refine later demand
estimates and reveal which changes warrant revisiting the selected
alternative.
9. Operational Considerations
The amount of information exchanged should follow the number of
relevant dependencies and alternatives. Shared summaries, cached
capability information, and subscriptions scoped to active services
reduce repeated queries from large agent populations. Gateways and
platforms can aggregate requests when their authorization and
workload contexts are compatible.
Many agents may react to the same favorable estimate by selecting the
same resources. Local admission, updated availability information,
and retry behavior in agent runtimes help manage the resulting
contention. Information services also need query limits and update
coalescing so that a resource event does not trigger excessive
reassessment traffic.
Operational records can relate a selected arrangement and its
estimated requirements to admission results, measured transfer and
execution times, and subsequent adaptations. This supports diagnosis
when an apparently suitable combination performs poorly. Evaluation
can examine task completion, adaptation cost, information overhead,
and the effect of delayed or partial information across domains.
Zhao, et al. Expires 24 April 2027 [Page 16]
Internet-Draft Cross-Domain Agentic Systems October 2026
Interoperability work can build on this framework by identifying
common operation profiles, network and computing information
semantics, and ways to associate updates with affected dependencies.
Experience with existing discovery, management, and information-
service interfaces can establish which additional protocol elements,
if any, are needed.
10. Relationship to Existing Work
Agent discovery and invocation mechanisms provide candidates and
service descriptions used by agents and their runtimes. DAWN use
cases [DAWN-UC], its discovery framework [DAWN-FW], and AIDIP [AIDIP]
address aspects of this exchange and federation. AIN [AIN] describes
intent-oriented agent networking, including capability information
and dynamic runtime information. These mechanisms can supply initial
candidates and context as dependencies develop.
CATS [CATS] describes traffic steering using computing and network
conditions, with metrics developed in [CATS-METRICS]. Service chains
are within its service model. The task-segmentation framework
[CATS-SEG] considers dependent subtasks, while CATPTS [CATPTS]
addresses coordinated source, compute, destination, and path choices.
Metric semantics [CATS-SEM] address the interpretation and
operational use of resource information. These mechanisms and
descriptions are relevant to realizing the communication and
computing requirements of a selected arrangement.
Distributed inference requirements [DIN], IDN [IDN], and the open
distributed-inference framework [ODSI] examine the dependencies and
resource coordination of inference execution. An agentic system can
consume an inference service that encapsulates this work, or use
exposed information when inference dependencies affect its wider
activity. Retrieval, delegated analysis, and tool interactions place
that inference activity within the dependencies of a broader task.
The Application-Responsive Network framework [ARN] and AI Agent
Policy-Aware Network [APAN] connect application needs and policy to
network behavior. The Agent Gateway Intercommunication Framework
[AGW] includes agent-combination and path selection under service,
network, and security requirements. Such gateways can provide the
infrastructure information and support the agent and runtime
functions described here; the dependencies involved in a task
determine which information those functions require.
ALTO [RFC7285] provides abstractions of network information for
applications. ALTO path vectors [RFC9275] support exposure of
abstract path and shared-resource information, and TIPS [RFC9569]
supports incremental information updates. The multi-domain analytics
Zhao, et al. Expires 24 April 2027 [Page 17]
Internet-Draft Cross-Domain Agentic Systems October 2026
draft [ALTO-MDA] considers dependent computation across domains with
limited information disclosure. ACTN [RFC8453] provides an
architecture for network abstraction and coordination across
administrative boundaries. These approaches support information
exposure and underlying resource management within this framework.
This document brings these functions together around the evolving
dependencies of an agentic activity: deriving the relevant
requirements, relating domain information to the proposed
collaboration, and revisiting the selected alternative as execution
and infrastructure conditions change.
11. Security Considerations
Dependency and infrastructure information can reveal task objectives,
sensitive data locations, workload characteristics, and operational
conditions. Requests as well as responses require access control.
Domain abstractions, bounded queries, and limited retention reduce
unnecessary disclosure, including inference from repeated
observations.
Information used for selection needs integrity and an authenticated
source. Misleading reachability, capacity, or readiness information
can divert work, expose data to an unintended recipient, or cause
denial of service. Recipients apply source and freshness checks
appropriate to the decision and distinguish resource estimates from
authorization to use those resources.
Agent-generated plans and service responses can lead to calls to
additional agents, services, or tools, or to new data transfers.
Authorization is evaluated in the context of the actual operation,
principal, and recipient. A delegated agent's ability to propose a
dependency does not itself authorize that dependency. Domain
enforcement remains with the relevant access-control and resource-
management functions.
Local processing may reduce data movement, but derived features and
model outputs can still contain sensitive information. Data-handling
policy applies to those outputs according to their content and
permitted use. Adaptation preserves these restrictions when changing
a service, execution location, or transfer arrangement.
Recursive delegation, repeated queries, retries, and subscriptions
can amplify load across domains. Quotas, cancellation propagation,
bounded delegation, and authenticated update delivery help contain
such effects. Diagnostic records also require protection because
they may retain the dependency and resource information that exposure
policies are intended to limit.
Zhao, et al. Expires 24 April 2027 [Page 18]
Internet-Draft Cross-Domain Agentic Systems October 2026
12. IANA Considerations
This document has no IANA actions.
13. Informative References
[AGW] Han, Z., Ed., Ruan, Z., Ed., Han, M., Yan, J., Liu, B.,
He, T., and R. Pang, "Agent Gateway Intercommunication
Framework", Work in Progress, Internet-Draft, draft-han-
rtgwg-agent-gateway-intercomm-framework-02, July 2026,
<https://datatracker.ietf.org/doc/html/draft-han-rtgwg-
agent-gateway-intercomm-framework-02>.
[AIDIP] Cui, Y., Chao, Y., and C. Du, "AI Agent Discovery and
Invocation Protocol", Work in Progress, Internet-Draft,
draft-cui-ai-agent-discovery-invocation-02, July 2026,
<https://datatracker.ietf.org/doc/html/draft-cui-ai-agent-
discovery-invocation-02>.
[AIN] Feng, C., "Agentic Intent Network (AIN): A Routing-Based
Architecture for AI Agent Coordination at Scale", Work in
Progress, Internet-Draft, draft-feng-nmrg-ain-
architecture-01, July 2026,
<https://datatracker.ietf.org/doc/html/draft-feng-nmrg-
ain-architecture-01>.
[ALTO-MDA] Xiang, Q., Zhang, J., Le, F., Yang, Y. R., and H. Newman,
"Resource Orchestration for Multi-Domain, Exascale, Geo-
Distributed Data Analytics", Work in Progress, Internet-
Draft, draft-xiang-alto-multidomain-analytics-06, July
2021, <https://datatracker.ietf.org/doc/html/draft-xiang-
alto-multidomain-analytics-06>. Expired Internet-Draft;
cited as prior work.
[APAN] Zhang, X., "Use Cases and Requirements for AI Agent
Policy-Aware Network", Work in Progress, Internet-Draft,
draft-zhang-rtgwg-agent-policy-aware-network-01, July
2026, <https://datatracker.ietf.org/doc/html/draft-zhang-
rtgwg-agent-policy-aware-network-01>.
[ARN] Yang, F. and C. Lin, "Application-Responsive Network
Framework", Work in Progress, Internet-Draft, draft-yang-
rtgwg-arn-framework-08, June 2026,
<https://datatracker.ietf.org/doc/html/draft-yang-rtgwg-
arn-framework-08>.
Zhao, et al. Expires 24 April 2027 [Page 19]
Internet-Draft Cross-Domain Agentic Systems October 2026
[CATPTS] Li, Q., Luan, Z., Fan, Z., and Y. Jiang, "A Timescale-
Aware Framework for Compute-Aware Task Placement and
Traffic Steering in Heterogeneous Geo-Distributed
Computing Networks", Work in Progress, Internet-Draft,
draft-luan-cats-catpts-01, August 2026,
<https://datatracker.ietf.org/doc/html/draft-luan-cats-
catpts-01>.
[CATS] Li, C., Ed., Du, Z., Boucadair, M., Ed., Contreras, L. M.,
and J. Drake, "A Framework for Computing-Aware Traffic
Steering (CATS)", RFC 10053, DOI 10.17487/RFC10053,
October 2026, <https://www.rfc-editor.org/info/rfc10053>.
[CATS-METRICS]
Yao, K., Li, C., Contreras, L. M., Ros-Giralt, J., and G.
Zeng, "CATS Metrics Definition", Work in Progress,
Internet-Draft, draft-ietf-cats-metric-definition-14,
October 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-cats-metric-definition-14>.
[CATS-SEG] Li, C., Wan, J., Tu, H., Miao, C., Yu, Y., Zhang, S., and
B. Ma, "A Task Segmentation Framework for Computing-Aware
Traffic Steering", Work in Progress, Internet-Draft,
draft-li-cats-task-segmentation-framework-02, July 2026,
<https://datatracker.ietf.org/doc/html/draft-li-cats-task-
segmentation-framework-02>.
[CATS-SEM] Zhu, M., "Operational Semantics for CATS Metric
Consumption", Work in Progress, Internet-Draft, draft-zhu-
cats-metric-semantics-01, August 2026,
<https://datatracker.ietf.org/doc/html/draft-zhu-cats-
metric-semantics-01>.
[DAWN-FW] Zhang, B., Ed., Dunbar, L., and Y. Yang, Ed., "A Framework
for Agent Discovery in DAWN", Work in Progress, Internet-
Draft, draft-zhang-dawn-agent-discovery-framework-09,
October 2026, <https://datatracker.ietf.org/doc/html/
draft-zhang-dawn-agent-discovery-framework-09>.
[DAWN-UC] King, D., Yao, K., Adler, K., and R. Ramdhany, "Use Cases
and Applicability for Discovery of Agents With Names",
Work in Progress, Internet-Draft, draft-kay-dawn-use-
cases-01, September 2026,
<https://datatracker.ietf.org/doc/html/draft-kay-dawn-use-
cases-01>.
Zhao, et al. Expires 24 April 2027 [Page 20]
Internet-Draft Cross-Domain Agentic Systems October 2026
[DIN] Song, J. and W. Cheng, "Distributed Inference Network
(DIN) Problem Statement, Use Cases, and Requirements",
Work in Progress, Internet-Draft, draft-song-rtgwg-din-
usecases-requirements-02, July 2026,
<https://datatracker.ietf.org/doc/html/draft-song-rtgwg-
din-usecases-requirements-02>.
[IDN] Li, Q., Wang, H., Jiang, Y., Xu, M., and G. Muntean, "A
Framework of Intelligence Delivery Network (IDN) for Deep
Learning Inference", Work in Progress, Internet-Draft,
draft-li-cats-idn-01, August 2026,
<https://datatracker.ietf.org/doc/html/draft-li-cats-idn-
01>.
[ODSI] Wang, H., Li, Q., Jiang, Y., Xu, M., and G. Muntean, "An
Architecture for Open, Decentralized, and Scalable Large
Language Model Inference", Work in Progress, Internet-
Draft, draft-wang-cats-odsi-01, August 2026,
<https://datatracker.ietf.org/doc/html/draft-wang-cats-
odsi-01>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC9275] Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
"An Extension for Application-Layer Traffic Optimization
(ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275,
September 2022, <https://www.rfc-editor.org/info/rfc9275>.
[RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path
Properties", RFC 9473, DOI 10.17487/RFC9473, September
2023, <https://www.rfc-editor.org/info/rfc9473>.
[RFC9569] Gao, K., Schott, R., Yang, Y. R., Delwiche, L., and L.
Keller, "The Application-Layer Traffic Optimization (ALTO)
Transport Information Publication Service (TIPS)",
RFC 9569, DOI 10.17487/RFC9569, September 2024,
<https://www.rfc-editor.org/info/rfc9569>.
Zhao, et al. Expires 24 April 2027 [Page 21]
Internet-Draft Cross-Domain Agentic Systems October 2026
Authors' Addresses
Dan Zhao
Pengcheng Laboratory
China
Email: zhaod01@pcl.ac.cn
Qing Li
Pengcheng Laboratory
China
Email: liq@pcl.ac.cn
Yu Wang
Pengcheng Laboratory
China
Email: wangy17@pcl.ac.cn
Changlin Jiang
Pengcheng Laboratory
China
Email: jiangchl@pcl.ac.cn
Zhao, et al. Expires 24 April 2027 [Page 22]