Nexus: An Execution Fabric for AI Agents Across Cloud, Edge, and Devices

Cary Chang; Jialin Zhou

cs.DCOct 5, 2026

Nexus: An Execution Fabric for AI Agents Across Cloud, Edge, and Devices

Authors: Cary Chang, Jialin Zhou

Organizations: Nexilume Research

Abstract

Language-model agents are evolving into long-running services that interact with models, tools, computers, mobile devices, and distributed environments. Existing agent frameworks simplify reasoning and tool invocation. However, cloud-centric designs face three limitations: centralized execution increases failure impact, scaling pressure, and compute cost; extending agents across computers, mobile devices, and edge environments requires a unified execution abstraction with permission control; and long-running executions require consistent lifecycle management across failures, recovery, results, usage, and settlement. We present Nexus, a cloud-edge platform that treats each invocation as a persistent task. Nexus uses an OpenWrt-based runtime for distributed serving, run-scoped delegation for authorized access to Computer and Mobile environments, and persistent records to track execution, outputs, failures, recovery, usage, and charging across cloud and edge components. We evaluate Nexus on controlled, cross-device, and model-driven workloads. All ten Computer-Android workflows succeed, and all six revocation tests block subsequent writes while preserving prior authorized reads. Under worker loss, journaling eliminates duplicate appends (six to zero per task), adding 0.933 s mean normal-path overhead. Across 24 matched task pairs, Nexus completes 24 tasks versus Dify's 22 and is a median 3.88 s faster on jointly successful pairs. In a separate workload, Nexus operates under a smaller tested incremental-runtime memory ceiling than Dapr (16 versus 64 MiB), although Dapr achieves lower successful-call latency. These results demonstrate how locality, operation-scoped authority, and persistent result identity support cloud-edge agent services with workload-dependent costs.

Figures & tables

Figure 1: Existing service, workflow, and recovery abstractions and their relationship to Nexus [ 5 , 6 , 1 , 2 , 3 , 4 , 7 , 8 ] . Nexus associates service reachability, authorized actions, and recorded outcomes with persistent invocations. Arrows show logical relationships. The Dify and Dapr experiments compare the corresponding workflow and service-invocation functions. Public IPv6 requires provisioned addresses and ingress permission; suppression of repeated external effects requires cooperating resources.

System	Relevant functionality	Comparison in this work
Dify [ 4 ]	Agent workflows and tool integration	Matched workflows using shared model and device tools.
Ray Serve [ 12 ]	Distributed application serving and replica management	Architectural context; not experimentally compared.
Istio / Envoy [ 14 , 15 ]	Service-traffic routing, security, and monitoring	Architectural context; not experimentally compared.
Dapr [ 6 ]	Service discovery and invocation	Matched invocation and constrained-memory experiments.
Portkey Gateway [ 16 ]	Model-provider routing, retries, and caching	Architectural context; not experimentally compared.

Table 1: Related system roles and the scope of empirical comparison in this work. Systems without a matched experiment provide architectural context.

Figure 2: System architecture and invocation lifecycle of Nexus . Cloud hosts agent deployments and manages service publication, invocation state, outputs, and accounting. OpenWrt makes edge-hosted agents discoverable and reachable. The SDK runs within each agent process and exposes interfaces for caller-authorized environment actions and execution reporting. Results and usage remain associated with the originating run. Agent-service routing and device-action dispatch are separate paths: OpenWrt reaches agent handlers rather than routing their commands directly to environment adapters. Arrows represent logical exchanges, not mandatory physical paths.

Figure 3: OpenWrt-native agent routing. (1) Time-limited registrations and route exchange maintain candidate endpoints and enable authorized calls between agents on different routers. (2) Identity and policy checks precede candidate filtering; only eligible routes are ranked and used to reach handlers through local, peer, public IPv6, or relay paths. (3) Reconnection uses retained task state and the original route, while router restart reconstructs service availability. These mechanisms recover access to services or retained executions, not arbitrary completed actions. Public IPv6 entry points require address provisioning and permitted incoming access.

Stage	Routing responsibility	Relationship to other components
Maintain service records	Register local services, expire old records, and exchange remote routes.	Cloud uses compatible registrations for service publication.
Forward invocations	Apply access rules and reach eligible handlers through configured paths.	Handlers use environment adapters to request separately authorized device actions.
Reconnect and rebuild	Reach retained tasks, resume available event histories, and reconstruct routing state.	Persistent action recovery, output retention, and settlement remain lifecycle responsibilities.

Table 2: Routing responsibilities and their relationship to the other components in the system overview.

Figure 4: Delegated agent interaction with caller-selected environments. (a) The same agent accesses a Computer workspace and a Mobile application through Cloud, which checks the applicable bindings and permissions. Computer establishes an outbound channel; Mobile retrieves commands through polling. (b) Repeated Computer commands reuse retained results without re-executing completed actions. (c) The evaluated Mobile client stores and retransmits completed results until acknowledgment, provided Cloud recognizes repeated reports as the same completion. The bottom strip identifies failures between an action taking effect and result retention, when completion can remain uncertain. Result replay requires retained state and valid authority; it does not replace run-level recovery.

Target	Action delivery	Execution and authority boundary
Computer	Device opens HTTPS setup and WSS command connections to Cloud.	Runs under a local user account; file operations use the configured workspace.
Browser	Actions use the selected Computer Runtime connection.	Actions stay on the selected Computer and are checked against stored observations.
Mobile	Android sends HTTPS requests for commands and reports results.	Caller/device grants, configured approval, and Android permissions govern actions.
Embedded	An explicit adapter exposes supported actions through a routed endpoint.	Each adapter defines its supported operations, transport, and errors.

Table 3: Environment-specific action paths. Connection direction identifies who establishes access, not the direction of subsequent messages. Embedded support is an adapter extension rather than a universal device implementation.

Input	Effect on execution
Reply	Answers a pending chat.ask and resumes the same handler in the current turn.
Steering	The handler accepts or rejects a caller instruction at a safe point; accepted changes affect subsequent actions in the current turn.
Queued request	Cloud admits a later turn after successful completion of the current turn and renewed access and pricing checks.

Table 4: User input and the execution it affects.

Identity / record	Responsibility and relationship
Run	Preserves caller scope and associates selected resources, conversation history, outputs, and usage across turns.
Turn	Identifies one admitted tool invocation, including its execution selection, usage, and applicable pricing terms.
Execution task	Tracks the run’s current execution, waiting, and recovery state; updated for subsequent turns rather than recreated for each message.
Worker attempt	Identifies an execution attempt and its assigned worker, separately from the persistent task and caller-visible status.

Table 5: Execution identities and records at different lifecycle scopes. A run can contain multiple turns, and a turn can involve multiple worker attempts; one execution task tracks the run’s current work.

