PaperlayerView exact revision on arXiv

Source-linked AI summary

The Internet of Collaborating Things: Agentic Edge AI for Autonomous Cross-Domain Collaboration

Walid A. Hanafy, Nader Sehatbakhsh, David Irwin, Mani Srivastava, Prashant Shenoy

arXiv:2609.10542v1cs.DC

TL;DR

Current approaches fall short of IoCT requirements for dynamic, cross-domain collaboration. The paper defines IoCT and proposes a portable execution substrate alongside an agentic control plane. Its supported conclusion is a shift from isolated endpoints toward autonomous participants in an evolving computational collective.

  • Problem

    IoCT requires collaboration across changing device populations and trust domains, while current approaches fall short along one or more of its requirements.

    Source: §I · p. 2, B. Limitations of State of the Art · p. 3

  • Method

    The paper defines IoCT and proposes a portable, secure communication and execution substrate paired with an agentic control plane for lifecycle orchestration.

    Source: §I · p. 2, A. An Initial IoCT Architecture · p. 4, B. Leveraging Edge AI Agents · p. 5

  • Results

    The paper presents IoCT as shifting devices from isolated endpoints to autonomous participants in a continuously evolving computational collective.

    Source: §V · p. 7

  • Takeaways & Limitations

    The authors argue that agents can manage collaboration across trust domains by reasoning about context, establishing transient trust, and adapting without runtime human intervention.

    Source: §I · p. 2

    Current approaches meet only some IoCT requirements; WASM and TEEs also leave execution or cross-domain security needs unaddressed.

    Source: B. Limitations of State of the Art · p. 3

Abstract

from arXiv · show

The Internet of Things is on a trajectory toward a trillion connected devices deployed across multiple domains. These devices are no longer simple sensing and actuation endpoints; they are mobile platforms with embedded processing and intelligent on-device services. The dominant paradigm of offloading computation to cloud and edge servers is a vertical device-to-server interaction model that cannot scale with this trajectory. What is needed instead is a horizontal paradigm in which devices communicate and collaborate directly, pooling their compute, sensing, and actuation into dynamic, cross-domain clusters rather than offloading to centralized infrastructure. We refer to this paradigm as the Internet of Collaborating Things (IoCT). Realizing this vision requires both a portable and secure execution substrate for heterogeneous hardware and an agentic control plane capable of contextual reasoning, transient trust establishment, and open-world adaptation throughout the device collaboration lifecycle without human intervention. In this position paper, we define this new communication, compute, and collaboration paradigm, articulate the role of agentic edge AI in realizing it, and outline research challenges and future directions toward trustworthy, autonomous IoCT collaboration.

I. INTRODUCTION

The paper argues that device-to-server offloading will not sustain growing IoT workloads, and proposes direct, horizontal collaboration among devices. It pairs a portable execution substrate with agentic orchestration to support dynamic cross-domain collaboration.

I. INTRODUCTION

  • IoT devices are becoming more capable, but offloading through server hierarchies cannot sustain projected device growth and modern AI and sensing demands.The paper cites more than 20 billion connected devices in 2025 and notes that devices may outnumber available processing servers by many orders of magnitude.Source: §I · p. 1
  • IoCT replaces vertical offloading with dynamic, cross-domain clusters that pool colocated devices’ computing, sensing, actuation, and networking capabilities.These shared resources serve multiple applications and visiting devices, with collaboration reorganized across devices in different trust domains.Source: §I · p. 1, Figure 1 · p. 1
  • IoCT applications use portable dataflow graphs whose nanotasks map at runtime to nearby hardware and whose nanoservices invoke device sensing, actuation, and communication.Nanotasks are platform-independent computations; nanoservices use primitives exposed by different devices.Source: §I · p. 2
  • The substrate must address device discovery, cross-domain security and access control, heterogeneity-aware orchestration, and constrained execution.AI workloads may require runtime partitioning, compression, migration, or adaptation to balance accuracy, latency, energy, and availability.Source: §I · p. 2
  • The proposed architecture pairs portable, secure execution and communication with an autonomous control plane that discovers devices, validates credentials, allocates resources, and adapts as clusters change.Agents evaluate identities, capabilities, task needs, credentials, attestations, intent, and policy to produce placement and access decisions without per-encounter manual configuration.Source: §I · p. 2
  • The paper’s contributions are an IoCT paradigm and motivating scenarios, an initial architecture, and open challenges in verifiable decisions, trust negotiation, and resource management.The authors argue that without autonomy, orchestration cannot scale to expected deployment frequency, heterogeneity, and cross-domain mobility.Source: §I · p. 2

