Paper deep dive
ASGE-RR: Agentic Service Graph Embedding with Revisable Reservations for Dynamic AI-Agent Calls
Trond Vatten, Yuming Jiang
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 8/8/2026, 2:06:13 AM
Summary
The paper introduces ASGE-RR, an online controller for Agentic Service Graph Embedding (ASGE) that manages dynamic AI-agent workflows. It addresses the challenge of runtime-revealed dependency calls by using revisable reservations to protect network capacity for likely future calls, thereby improving workflow completion rates compared to traditional online controllers.
Entities (8)
Relation Signals (6)
ASGE-RR → solves → ASGE
confidence 95% · We present ASGE-RR, an online ASGE controller with revisable reservations.
ASGE-RR → usesmechanism → Revisable Reservations
confidence 92% · ASGE-RR protects capacity for likely future calls while enforcing the constraints... updates reservations as new execution information becomes available.
ASGE-RR → evaluatedon → OpenHands
confidence 90% · We evaluate ASGE-RR using OpenHands and GPT Researcher workflows
ASGE-RR → evaluatedon → GPT Researcher
confidence 90% · We evaluate ASGE-RR using OpenHands and GPT Researcher workflows
ASGE-RR → outperforms → rolling-horizon controller
confidence 85% · ASGE-RR already demonstrates noticeable potential: It completes (up to) 10% more workflow value than a same-information rolling-horizon controller
ASGE-RR → outperforms → current-call steering controller
confidence 85% · It completes (up to) 10% more workflow value than a same-information rolling-horizon controller and a current-call steering controller
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:AI-agent workflows often involve remote calls to models, memory stores, and tools distributed across a network. As execution progresses, these dependency calls collectively form an agentic service graph (ASG). Unlike traditional service requests, many dependency calls are revealed only at runtime. Consequently, allocating resources to a currently visible call may consume capacity later needed by a call from a higher-value workflow. We formulate this challenge as Agentic Service Graph Embedding (ASGE), an online network-control problem that maps runtime-revealed workflow calls to service replicas and network paths under capacity, cost and deadline constraints. We present ASGE-RR, an online ASGE controller with revisable reservations. ASGE-RR protects capacity for likely future calls while enforcing the constraints. ASGE-RR evaluates candidate replica-and-path mappings against predicted workflow continuations and updates reservations as new execution information becomes available. We evaluate ASGE-RR using OpenHands and GPT Researcher workflows executed with gpt-5.6-luna and replayed over in two complementary experimental environments, a controlled Docker testbed and a WAN testbed. The investigation shows that all the evaluated AI-agent tasks expose at least one runtime-revealed dependency call that can be steered before connection establishment. Exploiting this control point, even though the experimental environments are small-scale, ASGE-RR already demonstrates noticeable potential: It completes (up to) 10% more workflow value than a same-information rolling-horizon controller and a current-call steering controller on the WAN testbed. The results suggest that runtime-revealed workflow structure creates a new network control opportunity: protecting resources for likely future calls allows more AI-agent workflows to finish in time.
Tags
Links
- Source: https://arxiv.org/abs/2608.06033v1
- Canonical: https://arxiv.org/abs/2608.06033v1
Trouble viewing inline? Open PDF directly →
Full Text
57,425 characters extracted from source content.
Expand or collapse full text
ASGE-R: Agentic Service Graph Embedding with Revisable Reservations for Dynamic AI-Agent Calls Trond Vatten, Yuming Jiang Norwegian University of Science and Technology (NTNU), Trondheim, Norway Abstract AI-agent workflows often involve remote calls to models, memory stores, and tools distributed across a network. As execution progresses, these dependency calls collectively form an agentic service graph (ASG). Unlike traditional service requests, many dependency calls are revealed only at runtime. Consequently, allocating resources to a currently visible call may consume capacity later needed by a call from a higher-value workflow. We formulate this challenge as Agentic Service Graph Embedding (ASGE), an online network-control problem that maps runtime-revealed workflow calls to service replicas and network paths under capacity, cost and deadline constraints. We present ASGE-R, an online ASGE controller with revisable reservations. ASGE-R protects capacity for likely future calls while enforcing the constraints. ASGE-R evaluates candidate replica-and-path mappings against predicted workflow continuations and updates reservations as new execution information becomes available. We evaluate ASGE-R using OpenHands and GPT Researcher workflows executed with gpt-5.6-luna and replayed over in two complementary experimental environments, a controlled Docker testbed and a WAN testbed. The investigation shows that all the evaluated AI-agent tasks expose at least one runtime-revealed dependency call that can be steered before connection establishment. Exploiting this control point, even though the experimental environments are small-scale, ASGE-R already demonstrates noticeable potential: It completes (up to) 10% more workflow value than a same-information rolling-horizon controller and a current-call steering controller on the WAN testbed. The results suggest that runtime-revealed workflow structure creates a new network control opportunity: protecting resources for likely future calls allows more AI-agent workflows to finish in time. I Introduction An AI-agent workflow for a complex task often includes remote calls to services like AI models, memory stores, and tools distributed across a network. Modern agent-serving platforms dynamically invoke these services as execution unfolds, allowing workflows to adapt to intermediate results and environmental conditions. We call each such remote invocation a dependency call. Because those services are commonly replicated across data centers, edge sites, or clusters, the infrastructure operator often has multiple equivalent endpoints for the same dependency call. Its network controller can therefore choose which replica a workflow contacts and which managed paths carry the request and response traffic. Existing work has already viewed such decisions as opportunities to reduce latency, balance load, or improve resource utilization [1, 2, 3]. Fig. 1 shows this control surface: an AI-agent workflow reveals a dependency call, a gateway asks a network controller to select an eligible service replica and to manage the request and response paths before opening the connection. AI-agent workflow1modelresultverifiergatewaymanaged networkeligible replicasAB3network controller2call + deadlinereplica + paths Figure 1: Conceptual overview of where ASGE acts. (1) An intermediate result reveals a dependency call. (2) Before connection, the gateway asks the network controller for a mapping. (3) The controller selects an eligible service replica and managed request and response paths. In this paper, we argue that adaptive AI-agent workflows create another Network-for-AI opportunity: network control can increase the amount of workflow value completed before deadline without adding capacity. However, there is an inherent challenge that arises because AI-agent workflows reveal resource allocation demands incrementally at runtime: a workflow’s next remote call is often unknown until an earlier stage completes. Consequently, future network resource demands become visible only during execution. This runtime revelation creates a new network resource allocation problem, which we call Agentic Service Graph Embedding (ASGE). The problem is to decide how to map a workflow’s agentic service graph (a directed acyclic graph (DAG)) onto network resources, such as service replicas and communication paths. While a workflow runtime determines which call to invoke next, the network decides where the call is served and how traffic reaches it. ASGE differs from established networking formulations, including Service Function Chaining (SFC) [4] and Virtual Network Embedding (VNE) [5], which assume requests are known at admission and during embedding. In contrast, ASGE operates when a workflow is already running, earlier bindings are fixed, and future dependency calls may not yet exist from the control perspective. ASGE is uniquely challenging because a decision optimal for the currently visible call may consume capacity later required by a higher-value workflow that has not yet been revealed. To address this challenge, we develop ASGE-R (ASGE with Revisable Reservations). ASGE-R evaluates each currently available replica-and-path mapping by asking whether likely future workflow continuations would remain feasible after the decision is made. Rather than permanently reserving and binding resources, ASGE-R makes revisable reservations that protect capacity for predicted future calls while allowing those reservations to be updated whenever new workflow information becomes available. In this way, ASGE-R converts partial knowledge about future workflow structure into admission protection without violating hard capacity constraints. We make several contributions. First, we formulate ASGE and its complete-information benchmark. Second, we design ASGE-R, an online ASGE controller with revisable reservations, and prove that every committed action satisfies resource and policy constraints. In addition, we evaluate ASGE-R on captured OpenHands and GPT Researcher workflows in Docker and on a WAN. It is found that all the evaluated OpenHands and GPT Researcher tasks expose at least one runtime-revealed dependency call that can be steered before connection establishment. Exploiting this control point, ASGE-R already demonstrates noticeable potential even under small-scale experiments: ASGE-R completes (up to) 10% more workflow value than a same-information rolling-horizon controller and a current-call steering controller on the WAN testbed, without adding network capacity. I Motivation, Model and Benchmark I-A The problem, challenge and opportunity We consider AI-agent workflows that call possibly replicated services across a network managed by an infrastructure operator. For each dependency call, the infrastructure operator can choose an equivalent replica and managed paths to and from it. By coordinating calls that share a workflow deadline, the network may help more valuable workflows finish on time without adding capacity. After completion, the related calls form the workflow’s service graph. The replica-and-path selection for each call becomes a mapping of that service graph onto network resources. This is the ASGE problem. While coordinating resource use among calls opens up an opportunity for the infrastructure operator to make better use of resources, this adaptability also creates a challenge: the next dependency call may appear only after earlier network choices are fixed. To demonstrate, consider an AI-agent workflow responding to a network service-level objective (SLO) violation. It collects telemetry, calls model and memory services to diagnose the cause, and asks a planner to propose an action. A verifier may accept the proposal, reject it and trigger more diagnosis, or send the approved action to a tool gateway. The possible steps may be known in advance, but the exact call sequence is not. An illustration of the challenge and opportunity is provided in Fig. 2, where there are two paths from the AI agent to the memory: a “fast” path and a “slow” path. It also shows two memory-related calls: an ordinary “memory” call that is available now, and a memory lookup call from the “verifier” that arrives later. For the ordinary memory call, either path can meet its requirement, but the verifier needs to use the fast path to finish by the workflow deadline. For the challenge, Fig. 2a shows that if the replica-and-path mapping is chosen solely based on current information, the fast path would be assigned to the ordinary memory call, causing the later verifier call to fail to meet the workflow deadline. For the opportunity, Fig. 2b demonstrates that if there were a way to coordinate such that the ordinary memory call would use the slow path, then the later verifier would be able to use the fast path and both calls would finish on time. (a) Current-only choicescarcealternatememory nowverifier later×verifier misses the deadline(b) ASGE-RRrevisable reservationscarcealternateverifier latermemory now✓ calls finish on time Figure 2: Conceptual illustration of the challenge and opportunity. I-B System model To formally describe and study ASGE, we first introduce the system model in this section and then construct a benchmark in Section I-C. I-B1 Network and service substrate The network is represented by a directed graph G=(V,E)G=(V,E), where V denotes the set of nodes and E the set of links of the network. Link e∈Ee∈ E has capacity Ue[bit/s]U_e\,[bit/s] and one-way delay δe[s] _e\,[s]. For directed path p, let e(p)1_e(p) be one when p uses link e. Its delay δ(p)δ(p) can be calculated as δ(p)=∑e∈pδeδ(p)= _e∈ p _e. Each service type d may be served by a replica in the set dU_d. Replica u resides at node n(u)∈Vn(u)∈ V and provides service capacity QuQ_u measured in service-work units per second [service-work units/s]. I-B2 Workflow replay Note that for an AI-agent task, its exact workflow is available only after execution is complete and depends on network-control decisions. To isolate network control from agent behavior, we use workflow replay: arrivals, branch outcomes, dependency-call releases, request and response sizes, call execution behavior, and realized service times are fixed from the completed execution. This ensures that all policies face identical workflow behavior and allows differences in outcome to be attributed solely to network control. AI-agent workflow r arrives at time ArA_r and has deadline budget LrL_r with value νr _r. The absolute deadline is Ar+LrA_r+L_r. Let rζD_r^ζ denote the set of dependency calls observed in replay ζ, where repeated invocations remain distinct calls. I-B3 Delay calculation For call c∈rζc _r^ζ, let vrcv_rc denote the issuing host, d(c)d(c) the called service type, mrc→m_rc^→ [bit] the request size, mrc←m_rc^← the response size [bit], brc→b_rc^→ [bit/s] the reserved transfer rate on the path from the host to the service, and brc←b_rc^← [bit/s] the reserved transfer rate on the reverse path. A candidate replica-and-path mapping for the call is denoted as γ=(u,p→,p←)∈rc(vrc),γ=(u,p^→,p^←) _rc(v_rc), which selects replica u∈d(c)u _d(c), request path p→p^→ from vrcv_rc to n(u)n(u), and response path p←p^←, where rc(vrc)G_rc(v_rc) denotes the set of possible mappings and the two paths p→p^→ and p←p^← may differ. At the call release, the following information is assumed to be known, e.g. via measurements: whether replica u is available (w¯rcu=1 w_rcu=1), an upper bound on required service work w^rcu w_rcu, and an upper bound on setup time κrcu _rcu [s]. Suppose replica u can support service rate λrcu _rcu [service-work units/s] to the call. Then, these values give the service-time bound s^rcu=w^rcu/λrcu+κrcu s_rcu= w_rcu/ _rcu+ _rcu. Ignoring queueing, the corresponding call completion time is bounded by drc(γ)= d_rc(γ)= drctrl+mrc→brc→+δ(p→)+s^rcu d^ctrl_rc+ m_rc^→b_rc^→+δ(p^→)+ s_rcu +mrc←brc←+δ(p←), + m_rc^←b_rc^←+δ(p^←), (1) where drctrld^ctrl_rc represents the controller and path establishment delay. This delay duration drc(γ)d_rc(γ) includes controller processing, data transfer on request and response paths, service execution, and delay of both paths. I-C Complete-information benchmark For a completed replay ζ, all branch outcomes, dependency calls, and realized service times are known. Each workflow can therefore be represented as a fixed, path-based, time-indexed DAG. We use this information to define a noncausal benchmark: the best joint replica, path, waiting, and phase schedule on the same finite time grid used by the online controller. For workflow r, let rζK_r^ζ be the finite set of complete configurations satisfying replica eligibility, path policy, stage precedence, and non-preemption. Configuration k fixes the replica and paths of every call, any deliberate waiting, and the request, setup/service, and response phase schedule. Let TrkT_rk be its arrival-relative completion time and Krk≥0K_rk≥ 0 its total cost under the per-action cost rule C(⋅)C(·). Its schedule induces directed-link load Brk,eℓB_rk,e and replica service-rate load Drk,uℓD_rk,u in time bucket ℓ . The former includes fixed-route workflow messages and charges request and response bandwidth only while the corresponding phase executes. Background loads B¯eℓ B_e and D¯uℓ D_u are common to all policies. Below, ∑r,k _r,k abbreviates ∑r∑k∈rζ _r _k _r^ζ. Binary zrkz_rk selects configuration k, and ara_r indicates that workflow r completes by its deadline. The complete-information benchmark is lexmaxa,z a,zlexmax (∑rνrar,−∑r,kTrkzrk,−∑r,kKrkzrk) ( _r _ra_r,\,- _r,kT_rkz_rk,\,- _r,kK_rkz_rk ) (2) s.t. ∑k∈rζzrk=ar, _k _r^ζz_rk=a_r, ∀r, ∀ r, (3) B¯eℓ+∑r,kBrk,eℓzrk≤Ue, B_e + _r,kB_rk,e z_rk≤ U_e, ∀e,ℓ, ∀ e, , (4) D¯uℓ+∑r,kDrk,uℓzrk≤Qu, D_u + _r,kD_rk,u z_rk≤ Q_u, ∀u,ℓ, ∀ u, , (5) ∑k∈rζTrkzrk≤Lrar, _k _r^ζT_rkz_rk≤ L_ra_r, ∀r, ∀ r, (6) zrk,ar∈0,1. z_rk,a_r∈\0,1\. (7) The objective first maximizes priority-weighted workflow value completed by deadline, then minimizes completion time and resource cost. If each configuration catalog contains every assignment satisfying the stated per-workflow constraints, Eqs. (2)–(7) give the exact complete-information optimum for replay ζ. The benchmark is not implementable online because future calls and service times have not yet been revealed. I-D Online ASGE The complete-information benchmark assumes knowledge that a live controller lacks, so it is not implementable in practice. In the following, we focus on the online ASGE problem that begins after workflow execution has started and only a prefix of the workflow has been observed. I-D1 Information available at decision time The live controller operates from the observed history, remaining capacity, fixed earlier choices, reservations for possible later calls, policy, and readiness. At each event, it first frees capacity that has ended its use. Events include call arrival, fixed stage start/end, branch outcome, call release/return, and termination. If a call appears, it chooses a replica and paths or waits, then books the call’s three phases, i.e., the request, service, and response phases. We record all observations in time order. For replay ζ, policy Π produces ωΠ(ζ)=((t1,e1),…,(tT,eT)) _ (ζ)=((t_1,e_1),…,(t_T,e_T)). Let ℱτ=σ((t1,e1),…,(tτ,eτ))F_τ=σ((t_1,e_1),…,(t_τ,e_τ)) be the history through event τ. At decision time τ for a call, the available information or decision state is represented by Iτ=(ℱτ,S~τ,Xτ,Aτ,Rτ,Pτ,W¯τ), I_τ=(F_τ, S_τ,X_τ,A_τ,R_τ,P_τ, W_τ), (8) where S~τ S_τ records remaining capacity; XτX_τ contains fixed bindings; AτA_τ contains hard allocations; RτR_τ contains reservations; and Pτ,W¯τP_τ, W_τ represents current policy PτP_τ and readiness information W¯τ W_τ. A policy is causal if decision dτd_τ depends only on IτI_τ: dτ=Π(Iτ), d_τ= (I_τ), (9) As a highlight and difference from the benchmark, future observations may influence later decisions here but cannot affect decisions already made. This information asymmetry defines the online ASGE problem. I-D2 Capacity evolution When a decision is committed, the controller binds each call before dispatch and keeps that binding fixed until the response returns. In addition, the controller books resource usage into a capacity calendar that records how available capacity of a service replica or a link evolves. Let g index a time bucket. In bucket g, the maximum available capacity is ceg=Ue−B¯egc_eg=U_e- B_eg for link e and cug=Qu−D¯ugc_ug=Q_u- D_ug for service replica u, where B¯eg B_eg and D¯ug D_ug respectively denote the background load on the link or the replica. To simplify representation, we use j∈e,uj∈\e,u\ to index either a link or a service replica in the following. Let ρjg(eτ) _jg(e_τ) be load released or expired at the event and ujg(dτ)u_jg(d_τ) denote the action’s phase calendar, where j∈e,uj∈\e,u\. The transition of load on link e (by letting j=ej=e) or replica u (by letting j=uj=u) can be represented by A~τ,jg A_τ,jg =Aτ−1,jg−ρjg(eτ),A~τ,jg+ujg(dτ)≤cjg, =A_τ-1,jg- _jg(e_τ), A_τ,jg+u_jg(d_τ)≤ c_jg, (10) Aτ,jg A_τ,jg =A~τ,jg+ujg(dτ),∀j,g. = A_τ,jg+u_jg(d_τ), ∀ j,g. (11) The remaining capacity is then S~τ,jg=cjg−A~τ,jg S_τ,jg=c_jg- A_τ,jg. As transactions finish, their allocations are released. Resource updates follow Eqs. (12)-(13), ensuring that committed allocations never exceed available capacity. As a remark, every allocation uses a half-open phase interval. A call that finishes midway through a bucket releases capacity at the next boundary, which makes rounding conservative. As time advances, expired buckets disappear from the controller’s relative view. I-D3 Evaluation metrics As in the complete-information benchmark, we evaluate policies using three quantities: completed workflow value, completion time, and resource cost. For replay ζ, the corresponding lexicographic performance vector is defined as Π(ζ)=( _ (ζ)= ( ∑rνrTrΠ≤Lr, _r _r1\T_r ≤ L_r\, −∑r:TrΠ≤LrTrΠ,−∑τC(dτ)) - _r:T_r ≤ L_rT_r ,- _τC(d_τ) ) (12) where, if a request is incomplete or dropped, set TrΠ=∞T_r =∞. Reporting these components separately makes the trade-offs visible: a policy may complete more value, finish workflows sooner, or consume fewer resources. I-D4 Fundamental limitation One might hope that a deterministic online controller could guarantee near-optimal performance on every workload. Unfortunately, this is impossible without additional assumptions. No deterministic causal policy for ASGE can admit a positive workload-independent competitive ratio. Recall the example shown in Fig. 2, where it is shown that committing capacity to an earlier revealed call blocks a later call from a higher-value workflow revealed after the commitment. A controller with complete information can complete both workflows, whereas any deterministic online policy can be forced arbitrarily far from optimal. Consequently, online ASGE cannot rely on worst-case competitiveness. So, instead, we focus on two properties: • hard feasibility guarantees, and • measured performance relative to the complete-information benchmark. The complete-information benchmark defines what is achievable with full knowledge of workflow evolution. The challenge is approaching that benchmark while observing only runtime-revealed calls. The next section presents ASGE-R, which addresses this challenge through revisable reservations and future-aware admission decisions. I ASGE-R: ASGE with Revisable Reservations I-A Design overview ASGE-R addresses the failure mode in Fig. 2 through revisable reservations: it protects capacity for likely future calls and revises that protection whenever new workflow information arrives. At each call-release event, it performs four steps: • Generate feasible actions: Construct all policy-compliant replica-and-path choices for the newly revealed call. • Forecast plausible workflow continuations: Estimate a bounded set of possible future call sequences that may still occur. • Compute revisable reservations: Determine how much capacity should be protected for those future possibilities. • Select an action: Choose the feasible action that best balances deadline completion, resource cost, and future flexibility. Importantly, only the selected action becomes committed, and only issued calls consume actual resources. However, for resource reservation, ASGE-R does not permanently reserve capacity; reservations remain in a soft state that guides admission decisions and may change at the next event. As a result, forecast errors may reduce efficiency but cannot violate capacity constraints. I-B Capacity calendar ASGE-R represents link and service-replica capacity using a time-indexed resource calendar. Specifically, ASGE-R divides the time before a workflow deadline into capacity slots. Let J index directed links and service-replica resources. For each resource j∈j , which is either a directed link e or a service-replica resource u, and time slot τ, the calendar tracks: (1) committed load from issued calls, (2) reserved load for possible future calls, and (3) remaining available capacity. The calendar is updated every time tτt_τ when a call completes, a new call is revealed, a workflow terminates, or a reservation changes. By maintaining explicit resource occupancy through time, the controller can reason about whether current decisions leave sufficient capacity for future workflow execution. When a dependency call is released, ASGE-R generates all legal mappings. Each candidate mapping specifies γ=(u,p→,p←),γ=(u,p^→,p^←), and creates a calendar footprint consisting of: request-path bandwidth, replica service usage, and response-path bandwidth. This footprint becomes the basis for later feasibility checks. The controller also considers a strategic waiting action, γwait _wait, which postpones dispatch until the next scheduling boundary. Including wait actions is important because immediate service is not always optimal. Under contention, briefly delaying one call can enable multiple workflows to meet their deadlines. Specifically, the resource allocation uses an absolute time grid with boundaries gΔg . At time tτt_τ, gτ(1),…,gτ(Hrτ)g_τ(1),…,g_τ(H_rτ) are the absolute buckets that overlap workflow r’s remaining interval [tτ,Ar+Lr)[t_τ,A_r+L_r), viewed as relative slots. ASGE-R charges a partial first bucket in full: Hrτ=|g:[gΔ,(g+1)Δ)∩[tτ,Ar+Lr)≠∅|H_rτ=|\g:[g ,(g+1) )∩[t_τ,A_r+L_r)≠ \|; H below is its workload maximum. The remaining capacity in this view is Sτ,jℓ=cj,gτ(ℓ)−A~τ,j,gτ(ℓ)S_τ,j =c_j,g_τ( )- A_τ,j,g_τ( ). It already considers issued calls and fixed workflow messages. Candidate γ has a sparse calendar uγ,jℓu_γ,j . It books bandwidth on the request path, λrcu _rcu at the replica during service, and bandwidth on the response path. The action set also includes γwait(t+)γ^wait(t^+). This action leaves the call undispatched until the first grid boundary at or after the earliest known release t+t^+, then shifts the candidate calendar to that boundary. I-C Forecasting future calls Future calls are unknown at the time of decision. ASGE-R therefore reasons over a set of plausible workflow continuations. We call each plausible workflow continuation or possible remaining call sequence a suffix. Examples include: a verifier accepting a plan, a verifier rejecting a plan, a planner generating an additional tool call, a retrieval step causing another model invocation, and workflow termination. ASGE-R assigns probabilities to these suffixes using traces collected from previous workflow executions. To keep computation bounded, only the highest-probability suffixes are retained. A configurable coverage threshold determines whether enough probability mass remains. If too much uncertainty exists, ASGE-R abandons reservations and reverts to a myopic strategy. This fallback mechanism prevents the controller from making aggressive reservation decisions on weak evidence. Specifically, for workflow r, let Σr(qr,τ) _r(q_r,τ) denote the set of suffixes consistent with the observed workflow state at time τ. ASGE-R keeps at most Z suffixes in Σr(qr,τ) _r(q_r,τ). Their original probability mass is mrτ=∑σ∈Σrp^r,τ(σ)m_rτ= _σ∈ _r p_r,τ(σ), where p^r,τ(σ) p_r,τ(σ) denotes the probability of suffix σ happening in Σr(qr,τ) _r(q_r,τ). Let αr∈[0,1] _r∈[0,1] be the largest allowed omitted mass. If mrτ<1−αrm_rτ<1- _r, the forecast omits too much probability and the method falls back to myopic control. Otherwise, it normalizes the retained weights: p~r,τ(σ)=p^r,τ(σ)/mrτ p_r,τ(σ)= p_r,τ(σ)/m_rτ. The weights must be learned from traces that are disjoint from the evaluation set. For each current choice, a bounded search simulates these possible futures. The search remains causal: futures with the same observed history must make the same choice until a new observation separates them. If two sequences begin with the same memory call, for example, they use the same simulated replica choice until a later verifier result appears. A scenario-tree beam search produces a future resource calendar vrσ,jℓ(γ)v_rσ,j (γ) and absolute completion estimate C^rσ(γ) C_rσ(γ) for each retained suffix, including future fixed-route workflow messages. A suffix extending beyond slot HrτH_rτ receives C^rσ=∞ C_rσ=∞ and holds its capacity bound through the deadline. We retain candidates that fit every retained scenario. I-D Forecasting future capacity demand and completion The retained sequences of Σr(qr,τ) _r(q_r,τ) are treated as alternatives rather than simultaneous demand. ASGE-R uses a weighted quantile to choose how much capacity to protect in each resource-time slot and another to estimate completion time. Let ϵr,βr∈[0,1] _r, _r∈[0,1] be the resource and completion tail levels, and let QqQ_q be a weighted q-quantile over the retained suffixes. Rrτ,jℓ(γ)R_rτ,j (γ) summarizes forecast demand for one resource and slot; C^rτβ(γ) C^β_rτ(γ) summarizes forecast completion: Rrτ,jℓ(γ)=Q1−ϵr(vrσ,jℓ(γ):σ∼p~r,τ(⋅∣qr,τ)), R_rτ,j (γ)=Q_1- _r\! (\v_rσ,j (γ):σ p_r,τ(· q_r,τ)\ ), (13) C^rτβ(γ)=Q1−βr(C^rσ(γ):σ∼p~r,τ(⋅∣qr,τ)). C^β_rτ(γ)=Q_1- _r\! (\ C_rσ(γ):σ p_r,τ(· q_r,τ)\ ). (14) Rrτ,jℓ(γ)R_rτ,j (γ) and C^rτβ(γ) C^β_rτ(γ) represent the amount of capacity to be protected for how long for future calls if action γ is selected. Together, these parameters provide a tunable tradeoff between resource efficiency and deadline robustness. Smaller ϵr _r and βr _r make both tests more conservative. These are marginal per-resource quantiles. At ϵr=0 _r=0, ASGE-R protects the greatest demand for each resource and slot while keeping mutually exclusive branches separate. Probability mass omitted from Σr _r counts as late in p^rτon(γ)=∑σ∈Σrp^r,τ(σ)C^rσ(γ)≤Ar+Lr p_rτ^on(γ)= _σ∈ _r p_r,τ(σ)1\ C_rσ(γ)≤ A_r+L_r\. Without a usable template, Rrτ=0R_rτ=0, and the completion test uses a configured lower bound on remaining work. The method is then myopic. I-E Feasibility tests The controller next eliminates actions that are unlikely to succeed. A candidate mapping γ must satisfy resource feasibility and deadline feasibility. The former ensures that the current load, existing reservations, and new reservations must all fit within available capacity. The latter is to satisfy the estimated completion time. Together, these two tests function as a future-aware admission control mechanism. Let R−r,τR_-r,τ be the capacity protected for other workflows. A current choice must pass two tests. Its call and all relevant reservations must fit in every resource-time slot, and its estimated completion must meet the deadline: uγ,jℓ+Rrτ,jℓ(γ)+R−r,τ,jℓ u_γ,j +R_rτ,j (γ)+R_-r,τ,j ≤Sτ,jℓ, ≤ S_τ,j , ∀j,ℓ, ∀ j, , (15) C^rτβ(γ) C^β_rτ(γ) ≤Ar+Lr. ≤ A_r+L_r. (16) These forecast tests retain choices predicted to fit and finish. Without a workflow template, Eq. (16) uses a lower bound on remaining work to screen calls whose earliest possible completion exceeds the deadline. I-F Reservation arbitration For workflow r and feasible candidate mapping γ at time τ, a reservation priority πrτ(γ) _rτ(γ) is calculated: πrτ(γ)=νrp^rτon(γ)maxϵt,Ar+Lr−tτ _rτ(γ)= _r p_rτ^\,on(γ) \ _t,A_r+L_r-t_τ\ (17) where ϵt>0 _t>0 is a deadline guard measured in seconds. This priority rises with workflow value, predicted on-time probability, and urgency. The terms prefer earlier completion, lower cost, and less use of scarce capacity. A valuable workflow near its deadline therefore has a higher-priority reservation. If reservations for other workflows block all current actions, ASGE-R releases lower-priority reservations in increasing order of priority until a feasible action appears, or until no more reservations can be removed. This policy prevents low-priority speculative reservations from blocking high-priority work. I-G Action ranking Multiple feasible actions may remain after screening. Rather than choosing the earliest completion time alone, ASGE-R scores each candidate based on three factors: completion, resource cost, and resource scarcity for future calls. The resulting score balances short-term performance and future flexibility. While a myopic controller focuses almost entirely on the first, ASGE-R explicitly accounts for all three. Once an action fits, a score scoreτ(γ)score_τ(γ) ranks the remaining choices. Let Kτ(γ)K_τ(γ) use the same per-action cost rule C(⋅)C(·) as the complete-information benchmark to candidate γ’s current-call calendar uγu_γ and controller charge. It excludes the soft reservation Rrτ(γ)R_rτ(γ). Define normalized completion C¯rτ(γ)=(C^rτβ(γ)−tτ)/maxϵt,Ar+Lr−tτ C_rτ(γ)=( C^β_rτ(γ)-t_τ)/ \ _t,A_r+L_r-t_τ\ and normalized cost K¯τ(γ)=Kτ(γ)/K0 K_τ(γ)=K_τ(γ)/K_0. We tune positive scale K0K_0 and weights λK,λR≥0 _K, _R≥ 0 on separate calibration traces. Per-resource guard ηj>0 _j>0, expressed in resource j’s units, prevents division by zero. The score is calculated as scoreτ(γ)= _τ(γ)= C¯rτ(γ)+λKK¯τ(γ) C_rτ(γ)+ _K K_τ(γ) +λR∑j,ℓuγ,jℓ+Rrτ,jℓ(γ)ηj+Sτ,jℓ−R−r,τ,jℓ. + _R _j, u_γ,j +R_rτ,j (γ) _j+S_τ,j -R_-r,τ,j . (18) I-H The algorithm and operational behavior Algorithm 1 summarizes the search, feasibility, arbitration, and commitment procedure. Only the selected action creates hard load; reservations remain soft and are recomputed whenever workflow information changes. Algorithm 1 ASGE-R 1: Precompute K policy-feasible paths per directed endpoint pair. 2: for event (tτ,eτ)(t_τ,e_τ) in timestamp order do 3: Release ended use; update traffic, observations, reservations. 4: if eτe_τ reveals an undispatched dependency call then 5: Clear r’s reservation; generate mapping/wait actions. 6: for action γ do 7: Search possible futures; set R=0R=0 if coverage is insufficient. 8: Compute Rrτ(γ)R_rτ(γ), C^rτβ(γ) C^β_rτ(γ); reject if a future is infeasible. 9: end for 10: Keep actions passing Eqs. (15) and (16). 11: while no action remains and a reservation is releasable do 12: Release the lowest-priority reservation; test again. 13: end while 14: if an action remains then 15: Choose minimum-score γ; commit its binding or queue wait. 16: else 17: Drop r; no action passes both tests. 18: end if 19: end if 20: end for I-I Safety guarantee and implementation complexity Since reservations in ASGE-R never consume capacity on their own, forecast errors may reduce performance. Still, they cannot violate capacity constraints, which provides a safety guarantee and is summarized in the following theorem. Theorem 1. If the initial hard calendar is feasible and realized demands stay within their declared bounds, every ASGE-R commitment satisfies capacity and policy constraints and preserves earlier bindings, independent of forecast accuracy. Proof. Induct on events. Release cannot increase load. Since reservations are nonnegative, Eq. (15) implies uγ,jℓ≤Sτ,jℓu_γ,j ≤ S_τ,j , so Eq. (11) preserves capacity. Candidate generation enforces policy; waits pass the same shifted calendar test; issued bindings never change. Reservations add no hard load, and an action that still cannot fit is dropped. Declared demand bounds prevent realized use from exceeding its booking. ∎ For complexity of Algorithm 1, let PpathP_path be path-precomputation cost, BdB_d the largest number of eligible replicas, and K the largest number of paths in each direction. Then B=BdK2+1B=B_dK^2+1 bounds the mapping and wait actions. Let Z be the number of retained suffixes, H the number of time slots, W the beam width, and L the number of nonzero resource-time entries per expansion. One candidate requires at most ZHWBZHWB beam expansions. Therefore, TdT_d call decisions with at most RcR_c reservation-release passes cost O(Ppath+TdRcZHWB2[L+log(WB)]). O\! (P_path+T_dR_cZHWB^2[L+ (WB)] ). (19) Working memory is O(ZWHL+NHL+BL)O(ZWHL+NHL+BL) for N active reservation profiles. Capacity and policy checks are exact for each generated current choice. IV Evaluation We evaluate ASGE-R in two complementary experimental environments: a controlled Docker testbed and a five-VM WAN testbed. We run fixed OpenHands and GPT Researcher runtimes and use the resulting AI-agent workflows in both setups. IV-A Real AI-agent runtimes and the pre-connection control point We run fixed OpenHands SDK 1.28.1 [19] and GPT Researcher 3.5.1 [20] versions on 28 public tasks chosen before seeing model results. OpenHands receives 14 repository tasks; GPT Researcher receives 14 public research questions. For each runtime, 4 tasks are used to train the forecasts and 10 to form the evaluation set. We use gpt-5.6-luna for model responses; GPT Researcher also uses text-embedding-3-small for embeddings. Fig. 3 summarizes the experimental replay pipeline. We first run each task with live model output and record when calls appear. After the run, we freeze the call sequence and exact request and response bytes. This creates a controlled workload on which we can run paired experiments: every compared controller receives the same workflow behavior. At the same time, each call remains hidden until replay reaches its release event. This replay pipeline allows us to isolate effects attributable to network policies rather than model variations in the AI-agent workflow responses. Firstly, we answer the question: Do real AI-agent workflows expose the pre-connection control point needed in ASGE? To answer the question, we performed a closer investigation on the runtimes of the 20 evaluation tasks, conducted from the pipeline in Fig. 3a. Results are presented in Fig. 4. All 20 evaluation tasks reveal at least one result-conditioned call that can be assigned to a replica and paths before connection (Wilson 95% interval 0.839–1.000). At the call level, this holds for 75/87 OpenHands calls and 19/37 GPT Researcher calls, for a total of 94/124. The needed control point and the proposed opportunity, therefore, exist: The network controller can wait until it knows what service the workflow needs, then select the replica and paths before connection. (a) Capture calls from live AI-agent tasksOpenHands14 public tasksGPT Researcher14 public tasksgpt-5.6-lunacalls appearduring executionfrozen replaypackageexact calls + bytesfreeze once; compare fairly(b) Replay the same workflows over a five-VM WANNurembergHelsinkicontroller hostruntime + gatewayCPX32relay ACPX12replica ACPX12replica BCPX12relay BCPX12alternativeselected mapping Figure 3: Main experimental pipeline. (a) We run public OpenHands and GPT Researcher tasks with gpt-5.6-luna, then freeze the resulting calls and exact bytes. (b) We replay each captured workflow under every controller over five VMs connected by real TCP paths between Nuremberg and Helsinki. As an example, Fig. 5 shows one measured decision. We choose the evaluation block with the median call count and use its frozen identifier to break ties, ensuring the selection is independent of the outcome. In that call replay, one OpenHands response completes at 2.910s2.910\,s. The next call appears 60.3ms60.3\,ms later. In the WAN experiment setup, the controller binds it to the Helsinki relay and a Nuremberg replica in 8.1ms8.1\,ms, and the gateway opens the connection 0.03ms0.03\,ms later. Figure 4: Runtime-revealed control opportunity. Each row reports the share of tasks with at least one result-conditioned call and the share of calls that are bindable before connection. Filled circles show task shares with 95% Wilson intervals; open squares show call shares. Labels give exact counts. Figure 5: Measured pre-connection control window. IV-B Validation under a controlled Docker environment Because reservations are central to ASGE-R, we next ask whether keeping a preferred replica-and-path mapping available for a likely later call actually reduces that workflow’s latency. We answer this question by comparing ASGE-R with a matched no-reservation controller. Both controllers receive the same calls, forecasts, measurements, available replicas, and paths. The no-reservation controller chooses the lowest-delay mapping for the current call but does not protect capacity between calls. We run fixed versions of OpenHands SDK 1.28.1 and GPT Researcher 3.5.1. For each, one task makes a later call only after processing an earlier response. Each trial pairs this task with a direct task from the other framework, which creates competing traffic before the later call appears. The runtime processes execute and communicate through a nine-container Docker network, as shown in Fig. 6a. The containers implement a gateway, the controller, two forward relays, two service replicas, two return relays, and an event recorder. Every dependency call uses a real HTTP connection through the gateway and the selected forward relay, service replica, and return relay. We deliberately replay the same responses in every comparison so that both controllers receive identical application inputs and responses. The OpenHands responses are recorded during gpt-5.6-luna executions; the GPT Researcher responses are prevalidated deterministic fixtures. The actual runtimes still issue, receive, and process every HTTP transaction, allowing us to attribute the measured difference to the network decision rather than model sampling. We test seven conditions: Moderate and high joint contention test the main mechanism at two load levels. Service-only and path-only contention separate the effects of replica queues and network paths. Abundant capacity and one legal mapping test cases in which there is no useful capacity choice to protect. Finally, a forecast miss measures the cost of reserving capacity for a call that never appears. One trial executes the complete workflow scenario under one controller. Two runtime pairings, seven conditions, two controllers, and ten repetitions give 280 trials. We repeat the entire experiment with the controller order reversed, yielding 560 runs in total. Reversing the order verifies that warm-up or changes in host conditions do not explain the result. Fig. 6b reports the results. Under moderate and high contention, ASGE-R reduces the workflow’s release-to-return latency by 1.45s1.45\,s and 4.31s4.31\,s, respectively. The service-only and path-only conditions produce reductions of 1.53s1.53\,s and 0.87s0.87\,s, showing that both replica queues and network paths can create an opportunity for reservations. The reversed-order experiment produces similar results. Under abundant capacity and with only one legal mapping, the intervals include zero: we detect no benefit when there is no useful alternative to protect. When the predicted later call does not appear, the unnecessary reservation instead delays the competing workflow by 0.46s0.46\,s. Figure 6: Controlled Docker environment. (a) The runtimes exchange HTTP transactions through nine role-separated containers. Before connection, the controller selects a forward relay, replica, and return relay. (b) ASGE-R minus matched no-reservation release-to-return latency across seven conditions. Negative values favor ASGE-R; the †forecast-miss row reports delay to the competing workflow. Each point summarizes 20 paired executions; bars show 95% bootstrap intervals and open squares reverse controller order. IV-C Evaluation under a WAN testbed environment IV-C1 The testbed Fig. 3b shows the setup of the testbed, which consists of a controller, two relay nodes, and two replicas, where the two relays are used to produce separate paths to the two replicas. Specifically, one CPX32 VM in Nuremberg runs the runtimes, which are replayed from the recorded runtime package, the gateway function, and the controller function. In addition, it is a recorder that records the performance. Two CPX12 relay VMs, one in Nuremberg and one in Helsinki, offer different paths. Two CPX12 service VMs in Nuremberg provide equivalent replicas. The controller chooses one of four relay-and-replica mappings before the gateway opens a TCP connection. Every request crosses VM interfaces and real TCP sockets, and Linux rate queues create contention from the paired workflow traffic. Two path contention levels are considered. A moderate-contention setting uses 4/8 Mbit/s rates for the two paths, respectively; the saturation setting uses 2/4 Mbit/s path rates. IV-C2 Confirmation of timing for control Recall the discussion about the pre-connection control point in Section IV-A. To confirm this in the WAN setup, we measure the timing breakdown of ASGE-R. The results for the moderate-contention case are shown in Fig. 7 for example. We also include the timing breakdown for the rolling-horizon controller (described in the next subsection) as additional evidence. The result shows about 5.0s5.0\,s of network transfer and queuing per moderate-contention replay, versus 1.18ms1.18\,ms of service time. ASGE-R and rolling horizon decide in 5.8 and 6ms6\,ms on average. The controller therefore acts quickly relative to the network delay, leaving an opportunity to make network decisions for the workflows. Figure 7: Where experimental time is spent (moderate contention). IV-C3 Performance comparison Figure 8: Controller effects across operating conditions and evaluation tasks. (a) Circles and horizontal lines show the order-balanced differences and paired 95% intervals; filled and open triangles show the two controller execution orders. (b) Each marker represents one evaluation block under moderate contention; stacked markers keep ties visible. Positive values favor ASGE-R. Blue marks positive differences, red negative differences, and gray ties or intervals with zero. In Fig. 8, we compare ASGE-R with two strong, complementary baselines. The rolling-horizon baseline follows the receding-horizon principle used in network control [12]. It gets the same forecasts and measurements as ASGE-R, re-optimizes the priority-weighted completion objective when a call appears, and releases its forecast protection between events. The CATS-style baseline represents established compute-aware traffic steering [15]. It treats each revealed call separately and selects the mapping with the earliest predicted finish. Rolling horizon tests whether retained reservations improve with repeated lookahead, while CATS tests whether workflow-aware control improves over strong current-call steering. We report results for three experimental conditions: moderate contention, saturation, and abundant capacity. Each of the 20 evaluation tasks defines one evaluation block, and each comparison uses the same blocks and two controller execution orders. Reversing the order helps separate controller effects from warm-up or changes in the hosts and network. An independently implemented checker validates the inputs, mappings, payloads, and deadline outcomes of every reported replay. Our primary metric is the fraction of offered workflows completed by the deadline. Each workflow has a value and contributes only if the entire workflow finishes on time. We pair controllers within each evaluation block and bootstrap the 20 blocks rather than treating individual calls as independent observations. Since the paired design holds the workflows, topology, forecasts, and configured capacity fixed across controllers, a potential gain of one controller over another, therefore, comes from the controller’s decisions. The results are summarized in Fig. 8. Fig. 8a shows the aggregate comparisons. Specifically, under abundant capacity, ASGE-R achieves no improvement. This is expected, because in this case, the two paths show no difference for ASGE-R to exploit. When this difference appears, the improvement emerges. Particularly, under saturation, compared with rolling horizon, ASGE-R changes from 5.0 points better in the first order to 2.5 points lower when the order is reversed. The order-balanced difference is therefore 1.25 points, with an interval that includes zero (−2.5-2.5–5.0). The order-balanced difference against CATS is also 1.25 points and includes zero (0–3.75). Under moderate contention, ASGE-R increases the fraction of workflow value completed by the deadline by 8.75 percentage points over rolling horizon (95% paired interval: 1.25–17.5) and by 10 percentage points over CATS (1.25–20.0). The two controller execution orders give rolling-horizon differences of 7.5 and 10.0 points, respectively. Fig. 8b shows where that gain occurs. Each of the 20 evaluation tasks defines one evaluation block. ASGE-R improves completed value in five blocks—four OpenHands blocks and one GPT Researcher block—ties rolling horizon in fourteen, and completes less value in one GPT Researcher block. These outcomes account for all 20 evaluation blocks. The gain concentration matches the proposed mechanism. Reservations can change an outcome only when a current choice would otherwise consume capacity needed by a later call from another workflow to complete by deadline. ASGE-R preserves that option and revises it when the later call appears, without changing workflow reasoning or calls already issued. V Related Work Service graphs and embedding. SFC already supports service graphs, cycles, stateful forwarding, policy, and dynamic paths [4]. ETSI VNF-FGs also represent graph and nested-graph services [5]. VNF orchestration and VNE map functions and edges onto substrates with limited compute and bandwidth [6, 7], including affinity, trust, and path constraints [8, 9]. Online VNE admits requests one by one as complete objects [10]. However, ASGE builds on the underlying infrastructure that has established network and resource placement and focuses on how to make use of them for workflows with runtime information. Most importantly, the service graph for a workflow in ASGE is unknown a priori, and consequently its embedding is dynamic and affected by any new call after the workflow has begun and earlier mappings have been committed. Uncertainty-aware embedding and predictive control. Stochastic VNE represents uncertain link demand with scenarios and recourse [11]. Model-predictive control (MPC) for SFC assurance uses a receding-horizon approach [12]. In contrast to ASGE-R, later calls are predicted while their identities remain unrevealed, and earlier calls remain committed. Priority and deadline control. Prioritized dynamic-SFC systems admit, place, and reconfigure known chains under shared capacity [13]. DCoflow admits and schedules coflows with deadlines [14]. ASGE-R instead uses a dynamic reservation-priority score that changes with workflow value, predicted on-time probability, urgency, and capacity for future calls. Steering and agent embedding. An individual ASGE mapping decision resembles Computing-Aware Traffic Steering (CATS), which uses compute and network metrics to select a service instance and overlay path [15]. The online ASGE setting is similar to that of AgentVNE, which maps agent nodes and virtual links under compute, memory, bandwidth, and affinity constraints and addresses topology changes [16]. Unlike them, the ASGE problem couples the mapping choices with fixed, earlier bindings, shared capacity, and deadline information. In addition, ASGE-R selects replicas and forward and return paths for dependency calls under hard endpoint and transit policy as execution unfolds. AI-agent serving and orchestration. To serve AI-agent workflows, many serving engines and orchestrators have emerged. AIALTO routes variable-fan-out outputs through stateful compound-AI pipelines [1]. Agentix schedules task graphs discovered at runtime [2], while Nalar supports changing invocations, managed state, and adaptive instance routing [17]. Murakkab co-optimizes workflows, models, and hardware. Maestro uses cross-cluster RTT, model readiness, and memory pressure [18, 3]. ASGE complements these systems by using runtime-revealed information to choose the replica and paths when a dependency call appears. VI Conclusion AI-agent workflows increasingly interact with distributed models, memory systems, and tools whose invocation patterns are revealed only during execution. This runtime uncertainty creates a new networking challenge. We formalized this challenge as Agentic Service Graph Embedding (ASGE) and introduced a complete-information benchmark, assuming that future workflow evolution is known. To address the online setting, we presented ASGE-R, an online ASGE controller that uses revisable reservations while preserving hard capacity and policy feasibility. The experimental results with replayed real AI-agent workflows indicated that runtime-revealed AI-agent calls create a practical opportunity for networks to complete more workflows by deadline using existing capacity. This more broadly suggests that network control for agentic systems should account for evolving workflow dependencies rather than optimize each call in isolation. Use of AI Disclosure Several AI tools were used in the experiments as introduced in the paper. In addition, OpenAI Codex was used to help implement ASGE-R for the experiments. The authors remain responsible for all the results. References [1] K. Santhanam, D. Raghavan, M. S. Rahman, T. Venkatesh, N. Kunjal, P. Thaker, P. Levis, and M. Zaharia, “ALTO: An efficient network orchestrator for compound AI systems,” in Proc. EuroMLSys, 2024, p. 117–125. [2] M. Luo et al., “Agentix: An efficient serving engine for LLM agents as general programs,” in Proc. 23rd USENIX NSDI, 2026, p. 2443–2459. [3] J. Wang et al., “Maestro: Workload-aware cross-cluster scheduling for LLM-based multi-agent systems,” arXiv:2606.12950, Jun. 2026. [4] J. Halpern and C. Pignataro, “Service Function Chaining (SFC) Architecture,” RFC 7665, Oct. 2015, doi: 10.17487/RFC7665. [5] ETSI, “Network Functions Virtualisation (NFV); Architectural Framework,” ETSI GS NFV 002 V1.2.1, Dec. 2014. [6] M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba, and O. C. M. B. Duarte, “Orchestrating virtualized network functions,” IEEE Trans. Netw. Service Manag., vol. 13, no. 4, p. 725–739, 2016. [7] N. M. M. K. Chowdhury, M. R. Rahman, and R. Boutaba, “Virtual network embedding with coordinated node and link mapping,” in Proc. IEEE INFOCOM, 2009, p. 783–791. [8] N. Bouten, R. Mijumbi, J. Serrat, J. Famaey, S. Latré, and F. De Turck, “Semantically enhanced mapping algorithmfor affinity-constrained service function chain requests,” IEEE Trans. Netw. Service Manag., vol. 14, no. 2, p. 317–331, 2017. [9] N. Torkzaban and J. S. Baras, “Trust-aware service function chain embedding: A path-based approach,” in Proc. IEEE NFV-SDN, 2020, p. 31–36. [10] G. Even, M. Medina, G. Schaffrath, and S. Schmid, “Competitive and deterministic embeddings of virtual networks,” Theor. Comput. Sci., vol. 496, p. 184–194, 2013. [11] B. Farkiani, B. Bakhshi, and S. A. MirHassani, “Stochastic virtual network embedding via accelerated Benders decomposition,” Future Gener. Comput. Syst., vol. 94, p. 199–213, 2019. [12] M. Avgeris, A. Leivadeas, N. Athanasopoulos, I. Lambadaris, and M. Falkner, “Model predictive control for automated network assurance in intent-based networking enabled service function chains,” in Proc. IEEE/IFIP NOMS, 2023, doi: 10.1109/NOMS56928.2023.10154316. [13] B. Farkiani, B. Bakhshi, S. A. MirHassani, T. Wauters, B. Volckaert, and F. De Turck, “Prioritized deployment of dynamic service function chains,” IEEE/ACM Trans. Netw., vol. 29, no. 3, p. 979–993, 2021. [14] Q.-T. Luu, O. Brun, R. El-Azouzi, F. De Pellegrini, B. J. Prabhu, and C. Richier, “DCoflow: Deadline-aware scheduling algorithm for coflows in datacenter networks,” in Proc. IFIP Networking, 2022, p. 1–9. [15] C. Li, Z. Du, M. Boucadair, L. M. Contreras, and J. Drake, “A framework for Computing-Aware Traffic Steering (CATS),” IETF Internet-Draft draft-ietf-cats-framework-24, Apr. 2026, work in progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-cats-framework/ [16] R. Zheng, Y. Zheng, Z. Cheng, L. Luo, H. Luo, G. Sun, H. Yu, and D. Niyato, “AgentVNE: LLM-augmented graph reinforcement learning for affinity-aware multi-agent placement in edge agentic AI,” arXiv:2601.02021, Jan. 2026. [17] M. Laju, D. Son, S. Agarwal, N. Kedia, M. Lee, J. Srinivasa, and A. Akella, “Nalar: An agent serving framework,” arXiv:2601.05109, Jan. 2026. [18] G. I. Chaudhry et al., “Murakkab: Resource-efficient agentic workflow orchestration in cloud platforms,” in Proc. 20th USENIX OSDI, 2026, to appear. [19] X. Wang et al., “OpenHands: An open platform for AI software developers as generalist agents,” in Proc. ICLR, 2025. [20] A. Elovic, “GPT Researcher,” GitHub repository, ver. 3.5.1, 2026. [Online]. Available: https://github.com/assafelovic/gpt-researcher