Figure 5: Persistent agent service lifecycle and bounded accounting. (a) Replies continue the current turn; follow-ups require renewed admission, while reconnecting viewers read stored records without reinvoking the handler. (b) Recovery reuses completed results of SDK-recorded actions; a failure between an external effect and its completion record can leave the outcome uncertain. (c) In the illustrated successful reported-price turn, identical report retries are recognized while pending. Settlement separately finalizes the charge within the admitted limit and releases unused reserved funds. The email action and monetary amounts are illustrative.

RQ	Experimental comparison	Primary measurements
RQ1	The same task and request-arrival schedule in Cloud and at the edge; service lookup using an index that narrows the search versus checking every entry.	Smallest tested Cloud processor limit meeting the deadline; processor time and transferred bytes; lookup time and whether the selected service remains unchanged.
RQ2	Shared device-access functions versus explicitly constructed requests for the same operations; permissions retained versus withdrawn.	Correct files and device responses; association of commands with the original request; permission enforcement before subsequent actions; device-access code size.
RQ3	Recovery with and without stored operation records; resending stored results; preventing repeated actions at the service performing them.	Repeated actions; recovery of the original task and its results; additional time when no failure occurs; final charging outcomes.

Table 6: Research questions, experimental comparisons, and primary measurements.

Comparison	Shared conditions	Factors that vary
Edge / Cloud execution	Compiled task program, input data, output checks, and completion reporting; request-arrival schedule and Cloud processor limit in the capacity experiment.	Execution location, operating-system kernel, bridge version, connection path, and additional edge resources.
Bridge outside / inside Docker	Kernel, system image, programs and libraries, selected processor cores, requests, and resource-measurement method.	How the bridge is started and isolated from other processes.
Nexus / Dify workflows	Tasks, model source, action-selection instructions, maximum number of model decisions, device tools, and output checks.	Coordination of workflow steps, actions actually generated by the model, and handling of the remaining execution time.
Nexus / Dapr service calls	VM, target program returning the same bytes, and request schedule; equal total processor and memory limits in the memory experiment.	Call interfaces, how services are located and authenticated, and supporting processes. Latency and memory limits are tested separately.
SDK / explicit HTTP	Task code, selected devices, requests, permissions, and shared execution and recovery services.	Device-access code: SDK functions versus explicitly constructed HTTP requests.
Journal / no journal	Task steps, their execution pace, the point at which the execution process is stopped, the wait before task reassignment, and checks of outputs and actual actions.	Saving and reusing operation records. Handling repeated requests at the service performing an action is varied in a separate experiment.

Table 7: Shared conditions and varying factors in the principal comparisons.

Cloud CPU	Initial		Repeat
ceiling (vCPU)	Edge	Cloud	Edge	Cloud
0.25	4/4	0/4	4/4	0/4
0.5	4/4	1/4	4/4	3/4
1	4/4	3/4	4/4	3/4
2	4/4	4/4	4/4	4/4

Table 8: Cloud-capacity feasibility for the 16-MiB, 32-round workload. Each entry is passing batches out of four; each batch offers 20 tasks. Initial and repeated campaigns are shown separately, including all deadline misses.

Figure 6: Maximum planned-arrival-to-receipt latency of each large-input batch. The dashed line marks the two-second deadline, and horizontal jitter separates batches at the same CPU ceiling.

Task stratum	Both succeed	Nexus only succeeds	Total pairs
Calibration	6	0	6
Non-calibration	16	2	18
All tasks	22	2	24

Table 9: Paired workflow outcomes for Nexus and Dify. Calibration status is defined by task identity.

Figure 7: Completion time and model decisions in the 22 jointly successful pairs. The diagonal denotes equality, and markers distinguish calibration tasks. Table 9 includes the two other pairs.

Configuration	Exact/scheduled	Success p50 (ms)	Success p95 (ms)	RSS sum (MiB)
Dapr	207/216	1.239	2.655	292.26
Nexus	207/216	99.169	148.770	9.73

Table 10: Service-invocation results across both experiments. Latency is conditional on successful completion; RSS sums cover sampled product processes.

Worker	Journal	Exact outputs	Duplicate appends	Completion (s)
Healthy	Off	6/6	0.0	7.260
Healthy	On	6/6	0.0	8.193
Lost	Off	6/6	6.0	108.414
Lost	On	6/6	0.0	108.618

Table 11: Worker-loss ablation after committed-operation acknowledgment. Each row contains six Runs. Duplicate appends and completion times are per-Run means; all Runs retain their original identity and single settlement.

Recovery configuration	Final outputs	Caller retries	Duplicate effects
No journal	6/6	0	18
Guarded journal + caller retry	6/6	6	6
Reconciliation declaration only	6/6	0	6
Journal + resource deduplication	6/6	0	0

Table 12: Agent failure after an external effect but before its completion record. Duplicate counts are totals over six Runs per arm. The guarded configuration includes an explicit caller retry.

	Original completed		Next observation (s)
Condition	No outbox	Outbox	No outbox	Outbox
Healthy	2/2	2/2	0.82	1.19
Result loss	0/2	2/2	1.72	6.86
Acknowledgment loss	2/2	2/2	0.66	7.43
Result loss + process exit	0/2	2/2	4.27	5.74

Table 13: Original Android command completion and subsequent-command delay. Each condition contains two pairs. Subsequent-observation times are marginal medians in seconds.

Figure 8: Route-index ablation on OpenWrt. Left: median across trials of the 95th-percentile lookup latency as the route count increases. Right: median paired speedup based on mean lookup times, with 95% trial-bootstrap intervals. Workloads vary the number of candidates per requested capability, missing queries, expired routes, and query concentration. Both implementations use the same selection policy.

Appendix figures & tables106 assets

Supplementary material from the paper’s appendix.

Appendix

Source	Cloud ceiling	Edge batches	Cloud batches	Edge timely	Cloud timely
1 KiB	0.25	4/4	4/4	80/80	80/80
1 KiB	0.5	4/4	4/4	80/80	80/80
1 KiB	1	4/4	4/4	80/80	80/80
1 KiB	2	4/4	4/4	80/80	80/80
16 MiB	0.25	4/4	0/4	80/80	0/80
16 MiB	0.5	4/4	1/4	80/80	51/80

Appendix

Table 14: Deadline-constrained placement. Every batch schedules 20 tasks; each cell has four batches per mode. Passing requires all 20 exact, receipted tasks within two seconds of scheduled arrival. Edge / Cloud refer to processing location, while the CPU ceiling always applies to the Cloud workload.

Figure 9: Per-batch timely completion fraction (top) and maximum arrival-to-completion latency (bottom, logarithmic scale). The dashed line marks the two-second deadline; horizontal jitter separates repeated observations.