II. WHY IS IOCT HARD TO ACHIEVE?

The section presents motivating examples for IoCT and explains why existing approaches fall short.

II. WHY IS IOCT HARD TO ACHIEVE?

  • The section presents IoCT’s motivating examples and explains where current approaches fall short.The supplied passage gives this as the section’s scope.Source: §II · p. 2

A. Motivational Examples

The scenarios show visiting devices entering spaces with resident devices and needing to collaborate across administrative and trust boundaries. Their needs range from robotic access to home resources, to time-limited visitor permissions and coordinated entertainment services.

Delivery Robot

  • A delivery robot can shift from standalone navigation to using building sensors, maps, smart locks, and on-premise computation, raising multitenancy, trust, integrity, and latency-management challenges.The scenario describes benefits including lower latency, improved reliability, and higher-quality prediction and control.Source: A. Motivational Examples · p. 2

Frequent Visitors

  • A frequent visitor needs access limited to duties and visit duration, such as using a baby monitor without being able to reconfigure it.The example identifies fine-grained, time-bounded access control as a challenge.Source: A. Motivational Examples · p. 3

Collaborative Gaming

  • Collaborative gaming combines visitors’ AR headsets, controllers, and mobile devices with resident TVs, consoles, lights, music, and on-premise processing.The scenario requires resource coordination while preserving performance isolation among users, applications, and background services.Source: A. Motivational Examples · p. 3

Shared structure

  • Across scenarios, visiting devices enter a domain with resident devices, discover resources, obtain scoped cross-domain access, collaborate, and depart.The paper uses the delivery robot as its running example.Source: A. Motivational Examples · p. 3, Figure 2 · p. 3

B. Limitations of State of the Art

The paper argues that existing approaches each miss requirements for IoCT, particularly dynamic cross-domain collaboration, resource pooling, and secure execution.

Service Discovery

  • Current approaches fall short along one or more IoCT requirements, including service discovery protocols that assume implicit local trust and lack access control and cross-domain identity verification.The named discovery protocols are UPnP, Zero-Conf, and Jini.Source: B. Limitations of State of the Art · p. 3

Cloud and Edge Platforms

  • Cloud and edge platforms treat devices as infrastructure clients, with pre-provisioned registries and vendor-anchored trust rather than cross-domain resource pooling.The cited examples include AWS IoT, Azure IoT Edge, and AWS Greengrass.Source: B. Limitations of State of the Art · p. 3

IoT Composition Frameworks

  • IoT composition frameworks statically partition applications and do not handle changing device populations, foreign-domain visitors, or runtime reallocation.The passage discusses declarative dataflow frameworks and service-oriented middleware.Source: B. Limitations of State of the Art · p. 3

Secure Isolation Mechanisms

  • WASM offers portable sandboxed execution but lacks real-time scheduling, multi-tenant sensor sharing, and accelerator access; TEEs provide hardware-backed isolation but are hardware-specific and do not themselves resolve cross-domain access decisions.The passage notes that TEEs are unavailable on many low-end devices.Source: B. Limitations of State of the Art · p. 3

