A Framework for Network- and Compute-Aware Cross-Domain Agentic Systems

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 services, and resource-management systems. Their interactions provide a basis for deployment-specific selection and resource-control mechanisms.

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

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:

Retrieve the relevant records from D and process them using resources in Domain 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. 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.

Problem Statement

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.

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.

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

Framework Architecture

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

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.

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.

From Dependencies to Infrastructure Requirements

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

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

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.

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.

Cross-Domain Information Exposure

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.

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

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.

Selection and Runtime Adaptation

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

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.

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

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

Relationship to Existing Work Agent discovery and invocation mechanisms provide candidates and service descriptions used by agents and their runtimes. DAWN use cases , its discovery framework , and AIDIP address aspects of this exchange and federation. 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 describes traffic steering using computing and network conditions, with metrics developed in . Service chains are within its service model. The task-segmentation framework considers dependent subtasks, while CATPTS addresses coordinated source, compute, destination, and path choices. Metric semantics 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 , IDN , and the open distributed-inference framework 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 and AI Agent Policy-Aware Network connect application needs and policy to network behavior. The Agent Gateway Intercommunication Framework 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 provides abstractions of network information for applications. ALTO path vectors support exposure of abstract path and shared-resource information, and TIPS supports incremental information updates. The multi-domain analytics draft considers dependent computation across domains with limited information disclosure. ACTN 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.

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.

IANA Considerations This document has no IANA actions.