Cloud	Processing	Passing batches		Timely tasks
ceiling	location	Initial	Repeat	Initial	Repeat
0.25	Edge	4/4	4/4	80/80	80/80
0.25	Cloud	0/4	0/4	0/80	0/80
0.5	Edge	4/4	4/4	80/80	80/80
0.5	Cloud	1/4	3/4	51/80	77/80
1	Edge	4/4	4/4	80/80	80/80

Appendix

Table 15: Separate initial and repeat outcomes for the same 16 MiB stratum. Each campaign has four batches and 80 tasks per mode/ceiling. A passing batch requires all 20 exact outputs and receipts within two seconds.

Input / rounds	Cloud CPU (s)		Edge CPU (s)		Latency (ms)
	C	E	C	E	C	E
1 KiB / 1	0.080	0.040	0.030	0.030	16.4	26.4
1 KiB / 32	0.073	0.041	0.026	0.031	13.1	25.3
1 MiB / 1	0.483	0.039	0.086	0.054	60.3	24.4
1 MiB / 32	0.844	0.056	0.091	0.437	77.9	43.1
16 MiB / 1	5.806	0.052	0.851	0.323	659.5	43.1

Appendix

Table 16: Placement batch medians. CPU is measured at each endpoint for 20 attempts; latency is the median of batch-level median attempt durations, including failures. C/E denotes Cloud/edge execution location. Ten paired batches per row.

Figure 10: Endpoint CPU under Cloud and edge placement. Each point represents twenty attempted tasks, including the batch containing a failed task; bars mark medians. Both axes are logarithmic. K and M denote KiB and MiB.

Input	Digest rounds	Edge ms	Cloud ms	Cloud CPU saved s
1 KiB	1	26.36	16.38	0.040
1 KiB	32	25.35	13.14	0.035
1 MiB	1	24.41	60.33	0.443
1 MiB	32	43.10	77.92	0.792
16 MiB	1	43.12	659.50	5.759
16 MiB	32	334.82	984.24	11.102

Appendix

Table 17: Measured deployment tradeoff. Latency is ms; Cloud CPU saved is seconds per 20-attempt paired batch. Ten pairs per row.

Figure 11: Reanalysis of the deployment pairs. Each point is one batch pair; horizontal marks are cell medians. The three panels separate latency, Cloud CPU and total stack CPU. Lower latency differences favor the edge; positive CPU savings indicate fewer measured CPU seconds.

Figure 12: Sensitivity of the source-transfer cost component to assumed ingress prices and additional edge cost, for one digest round. Negative values indicate that additional edge cost exceeds the avoided source-transfer charge.

KiB	Deployment	Passed	Total(s)	Model(s)	CPU(s)	RSS(MiB)
1	OpenWrt/native	4/4	21.58	6.54	0.121	33.5
1	Cloud/Docker	4/4	24.11	9.63	0.135	79.7
64	OpenWrt/native	4/4	23.56	9.28	0.123	33.5
64	Cloud/Docker	4/4	21.47	7.15	0.146	79.7

Appendix

Table 18: Complete Agent deployment: four paired tasks per input stratum. Values are means. CPU is the handler process’s user+system time; peak RSS is the process lifetime value reported at completion, not a per-task allocation or whole-platform total.

Figure 13: Eight paired complete workflows. Lines connect the same task at the two execution locations. Model waiting and Agent CPU are reported separately; peak RSS is the process-lifetime maximum.

KiB	Placement	Passed	Task(s)	Window(s)	CPU(s)	Adjusted(s)
1	Native	4/4	18.70	19.04	22.99	15.57
1	Docker	4/4	22.60	22.98	25.21	9.58
64	Native	4/4	21.21	21.53	19.55	3.45
64	Docker	4/4	23.79	24.11	27.77	4.61

Appendix

Table 19: Resource measurements for four tasks per row. Values are means of client time, Cloud accounting-window duration, process-group CPU, and the modeled idle-adjusted CPU estimate. CPU seconds sum across processes.

Figure 14: Paired Cloud process-group CPU and idle-adjusted estimates. The latter retain negative values because sampled background work and model waiting contribute to the accounting interval.

Campaign	KiB	$\Delta T$ (s)	$\Delta M$ (s)	$\Delta(T-M)$ (s)
Initial	1	-2.530	-3.089	+0.559
Initial	64	+2.095	+2.124	-0.029
Repeat	1	-3.896	-3.401	-0.495
Repeat	64	-2.573	-2.704	+0.131

Appendix

Table 20: Mean paired native-minus-Docker differences, four pairs per row. Negative values mean less observed wall time on native. The final column is an arithmetic residual, not a causal deployment effect.

Figure 15: Wall-time decomposition of the initial and repeated placement experiments. Each bar averages four executions and separates measured model-request time from the arithmetic residual.

Family	Placement	Seen/planned	Task	Verified	GW	Time (s; n)	CPU (s; n)
Expenses	Native	4/4	4	4	20	24.06 (4)	0.077 (4)
Expenses	Docker	4/4	4	4	20	28.21 (4)	0.132 (4)
Inventory	Native	4/4	4	4	25	37.42 (4)	0.090 (4)
Inventory	Docker	4/4	4	4	24	31.45 (4)	0.143 (4)
Screen	Native	4/4	4	4	32	39.98 (4)	0.138 (4)
Screen	Docker	4/4	4	4	32	37.71 (4)	0.194 (4)

Appendix

Table 21: Controlled multi-step tasks. Task counts successful workflows; Verified additionally requires complete execution records. GW counts associated gateway records, including repeated calls. Times cover observed terminal outcomes, with the available sample size shown.

Figure 16: Execution of the three model-driven task families. Circles indicate task success, crosses indicate unsuccessful or unresolved outcomes, and labels show successful/observed Runs. RSS is the process-lifetime peak.

Payload	Concurrency	Native	Docker	Paired difference [interval]
1 KiB	1	0.971	1.037	+0.026 [-0.085, +0.175]
1 KiB	8	6.546	7.595	+0.639 [+0.274, +1.174]
64 KiB	1	0.925	1.035	+0.102 [+0.037, +0.168]
64 KiB	8	7.376	8.224	+0.846 [-0.001, +1.849]
1024 KiB	1	1.672	1.858	+0.160 [+0.083, +0.247]
1024 KiB	8	11.860	12.855	+1.187 [+0.338, +1.607]

Appendix

Table 22: Native/Docker request latency. Each value is the median of ten arm medians (ms). The last column is the median within-pair Docker-minus-native difference and its exploratory 95% percentile bootstrap interval.

Figure 17: All scheduled matched bridge observations. Lines join the two arms of one scheduling pair; labels K denote KiB. CPU and RSS are bridge-process measurements with the exclusions stated in the text.

		CPU seconds		Peak tree RSS (MiB)