Attestation and Device Integrity

  • Attestation methods can verify device integrity but assume static, preestablished verifier–prover relationships, while privacy-preserving techniques do not establish dynamic integrity or guarantee trustworthy sensor and actuator outputs.The passage distinguishes integrity verification from limiting data disclosure in particular processing settings.Source: B. Limitations of State of the Art · p. 3

III. REALIZING IOCT

IoCT's design principles center on direct device collaboration, short-lived cross-domain federation, portable execution, autonomous orchestration, continuous adaptation, and least-privilege access.

Horizontal collaboration over hierarchical offload

  • Nearby devices collaborate directly by pooling sensing, computation, networking, and actuation rather than relying solely on hierarchical offload.Source: §III · p. 4

Transient cross-domain federation

  • Collaborations form opportunistically across administrative trust boundaries and dissolve as devices enter or leave a physical space.Source: §III · p. 4

Portable execution across heterogeneous devices

  • Applications should run across microcontrollers, embedded processors, GPUs, and specialized accelerators without device-specific deployment logic.Source: §III · p. 4

Policy-driven autonomous orchestration

  • High-level intent and automated reasoning over capabilities, trust, and runtime context drive orchestration in dynamic, heterogeneous environments.Source: §III · p. 4

Continuous adaptation to mobility and resource dynamics

  • Placement, access control, and resource allocation must adapt as devices move, workloads fluctuate, and network conditions evolve.Source: §III · p. 4

Least-privilege, time-bounded collaboration

  • Access should be limited to the permissions needed for a collaboration session and revoked automatically when it ends.Source: §III · p. 4

A. An Initial IoCT Architecture

The initial IoCT architecture pairs a portable, secure data plane with a control plane that discovers devices, allocates resources, and adapts collaboration across domains.

Data Plane

  • The data plane lets applications use a dynamic cluster of heterogeneous devices and servers, sharing their sensing, actuation, computation, and connectivity.Source: A. An Initial IoCT Architecture · p. 4
  • A unified publish-subscribe messaging abstraction can bridge heterogeneous wireless links, while device brokers mediate module and cross-device communication and enforce capability-token policies.Source: A. An Initial IoCT Architecture · p. 4
  • WebAssembly offers portable, low-overhead execution that can be placed inside a hardware trusted execution environment for two-way isolation.The data plane must also support fine-grained, multi-tenant sharing of sensors, actuators, and accelerators.Source: A. An Initial IoCT Architecture · p. 4

Application Model

  • Applications are portable dataflow graphs of dynamically placed nanotasks and nanoservices that expose device-native sensing, actuation, and communication primitives.Structured capability descriptions advertise available resources and services; the delivery-robot graph combines robot and building resources across trust domains.Source: A. An Initial IoCT Architecture · p. 4, Figure 3 · p. 4

Control Plane

  • The control plane tracks device capabilities and trust metadata, validates visiting devices, issues short-lived capability tokens, maps tasks under latency and capacity constraints, and re-orchestrates as context changes.An agentic control plane is proposed because device combinations and collaboration contexts cannot be anticipated at design time and sessions arise too frequently for manual configuration.Source: A. An Initial IoCT Architecture · p. 5

B. Leveraging Edge AI Agents

Because IoCT requires orchestration under incomplete, changing conditions that static rules cannot anticipate, the paper proposes an agentic orchestrator with validated, event-driven decisions.

Need for an agentic orchestrator

  • IoCT needs contextual reasoning, transient trust establishment, and open-world adaptation because device combinations and conditions cannot be anticipated and rule-based orchestration becomes brittle.Source: B. Leveraging Edge AI Agents · p. 5

Agentic orchestrator

  • The orchestrator maintains a persistent observe-reason-act loop and responds to control-plane alerts with targeted decisions rather than replanning from scratch.The reference architecture places the agent alongside the control plane, device registry, policy state, and data-plane telemetry and enforcement.Source: B. Leveraging Edge AI Agents · p. 5, Figure 4 · p. 5