Payload	Concurrency	Native	Docker	Native	Docker
1 KiB	1	0.765	0.890	2.715	2.666
1 KiB	8	0.645	0.815	9.170	9.150
64 KiB	1	0.740	0.910	1.801	1.793
64 KiB	8	0.740	0.875	8.299	8.668
1024 KiB	1	1.240	1.520	1.801	1.797

Appendix

Table 23: Median bridge CPU time per 2,000-request arm and median sampled peak process-tree RSS. Accounting excludes the daemon, driver, backend, and VM.

Platform	Routes	Index p95	Scan p95	Mean-time speedup
Windows	100	0.300	0.600	2.5 [2.4, 2.8]
Windows	1,000	0.400	6.250	20.4 [17.8, 22.0]
Windows	10,000	0.950	193.600	250.4 [209.4, 274.9]
Windows	50,000	2.150	3397.700	1773.3 [1336.6, 1964.3]
OpenWrt VM	100	0.371	1.051	3.1 [2.8, 3.3]
OpenWrt VM	1,000	0.544	9.619	18.3 [15.6, 20.1]

Appendix

Table 24: Within-platform index ablation. p95 entries are medians across ten paired trials (microseconds). Speedup is the median paired mean-time ratio with a trial-bootstrap 95% interval.

SDK re-registration	Recovered arms	Successful fresh probes	Censored
Disabled	0/6	0/900	6
Enabled	6/6	890/900	0

Appendix

Table 25: Six matched OpenWrt restart pairs. Fresh probes start after the service action returns; baseline probes are excluded from these counts. Unrecovered controls are censored at the observation bound.

Figure 18: Re-registration after router restart. Each point is one arm in six pairs; bars mark means. Recovery time begins when the restart action returns. Recovery times are shown only for arms that recover within the observation window.

Candidate	Accepted	Successful probes	Degraded	Diagnostic restored
Invalid	0/6	540/540	6/6	6/6
Valid	6/6	540/540	0/6	6/6

Appendix

Table 26: Static-route update scenarios: six attempts per candidate condition. The same dynamic route is retained across hot reload. Successful probes include static and dynamic calls before, during, after and following restoration.

Routes	Reflector	Oracle arms	Published at C	Recovered at C	Bound (s)
4	Off	4/4	0/16	0/16	—
4	On	4/4	16/16	16/16	1.295
32	Off	4/4	0/128	0/128	—
32	On	4/4	128/128	128/128	1.576

Appendix

Table 27: Route state at the destination peer. Each row contains four arms. Expected-state counts include absent routes in the reflection-disabled control; publication and recovery use all source routes as denominators. Recovery time is the median observed bound for reflection-enabled arms.

Figure 19: Time from the reflection action to the first complete destination route-set observation. Measurements include management operations and polling. Reflection-disabled arms have no available destination route and therefore no recovery-time point.

Candidate domain	Admission	Discovered	Peer	Route	Verified
Same	Off	4/4	0/4	0/4	4/4
Same	Same-domain	4/4	4/4	4/4	4/4
Other	Off	4/4	0/4	0/4	4/4
Other	Same-domain	4/4	0/4	0/4	4/4

Appendix

Table 28: Four discovery arms per cell. Verified includes policy-consistent rejection; usable routes are counted separately. Route validation matches identity, tenant, peer origin, and path vector.

Figure 20: Discovery and admission outcomes. The right panel shows observed stage intervals for the four eligible same-domain automatic-admission arms.

Admission	Phase	Probes	Route found	Backend verified
Off	Before	8	0	0
Off	Available	8	0	0
Off	Expired	8	0	0
Off	Recovered	8	0	0
Same-Domain	Before	8	0	0
Same-Domain	Available	8	8	8

Appendix

Table 29: Each cell includes four arms and both directions. No-route observations are policy/lifecycle outcomes and are not counted as successful executions.

Figure 21: Directional invocation outcomes. Successful execution requires both HTTP completion and a matching backend receipt.

Path	Success	Calls	Median (s)	Median CPU (s)
Peer tunnel	8/8	48	10.023	0.0853
Direct HTTP	8/8	48	9.523	0.0808

Appendix

Table 30: Real Agent peer/direct comparison. End-to-end times include six model decisions per arm; resource samples cover both logical nodes.

Figure 22: Eight peer/direct pairs with fresh execution and equal model-call counts. Labels identify direction, task family, and input size.

KiB	Path	Exact/attempts	All s	Exact s	Ready s
1	IPv6	3/4	0.726	0.776	34.043
1	Relay	4/4	0.831	0.831	37.290
16	IPv6	4/4	0.677	0.677	33.873
16	Relay	0/4	1.116	–	37.152
32	IPv6	4/4	0.684	0.684	33.693
32	Relay	0/4	0.792	–	35.021

Appendix

Table 31: Production transport requests. Durations are median seconds; “All” includes failed attempts, “Exact” includes only independently verified outputs, and “Ready” is untimed registration waiting. A dash means no exact output.

Figure 23: Application delivery by body size. Crosses identify failed attempts; the second panel reports exact-output fractions.

KiB	Path	Exact/attempts	Exact median s	$\Delta$ s
1	IPv6	4/4	0.647	–
1	Relay	4/4	0.786	+0.139
4	IPv6	4/4	0.651	–
4	Relay	4/4	0.810	+0.163
7	IPv6	4/4	0.710	–
7	Relay	4/4	0.739	+0.029

Appendix

Table 32: Repaired common-bound deployment. Median seconds include only exact outputs; all attempts remain in the success denominator.

\Delta

is the median Relay-minus-IPv6 difference over complete exact-output pairs, not the difference of the two marginal medians.

Figure 24: Stream-local rejection and bounded transport delivery. Left: scenario outcomes. Right: individual attempt durations, with crosses identifying failures.

Payload	Conc.	IPv6 valid	Relay valid	Latency (ms)	Goodput (/s)
1 KiB	1	128/128	128/128	577.5 / 770.6	1.73 / 1.29
1 KiB	4	128/128	128/128	1501.1 / 2460.4	2.62 / 1.60
7 KiB	1	128/128	128/128	647.5 / 835.5	1.54 / 1.16
7 KiB	4	128/128	128/128	982.7 / 1495.9	3.96 / 2.67

Appendix

Table 33: Finite application batches. Each cell schedules 128 calls per path. Latency is the median of four batch medians; goodput is the median of four batch values. Paired columns show IPv6 / Relay.

Figure 25: Per-batch completion and timing summaries, with four batches per path and workload cell.

Path	Verified/scheduled	p50 (ms)	p95 (ms)	RSS sum (MiB)
Direct HTTP	216/216	0.144	0.346	—
Dapr	207/216	1.239	2.655	292.26
Nexus	207/216	99.169	148.770	9.73

Appendix

Table 34: Two fixed external-baseline campaigns. Latency is conditional on a verified successful request; failed calls remain in the success denominator. RSS sums include all product processes but can double-count shared mappings.

Figure 26: Successful-call latency and sampled process RSS in the two service experiments, on logarithmic axes. The direct-HTTP reference has no intermediary product process; its caller and backend lie outside this RSS series.

MiB	N complete	D complete	N calls	D calls	OOM N/D
16	2/2	0/2	36/36	0/36	0/2
32	2/2	0/2	36/36	0/36	0/2
64	2/2	2/2	36/36	36/36	0/0
128	2/2	2/2	36/36	36/36	0/0
256	2/2	2/2	36/36	36/36	0/0

Appendix

Table 35: Equal enforced memory budgets. N/D denote Nexus/Dapr; a complete arm finishes both warmups and all 18 measured calls. Startup failures count as uncompleted scheduled requests. Kernel OOM counts refer to arms.

Figure 27: Completed workloads under equal incremental-runtime memory ceilings. Twenty arms cover five ceilings and two opposite-order pairs per ceiling.

Implementation	Success	Non-calib.	Attempt p50 (s)	Calls	Invalid
Nexus SDK	24/24	18/18	25.06	159	9
Dify + shared tools	22/24	16/18	31.10	168	15

Appendix

Table 36: Nexus and Dify workflow outcomes. Non-calibration counts cover the nine tasks not used to revise the prompt. Attempt duration includes successful and failed termination; model calls and invalid actions include failed decisions.

Input	Adapter	Exact output	End-to-end	Handler	Requests
1 KiB	SDK	4/4	12.797	6.335	21–25
1 KiB	HTTP	4/4	13.088	6.664	23–25
64 KiB	SDK	4/4	13.051	6.553	23–25
64 KiB	HTTP	4/4	13.047	6.192	21–28

Appendix

Table 37: Resource integration. Times are seconds; medians cover four Runs per row. Request counts cover the instrumented handler through readback, before final output publication, rather than all platform traffic.

Figure 28: Paired SDK-minus-HTTP duration differences. Positive values indicate longer SDK execution.

Input	Adapter	Exact output	End-to-end	Handler	Requests
1 KiB	SDK	4/4	15.474	8.382	39–41
1 KiB	HTTP	4/4	13.924	7.222	37–40
64 KiB	SDK	4/4	14.466	7.685	34–41
64 KiB	HTTP	4/4	14.723	6.852	35–39

Appendix

Table 38: Active-journal resource integration. Each row contains four Runs; times are median seconds. Request counts use the pre-publication boundary defined in Table 37 .

KiB	Adapter	Exact/attempts	Workflow s	Model s	Handler s
1	SDK	4/4	30.825	8.675	9.412
1	HTTP	4/4	27.374	5.586	9.106
64	SDK	4/4	30.924	9.572	8.228
64	HTTP	4/4	30.221	9.574	9.187

Appendix

Table 39: Real Qwen workflow comparison. Four independent arm executions per row. Times are medians over attempted workflows, in seconds. “Model” sums two inference calls; “Handler” measures inside the hosted composite tool.

Figure 29: Paired SDK-minus-HTTP differences in end-to-end, model-request, and composite-tool time. Each point represents one independently executed workflow pair.

Condition	Path	Successful	Time (s)
Healthy	Device API	10/10	4.872
Healthy	Agent delegate	10/10	15.236
10-s loss	Device API	10/10	14.799
10-s loss	Agent delegate	10/10	15.441

Appendix

Table 40: Same-device workflow outcomes. Completion requires both successful termination and the independent Settings oracle. Time is the median among successful attempts.

Target idle (s)	Actual idle (s)	Completion (s)	Commands	Oracle
60	62.607	16.636	2	Pass
600	601.205	10.020	2	Pass
3600	3601.081	11.714	2	Pass

Appendix

Table 41: One observed run per idle interval; scenario outcomes without statistical intervals.

Input	Pairs	Chat median (s)	Tool median (s)	Paired median (s)
1 KiB	10	10.634	9.239	0.702
64 KiB	10	9.320	8.420	0.955

Appendix

Table 42: Same-Computer API comparison. All 40 attempts completed and passed the independent artifact oracle. Paired differences are chat minus tool.

Figure 30: Left: route eligibility with and without lease renewal, with ten sampled traces per arm. Right: paired Computer workflows with and without a ten-second Runtime interruption.

Path	Successful	Failed	Median time (s)
Device API	10/10	0	11.590
Agent delegate	10/10	0	20.665

Appendix

Table 43: Real Qwen-driven micro-workflow. Ten attempts per adapter (five task paraphrases, two repeats).

Figure 31: Successful workflow completion times, with one point per execution and median bars. Left: the deterministic device task under healthy and interrupted connectivity. Right: fresh Qwen requests around the same device task. Tables retain all attempt denominators.

Condition	Observed outcome	Count
Full grant / restored grant	Run completes, exact artifact	3/3 each
Missing write permission	Run fails, read occurs, no write	3/3
Grant revoked before submission	Run fails, no device command	3/3
Valid Display proof	HTTP 200, intended Run visible	3/3
Missing / wrong-Run / tampered proof	HTTP 404, no Run payload	3/3 each
Wrong tenant with valid proof	HTTP 404, no Run payload	3/3

Appendix

Table 44: Authorization scenarios with three repetitions per row. Outcomes distinguish action execution from permission-consistent refusal.

Condition	Completed at window end	Old token rejected	Auth failure	Final success
Retain	6/6	0/6	0/6	6/6
Rotate	0/6	6/6	6/6	6/6

Appendix

Table 45: Android credential intervention, six arms per condition. Completion after re-pairing concerns the same queued command; it is explicit repair, not automatic retry.

Condition	Original complete	Unresolved	Fresh work	Clicks: initial to final
Healthy	6/6	0/6	6/6	6 to 6
Result lost	0/6	6/6	6/6	6 to 12
Acknowledgment lost	6/6	0/6	6/6	6 to 6

Appendix

Table 46: Android effect/result boundary, six attempts per condition. Original command state is distinguished from successful new work. Only the result-lost condition subsequently issues an explicit new Apply command.

	Original completed		Fresh observe (s)
Scenario	Baseline	Outbox	Baseline	Outbox
Healthy	2/2	2/2	0.82	1.19
Result loss	0/2	2/2	1.72	6.86
ACK loss	2/2	2/2	0.66	7.43
Result loss + process exit	0/2	2/2	4.27	5.74

Appendix

Table 47: Android receipt-recovery outcomes, with two pairs per condition. Completion refers to the original command; subsequent-observation time is median created-to-completed duration in seconds.

Figure 32: Original-command recovery and the delay of subsequent observations. Points are individual durations and horizontal marks are medians of two observations.

Condition	Completed	Deliveries	Stable object	Median (s)
Healthy	8/8	8	8/8	7.854
Result lost	8/8	32	8/8	24.001
Result lost + process restart	8/8	32	8/8	23.698
Acknowledgment lost	8/8	8	8/8	9.256