Decision validation

  • The agent evaluates intent, credentials, attestations, capabilities, resources, and policy constraints, while syntactic and semantic validation gates policy, placement, and token outputs before application.Source: B. Leveraging Edge AI Agents · p. 5

Inter-agent coordination

  • MCP standardizes the agent-control-plane interface, while peer orchestrators use A2A-inspired negotiation when a visiting device crosses domains.Each domain operates its own orchestrator, and neither has authority over the other.Source: B. Leveraging Edge AI Agents · pp. 5–6

C. The Collaboration Lifecycle

The delivery-robot example follows collaboration from discovery through cross-domain validation and scoped access, then adapts enforcement as conditions change and revokes visit-specific access at departure.

Arrival and discovery

  • When the robot enters the lobby, discovery and capability profiling trigger the building orchestrator to inspect its identity, capabilities, task needs, and relevant administrator intent.Source: C. The Collaboration Lifecycle · p. 6

Validation and authorization

  • Credential and attestation checks validate the robot's identity and claims, which the orchestrator combines with intent, context, resources, and task needs to scope access and placement.The example may authorize building map, elevator, and lock-actuation nanoservices, as well as on-premise compute.Source: C. The Collaboration Lifecycle · p. 6

Runtime adaptation and departure

  • Short-lived signed capability tokens govern access; telemetry and alerts support policy, placement, or token changes as conditions shift, and departure triggers revocation.Source: C. The Collaboration Lifecycle · p. 6

IV. OPEN RESEARCH CHALLENGES

IoCT faces research challenges spanning the device-layer substrate, cross-domain security, and autonomous orchestration. The supplied passages identify open issues in safe decisions, transient trust, resource management, and collaboration incentives.

Safe and Verifiable Agentic Decisions

  • LLM-based orchestration can hallucinate or produce inconsistent outputs, risking excessive access, incorrect placement, or unsafe actuation; existing pipelines do not guarantee correctness for broader IoCT decisions.Future work must combine structured output schemas, satisfiability checks, and formal safety verification.Source: §IV · p. 6

Cross-Domain Trust Negotiation

  • Transient cross-domain visits lack the prior relationships of traditional federated systems, while existing protocols do not cover IoCT’s credential exchange, attestation validation, and policy reconciliation needs.Open questions include policy conflicts, delegation scope, and accountability when a visiting device causes harm.Source: §IV · p. 6

Bidirectional Resource Sharing Under Asymmetric Trust

  • Asymmetric resource sharing lets visitors contribute capabilities such as a robot GPU, but existing isolation and cryptographic mechanisms may be hardware-specific, unavailable, or too costly for latency-sensitive workloads.Future systems must support varying trust levels, protect sensitive state, verify less-trusted executors, and update trust as evidence changes.Source: §IV · p. 6

Dynamic and Heterogeneous Resource Management

  • Fluid device availability and heterogeneous hardware require re-orchestrating placement, policies, and resource allocations under latency and safety constraints.Open challenges include managing execution state after unexpected departures and sharing sensors, actuators, and accelerators across tenants without conventional memory protection.Source: §IV · p. 6

Incentives and Economic Models for Collaboration

  • Voluntary contributions of sensing, compute, networking, and actuation incur energy, wear, privacy, and opportunity costs, making incentives and accounting mechanisms an open challenge.Open questions include valuing resource use, enforcing fairness, and choosing cooperative, contractual, or market-driven models.Source: §IV · p. 7

V. CONCLUSION

The conclusion presents IoCT as a shift from isolated IoT endpoints to autonomous participants in a continuously evolving computational collective.

V. CONCLUSION

  • IoCT shifts IoT devices from isolated endpoints to autonomous participants in a computational collective.The collective is continuously evolving.Source: §V · p. 7
  • The paper characterizes the IoCT collective as continuously evolving.Source: §V · p. 7
  • Devices in IoCT are framed as participants in a shared computational collective rather than isolated endpoints.Source: §V · p. 7
Loading 2609.10542v1…