Appendix

Table 48: Computer file workflow, eight attempts per condition. Deliveries count repeated transmission of the same write command. Stable object means the post-write file identity and timestamps match every later result and the final artifact.

Figure 33: Computer workflow completion times under the specified result-loss and restart conditions. Lines connect the same experimental block, not successive time points. The result-loss gate lasts twelve seconds.

Condition	Current-plan effect	Rejected	Stale-plan effect
Fresh observation and plan	2/2	0/2	0/2
Old R1 after R2	0/2	2/2	0/2
Expected revision omitted	0/2	0/2	2/2
DOM changed, no new snapshot	0/2	0/2	2/2

Appendix

Table 49: Initial page-action effects in the scheduled revision comparison, two attempts per condition. Stale-intention effects apply B although the retained intention is A. Recovery effects are reported separately.

Figure 34: Initial page effects and endpoint-availability outcomes. The left panel precedes authorized recovery; the right panel reports completed browser operations and explicit offline refusals.

Figure 35: Viewport observations before selection change and after the unguarded action. The Agent retains intention A while the independent page-effect record identifies B. The displayed regions preserve the captured pixels.

Outcome	Initial experiment	Instrumented repeat
Scheduled Runs observed	14/14	14/14
Old-snapshot actions rejected	2/2	2/2
Authorized recovery effects	1/2	2/2
Explicit offline-open refusals	1/2	2/2
Available workflows completed	2/2	2/2
New Runs after restoration completed	2/2	2/2

Appendix

Table 50: Browser outcomes in the initial experiment and the instrumented repetition. Each experiment has fourteen conditions, including two opportunities for authorized recovery and two for offline refusal.

Interactive effect	Nexus PTY	Pipe control
Child receives TTY and foreground group	2/2	0/2
Requested dimensions observed in child	2/2	0/2
Ctrl-C interrupts the waiting child	2/2	0/2
Subsequent command in original shell	2/2	—
Retention effect	Reattach original	Close and recreate
Same shell PID/session retained	2/2	0/2

Appendix

Table 51: Independent effects in the corrected eight-condition repetition. Each column has two scheduled opportunities. A dash denotes an outcome not requested by that workload, rather than a failure.

Worker	Journal	Outputs	Appends	Duplicates	Completion (s)
Healthy	Off	6/6	6.0	0.0	7.260
Healthy	On	6/6	6.0	0.0	8.193
Lost	Off	6/6	12.0	6.0	108.414
Lost	On	6/6	6.0	0.0	108.618

Appendix

Table 52: Real worker-process loss and journal ablation: six attempts per cell. Times and duplicate counts are means; no model is called. Every completed task is charged once at 0.050000 synthetic USD.

Figure 36: Repeated appends and total completion time under worker loss. Points show individual Runs and bars show means.

Arm	Final outputs	Pauses	Effect rows	Duplicates
No journal	6/6	0	54	18
Guard + caller retry	6/6	6	42	6
Reconciliation flag alone	6/6	0	42	6
Journal + resource idempotency	6/6	0	36	0

Appendix

Table 53: Agent-process loss after the stage-three external commit. Six attempts per arm; effect and duplicate counts are totals across that arm. The guarded arm completes only after an explicit caller retry.

Figure 37: Repeated external effects after Agent failure at the effect/recording boundary. Points show individual Runs and bars show means. The guarded arm includes a subsequent caller retry.

Tariff	Total stages U/C	Post-return U/C	$\Delta$ terminal (ms)	95% interval
Fixed	12/3	8.17/0	-1206.8	[-1279.6, -1139.6]
Reported	12/3	8.67/0	-1309.3	[-1338.6, -1280.7]

Appendix

Table 54: Active cancellation, six pairs per tariff. U: unchecked handler; C: cooperative handler. Stage counts are scenario outcomes. Timing is the paired mean difference C

-

U, with an exploratory 95% pair-bootstrap interval.

Figure 38: Residual local effects and termination after cancellation. Points show individual attempts and bars show means.

Text (B)	Cut event	Replay (B)	Cursor (B)	Reduction	Duplicates R/C
64	4	7,631	6,791	11.0%	4/0
64	16	10,165	6,791	33.2%	16/0
4,096	4	152,783	135,815	11.1%	4/0
4,096	16	203,701	135,815	33.3%	16/0

Appendix

Table 55: Consumed SSE bodies across initial and reconnect responses. Every direct and bridge repetition has the shown count; timing is analyzed separately.

Figure 39: Incremental stream delivery. Left: consumed SSE bodies, with overlapping points for identical direct and bridge counts. Right: median paired completion-time difference, cursor minus full replay, and 95% intervals from 5,000 pair-bootstrap resamples. Each timing cell has ten pairs.

Fault	Reconnect policy	Outputs	Producer starts	Duplicate appends
Process replacement	Full replay	6/6	12	72
Process replacement	Cursor	0/6	6	0
Retention expiry	Full replay	6/6	12	72
Retention expiry	Cursor	0/6	6	0

Appendix

Table 56: Recovery after history loss, with six attempts per row. Counts include the original execution and any replacement. Duplicate appends count repeated business stages rather than repeated event delivery.

Protocol	Text (B)	Cut event	Replay (B)	Cursor (B)	Reduction
MCP	64	4	5,514	4,450	19.3%
MCP	64	8	6,578	4,450	32.4%
MCP	4,096	4	86,154	68,962	20.0%
MCP	4,096	8	103,346	68,962	33.3%
A2A	64	4	9,624	8,036	16.5%
A2A	64	8	11,388	8,036	29.4%

Appendix

Table 57: Native-ingress consumed SSE bodies. Every repetition in a cell has these byte counts. Both arms reconstruct the same business output; duplicate delivered events are cut/zero for replay/cursor.

Figure 40: MCP/A2A ingress through the OpenWrt adapter. Left: median paired SSE-body reduction. Right: median paired completion-time difference and exploratory 95% intervals from 5,000 pair-bootstrap resamples, with ten pairs per cell.

SDK	Path	Handles	Correct workers	Calls
Original	Direct	2/2	2/2	8
Original	Peer	0/2	2/2	8
Candidate	Direct	2/2	2/2	8
Candidate	Peer	2/2	2/2	8

Appendix

Table 58: Asynchronous admission across both directions. Each worker executes four model decisions. Correct worker output and a usable caller-held task handle are counted separately.

Figure 41: Original-handle observation during peer interruption. Amber marks unavailable observation while the worker continues; green marks the validated result.

Condition	Store	Admitted	Correct	Handles	Calls
Lookup	Previous	2	2	1	8
Lookup	Candidate	2	2	2	8
Overflow	Previous	3	3	1	12
Overflow	Candidate	2	2	2	8

Appendix

Table 59: Capacity scenarios. A correct worker artifact and a usable completed task handle are separate outcomes. The candidate’s refused third task is not counted as a completed task.

Condition	Workers	Correct	Results	Records	Calls
Intact	2	2	2	2	8
Lost, no replay	2	2	0	2	8
Lost, active replay	2	2	0	4	8
Lost, completed replay	2	2	2	4	8

Appendix

Table 60: Two directions per receipt condition. “Results” counts caller-held handles returning the completed application result. Control records include lost and rejected-replay records; they are not distinct business executions.

Submission mode	Runs	Ready at return	Final correct	Invocations
Worker-dispatched queue	4	4/4	4/4	8
Explicit continuation	4	0/4	4/4	8

Appendix

Table 61: Four matched pairs. Readiness means the independently verified second-turn result already exists at client return, before any manual resume.

Scenario	Successful	Median time (s)
Hash output	10/10	7.515
Solicited reply	10/10	8.915
Cooperative steering	10/10	10.950

Appendix

Table 62: Hosted output, reply, and steering scenarios, with ten Runs per pattern.

Figure 42: Server-side event persistence and client-observed workflow completion for ten Runs per interaction pattern.

Scenario	Terminal outcome	Charge (USD)
Fixed-price successful digest	Completed	0.050000
Reported-price successful digest	Completed	0.032100
Successful digest, missing report	Completed	0.050000
Report followed by handler failure	Failed	0.000000
Same report submitted twice	Completed	0.032100
Over-cap report attempted through SDK	Failed	0.000000

Appendix

Table 63: HTTP–worker–SDK accounting scenarios. Each accepted call reserves 0.050000 synthetic USD; all reservations are released at termination.

Figure 43: Left: same-Computer admission-path durations. Right: reserved and charged synthetic amounts in the separate PostgreSQL component experiment.

Task	Client	Exact	Client s	Server s	Reply reaction s
Hash	WEB	4/4	11.160	6.002	0.000
Hash	API	4/4	9.175	8.688	0.000
Confirm	WEB	4/4	19.814	15.780	2.809
Confirm	API	4/4	11.230	10.530	0.000

Appendix

Table 64: Matched invocation, four pairs per task family. All 16 attempts complete with exact results and zero configured charge. Times are marginal medians in seconds; client and server medians have different boundaries.

Figure 44: Paired API and Web durations. Client time includes observation and confirmation response; server time includes scheduling and interaction but excludes browser presentation.

Figure 45: Browser view of a completed 1,024-byte digest workflow, including its result, execution plan, and zero-charge settlement.

Scenario	Pairs	Run status	Charge	Billing state
missing report	2	completed	0.050000	missing
reported failure	2	failed	0.000000	released
fixed success	2	completed	0.050000	captured
reported success	2	completed	0.032100	captured
over cap	1	failed	0.000000	released
duplicate report	1	completed	0.032100	captured

Appendix

Table 65: Paired nonzero settlement. Expected failures are part of the fixed protocol. Each listed amount is per independently executed Run, in synthetic USD; both clients agree.

Figure 46: Allocation of synthetic experimental funds. Publisher and platform shares sum to the consumer debit.

Figure 47: Browser view of successful execution without a final cost report. The missing report status coexists with the settled authorized charge of 0.05 synthetic USD.

Path	Initialize/list	Client success	Progress callbacks	Producer complete
FastMCP transport	8/8	8/8	128	8/8
Native adapter	8/8	0/8	0	1/8

Appendix

Table 66: Standard-client tool invocation across eight fresh sessions per path. Producer completion is measured independently of client-visible completion.

Campaign	Path	Client success	Progress	Producer complete
Original	Direct FastMCP	8/8	128	8/8
Original	Installed adapter	0/8	0	1/8
Rebuilt original	Direct FastMCP	8/8	128	8/8
Rebuilt original	Control adapter	0/8	0	1/8
Corrected	Direct FastMCP	8/8	128	8/8
Corrected	Candidate adapter	8/8	128	8/8

Appendix

Table 67: Standard-client outcomes for the initial and revised adapter configurations, with separate initial, repeated, and build-controlled experiments.

Fault	Size	Policy	PUT bodies	Download	Time
Download	2	restart	2.00	2.25	8.921
Download	2	resume	2.00	2.00	8.216
Download	4	restart	4.00	4.25	7.607
Download	4	resume	4.00	4.00	7.548
Upload	2	restart	5.00	2.00	10.107
Upload	2	resume	4.00	2.00	9.677

Appendix

Table 68: File-transfer outcomes. File size, PUT bodies, and delivered data are in MiB; end-to-end time is in seconds. All eight outputs match their expected content.

Figure 48: Observed bytes in the affected transfer direction for all four pairs. Continuation preserves the already accepted or delivered prefix. The plotted values are recomputed from the retained request and read records.

Format	KiB	Adapter	Exact	Expected	Reused	Time
Binary	64	SDK	2/2	2/2	0/2	10.455
Binary	64	HTTP	2/2	2/2	0/2	9.592
Text	64	SDK	2/2	2/2	2/2	8.578
Text	64	HTTP	2/2	2/2	2/2	9.509
Binary	1024	SDK	2/2	2/2	0/2	9.640
Binary	1024	HTTP	2/2	2/2	0/2	9.385

Appendix

Table 69: Scheduled private-file workflow observations. Completion includes an independent output digest; reuse is evaluated under the scanner policy. Expected denotes the predeclared complete workflow oracle (including binary reuse denial); Reused counts accepted references. Time is the median invocation-completion time in seconds for two observations per row, excluding caller preparation and post-completion validation/scan.

	Exact outputs		Full outcomes
Input	Initial	Repeat	Initial	Repeat
64 KiB text	4/4	4/4	4/4	4/4
1 MiB text	4/4	4/4	2/4	2/4
64 KiB binary	4/4	4/4	4/4	4/4
1 MiB binary	4/4	4/4	4/4	4/4

Appendix

Table 70: Exact-input file-workflow replication. Full outcomes include the original scan/reference policy, not only correct transformation. Unsupported binary rejection is an expected control. Each cell has four Runs.

KiB	Input source	Exact	PUT KiB	Prepare s	Continue s
64	Reference	2/2	0	0.226	9.705
64	Upload	2/2	128	1.580	8.524
1024	Reference	2/2	0	0.178	9.162
1024	Upload	2/2	2048	0.757	10.161

Appendix

Table 71: Continuation after output preparation. PUT bytes are summed caller upload bodies for second-turn admission; times are medians in seconds. Each row contains two Runs. Application execution still transfers files between the Agent and Cloud in both arms.

KiB	Capture	Reupload	Capture (s)	Reupload (s)	Avoided KiB
64	4/4	4/4	0.250	0.305	128
1024	4/4	4/4	0.296	0.715	2048

Appendix

Table 72: Archive comparison. Counts are verified operations; times are means over four operations. Reupload time includes source download and import. Avoided KiB is caller artifact-body traffic per pair, excluding metadata, multipart framing and equal verification traffic.

Figure 49: Caller artifact-body traffic and archive duration. The metric excludes metadata, shared scan preparation, version administration, and verification reads.

Selector	Headers	Calls	Lineage	Usage	Tokens	Time
Pool	NONE	4/4	4/4	0	118/33	1.599
Pool	SDK	4/4	4/4	4	118/33	1.627
Router	NONE	4/4	4/4	0	118/33	1.656
Router	SDK	4/4	4/4	4	118/33	1.643

Appendix

Table 73: Single-source Qwen requests, with four common tasks per row. Lineage matches source and usage records; Usage counts Run-attributed records. Tokens are reported input/output totals, and time is median model-request duration excluding admission and polling.

C	Policy	Sent/planned	Match	Differ	Success	Correct	Mean (s)
1	A first	4/4	4	0	4	4	2.114
1	Withdraw A	4/4	4	0	4	4	5.869
1	Weight A=0	4/4	4	0	4	4	2.851
1	Rollback	4/4	4	0	4	4	3.850
1	Order A=0	4/4	0	4	4	4	3.613
2	A first	4/4	4	0	4	4	2.118

Appendix

Table 74: Policy-controlled selection. Match, Differ, and Unknown describe source choice; Success describes inference and Correct describes task output. Mean duration is conditional on a successful response. Experiments 1 and 2 use the initial and zero-preserving implementations.

Figure 50: Source selection and request duration for each policy. Circles indicate successful inference; crosses indicate unsuccessful or unresolved requests.

Deployment	Baseline (s)	Post-idle (s)	Verified	Gap (s)
OpenWrt native	19.30	20.33	2/2	7251.9
Cloud Docker	18.32	26.44	2/2	7203.1

Appendix

Table 75: Complete workflows before and after inactivity. Gap spans baseline terminal observation to post-idle submission for each placement, including the other placement’s scheduled execution. There is one workflow per cell.

Figure 51: Completion times before and after the command-idle interval. Each point represents a complete workflow with model requests and device operations.

Figure 52: Cloud capacity and conditional expenditure reduction. Left: tested passing ceilings in the initial and repeated experiments. Right: analytical sensitivity to allocation conversion and additional edge cost for the 16-MiB workload; these coordinates are assumptions rather than measured charges.

Explore similar work

May 26, 2026cs.AI

Agyn: An Open-Source Platform for AI Agents with Scalable On-Demand Execution, Agent Definition as a Code, and Zero-Trust Access

As organizations move toward production deployments of AI agents, which execute non-deterministic workflows, maintain stateful sessions, and often operate with privileged access to internal services, the engineering challenge shifts from building individual agents to operating them at scale with proper isolation, governance, and security. In this paper we present Agyn, an open-source platform designed around three key principles tailored for agent workloads: a signal-driven, stateful serverless runtime on Kubernetes; a Terraform provider for agent and harness definition; and a security model grounded in zero-trust and least-privilege principles. Agyn is agent-agnostic, model-agnostic, and cloud-agnostic.

Nikita Benkovich, Vitalii Valkov

Agyn, Inc. · Mila AI e-Lab

Agentic Deployments Kubernetes Artificial Intelligence Agents Cloud Scalability Open-Source

Ask PDF

Apr 22, 2026cs.LG

A Delta-Aware Orchestration Framework for Scalable Multi-Agent Edge Computing

The Synergistic Collapse occurs when scaling beyond 100 agents causes superlinear performance degradation that individual optimizations cannot prevent. We observe this collapse with 150 cameras in Smart City deployment using MADDPG, where Deadline Satisfaction drops from 78% to 34%, producing approximately $180,000 in annual cost overruns. Prior work has addressed each contributing factor in isolation: exponential action-space growth, computational redundancy among spatially adjacent agents, and task-agnostic hardware scheduling. None has examined how these three factors interact and amplify each other. We present DAOEF (Delta-Aware Orchestration for Edge Federations), a framework that addresses all three simultaneously through: (1) Differential Neural Caching, which stores intermediate layer activations and computes only the input deltas, achieving 2.1x higher hit ratios (72% vs. 35%) than output-level caching while staying within 2% accuracy loss through empirically calibrated similarity thresholds; (2) Criticality-Based Action Space Pruning, which organizes agents into priority tiers and reduces coordination complexity from O(n2) to O(n log n) with less than 6% optimality loss; and (3) Learned Hardware Affinity Matching, which assigns tasks to their optimal accelerator (GPU, CPU, NPU, or FPGA) to prevent compounding mismatch penalties. Controlled factor-isolation experiments confirm that each mechanism is necessary but insufficient on its own: removing any single mechanism increases latency by more than 40%, validating that the gains are interdependent rather than additive. Across four datasets (100-250 agents) and a 20-device physical testbed, DAOEF achieves a 1.45x multiplicative gain over applying the three mechanisms independently. A 200-agent cloud deployment yields 62% latency reduction (280 ms vs. 735 ms), sub-linear latency growth up to 250 agents.

Samaresh Kumar Singh, Joyjit Roy

Independent Researcher · Leander, Texas · Austin, Texas

Intelligent Edge Distributed Optimization Orchestration Urban Environments Collapse

Ask PDF

Sep 28, 2026cs.DC

AgentWare: Automating the Lifecycle of Agentic Applications across the Edge-to-Cloud Continuum

Deploying LLM-enabled agentic applications across the Edge-to-Cloud continuum remains challenging due to hardware heterogeneity, deployment complexity, limited observability, and the lack of systematic evaluation methods. Existing solutions address agent development, observability, or benchmarking separately, offering limited support for the full lifecycle of distributed agentic applications. This paper presents AgentWare, an AgenticOps framework that automates the provisioning, deployment, observability, and evaluation of agentic applications across Edge-to-Cloud infrastructures. AgentWare introduces an end-to-end lifecycle pipeline that automatically prepares heterogeneous execution environments, transforms user-defined agent implementations into distributed applications, deploys agent components across the continuum, and performs unified collection of execution traces, infrastructure telemetry, and evaluation metrics. The framework further supports automated semantic evaluation through LLM-as-a-Judge workflows and generates reproducible reports covering correctness, performance, resource utilization, and energy consumption. We demonstrate the applicability of AgentWare through a distributed book assistant agent deployed across real Edge-to-Cloud infrastructure under multiple deployment and model configurations. The results show that AgentWare enables systematic experimentation and evaluation of distributed agentic applications while significantly reducing the manual effort required for deployment, instrumentation, and analysis.

Michalis Kasioulis, Moysis Symeonides, George Pallis +1

Department of Computer Science, University of Cyprus

Agentic Deployments Edge Platforms Cp-Agent Lifecycle Llm-As-A-Judge

Ask PDF