Application-Centric Considerations for Deployment over the IoT Computing Continuum

Introduction The Internet of Things (IoT) has evolved from simple data-collection systems into a foundation for complex, data-driven smart applications across domains such as smart cities, precision agriculture, industrial automation, and healthcare. These applications increasingly depend on distributed computing resources to sense, process, and act on data close to where it is generated, while also leveraging large-scale cloud infrastructures for coordination, analytics, and long-term storage. This evolution has led to the emergence of a distributed computing environment spanning multiple stages, from highly constrained devices and gateways to edge nodes, cloudlets, and centralized cloud platforms. The literature commonly describes this environment as the edge-cloud continuum, IoT-edge-cloud continuum, or simply the computing continuum. Comprehensive perspectives on the evolution of this paradigm are provided in . In this document, the term IoT computing continuum emphasizes the presence of constrained IoT devices and the domain-specific requirements they introduce. Recent research and standardization efforts have highlighted this continuum and discussed challenges related to edge functions, data handling, and communication across heterogeneous environments, including IETF and IRTF work such as . However, much of the existing discussion remains infrastructure- or communication-centric, with comparatively less focus on the implications for smart application deployment and lifecycle management. From an application perspective, smart services are no longer confined to a single execution environment. Instead, they comprise multiple functions that must be placed, coordinated, and potentially migrated across stages of the IoT computing continuum to meet requirements for latency, resilience, scalability, privacy, and energy efficiency. In practice, these decisions are often handled manually or through ad hoc mechanisms, leading to fragmented solutions and limited portability across deployments. The lack of a shared, application-centric view of deployment over the IoT computing continuum creates challenges for both researchers and practitioners. It complicates systematic reasoning about application structure, hinders the comparison of alternative approaches, and makes it difficult to identify common requirements that could inform future research and standardization activities. This document contributes to this discussion by examining smart application deployment across the IoT computing continuum from a conceptual and architectural perspective. Rather than proposing specific mechanisms or protocols, it identifies key challenges, clarifies terminology, and outlines considerations relevant to ongoing research within the Thing-to-Thing Research Group (T2TRG) of the Internet Research Task Force (IRTF).

Scope and Non-Goals This document focuses on conceptual and architectural considerations for deploying smart applications across the IoT computing continuum. It focuses on challenges, common patterns, and terminology arising from distributed application logic across heterogeneous computing environments, including constrained IoT devices, edge nodes, and cloud platforms. The intent is to support research-oriented discussion and provide a shared frame of reference for ongoing and future IRTF work. The discussion explicitly considers the interplay between application development and deployment, while remaining agnostic to specific tools, workflows, or operational practices. The document does not specify concrete deployment mechanisms, protocols, or interfaces. It does not define a reference architecture or mandate how applications should be structured, deployed, or managed in practice. Instead, it describes the problem space and highlights issues relevant across multiple technologies, deployment models, and research efforts. In particular, the following items are explicitly outside the scope of this document:

The specification of new communication protocols, APIs, or data models.
The definition of normative requirements, including the use of requirement keywords such as MUST, SHOULD, or MAY.
The standardization of specific platforms, frameworks, or programming models for IoT application deployment.
Detailed performance evaluations or quantitative comparisons between alternative solutions.

By clearly delineating its scope and non-goals, this document complements existing and ongoing efforts in the computing continuum, including work on communication, edge functions, and operational aspects, while maintaining a technology-agnostic, application-centric perspective.

Terminology This document uses the following terms with the meanings indicated below. These definitions clarify usage in this document and are not meant to redefine existing terminology used elsewhere. Internet of Things (IoT): A system paradigm involving interconnected physical objects equipped with sensing, actuation, processing, and communication capabilities, operating under resource constraints, as discussed in . Constrained Devices: Devices with limited processing power, memory, energy availability, or communication capabilities. The use of the term constrained in this document follows the terminology defined in . IoT Computing Continuum: A distributed execution environment spanning constrained IoT devices, edge nodes, cloud platforms, and network elements that provide suitable processing capabilities. Application functions may execute at different stages, depending on their requirements and the capabilities and constraints of each environment. These stages are not restricted to general-purpose computing hosts: programmable network elements can also execute eligible functions as part of the continuum, integrating the notion of Computing in the Network (COIN). The shorthand term IoTinuum has been used in related work to denote this same concept . This document uses the expanded form throughout for clarity and alignment with terminology used in related standardization efforts. Edge Node: An intermediate computing node between constrained devices and centralized cloud infrastructure, providing computation, storage, and networking closer to data sources, as described in . Orchestration and Choreography: Two coordination styles for distributed applications. Orchestration refers to coordination driven by explicit control logic, while choreography relies on decentralized interactions among components without a central coordinator.

Background: The IoT Computing Continuum The increasing distribution of computation across networked systems has led to the emergence of what is commonly described as a computing continuum, spanning centralized cloud infrastructures, intermediate edge and fog nodes, and highly constrained end devices . This paradigm reflects a shift away from strictly centralized processing models toward more distributed execution, driven by requirements related to latency, bandwidth efficiency, resilience, data locality, and regulatory constraints. Within the context of the Internet of Things (IoT), this continuum acquires additional characteristics that distinguish it from more general edge-cloud computing environments. IoT deployments involve large numbers of heterogeneous devices with severe resource constraints, intermittent connectivity, and close interaction with the physical world through sensing and actuation . As a result, computation is often pushed closer to data sources not only for performance reasons, but also to enable timely control actions, reduce energy consumption, and preserve privacy. Recent research and standardization activities have explored different aspects of this continuum. In particular, work within the IETF and IRTF has highlighted the importance of edge computing and has discussed functional components and challenges associated with operating across distributed environments . Existing documents have examined edge functions for data processing, storage, and communication, as well as the roles of gateways and intermediate nodes in bridging constrained devices to cloud services. These efforts provide an important foundation for understanding the structural and operational properties of the continuum. This document takes a complementary rather than competing perspective. While characterizes functional components and infrastructure-level challenges, focusing on edge functions and the communication fabric that supports them, this document shifts attention to the application layer that runs on top of that infrastructure. Specifically, it considers how smart applications, composed of multiple interdependent functions, are decomposed, placed, coordinated, and managed across the heterogeneous stages enabled by that infrastructure. Application-centric concerns such as functional decomposition, placement, coordination style, and lifecycle management are largely orthogonal to the infrastructure view and remain comparatively underexplored in current standardization discussions. This document adopts the term IoT computing continuum to refer to this distributed execution environment, encompassing constrained IoT devices, edge nodes, cloud platforms, and network elements with processing capabilities. The continuum naturally accommodates Computing in the Network (COIN): application processing can include eligible functions executed within the network. For example, filtering, aggregation, or preprocessing may execute in a programmable network element when its capabilities and the application semantics permit. This does not imply that every network element is programmable or that every application function is suitable for in-network execution. Building on existing work, the focus here is on understanding how the properties of the IoT computing continuum influence application deployment, placement, and lifecycle management, rather than on defining specific technologies or architectural solutions.

An Application-Centric View of the Continuum Traditional IoT architectures often treat applications as tightly coupled to specific execution environments, typically assuming fixed roles for devices, gateways, and cloud services. In the context of the IoT computing continuum, this assumption no longer holds. Smart applications must be understood as distributed entities whose behavior emerges from the coordinated execution of multiple components across heterogeneous computing stages. An application-centric view is therefore essential for reasoning about deployment, adaptation, and lifecycle management in such environments.

Applications as Distributed Functional Graphs From an application-centric perspective, smart applications can be modeled as collections of interdependent functions rather than as monolithic software artifacts. These functions interact through well-defined data and control dependencies, forming a logical application graph that captures the application's structure independently of where its components execute. This representation enables reasoning about application behavior, dependencies, and composition without prematurely binding functions to specific devices or platforms. Viewing applications as distributed functional graphs is particularly relevant in IoT environments, where different functions may have distinct requirements for latency, computational resources, sensor or actuator access, and interaction with external services. By separating the application's logical structure from its physical deployment, this model supports more flexible placement and adaptation strategies across the continuum.

Decoupling Application Logic from Execution Environments A key implication of the application-centric view is decoupling application logic from execution environments. Application functionality should be expressed in a way that is independent of specific hardware platforms, operating systems, or runtime environments. This decoupling enables portability across heterogeneous devices and supports dynamic reassignment of application components as execution conditions change. In the IoT computing continuum, execution environments vary widely in terms of resource availability, connectivity, and operational constraints. Binding application logic too early to a particular environment limits the ability to adapt to failures, load variations, or evolving requirements. An application-centric approach instead treats execution environments as abstract resources onto which application functions can be mapped, allowing deployment decisions to be revisited over time.

Placement and Distribution Across the Continuum Once application logic is decoupled from execution environments, placing application functions becomes a first-class concern. Placement decisions determine where an application's functions execute within the IoT computing continuum, from constrained devices and gateways to edge nodes and cloud platforms. These decisions directly affect end-to-end application properties, including latency, reliability, energy consumption, and data locality. Importantly, placement is not static. In many scenarios, application components may need to be redistributed in response to changes in workload, network conditions, or operational context. An application-centric view highlights the need to reason about placement and distribution as dynamic processes intrinsic to how smart applications operate across the continuum.

Application Lifecycle Beyond Initial Deployment In centralized systems, application deployment is often treated as a one-time event followed by relatively infrequent updates. In contrast, the IoT computing continuum introduces a more complex and dynamic application lifecycle. Beyond initial deployment, applications may undergo continuous adaptation, including updates, reconfiguration, scaling, component migration, and partial redeployment across different continuum stages. Managing this lifecycle is particularly challenging in IoT environments due to device heterogeneity, intermittent connectivity, and the coexistence of multiple administrative domains. An application-centric perspective emphasizes that lifecycle management must be considered holistically, encompassing not only software updates but also the ongoing coordination of distributed application components. Understanding these lifecycle aspects is essential for identifying common challenges and research questions related to deployment and operation in the IoT computing continuum.

Challenges in Smart Application Development and Deployment The IoT computing continuum introduces challenges that fundamentally affect both the development and deployment of smart applications. Unlike centralized environments, where development and deployment can often be treated as loosely coupled phases, the heterogeneity, distribution, and dynamism of the continuum create strong interdependencies among application design choices, deployment decisions, and runtime behavior. As a result, development and deployment concerns cannot be addressed effectively in isolation. A primary challenge stems from the bidirectional influence between application development and deployment constraints. Development decisions, such as functional decomposition, communication patterns, and state management, directly affect deployment feasibility across constrained devices, edge nodes, and cloud platforms. At the same time, deployment realities, resource availability, network conditions, latency requirements, and energy constraints often impose limitations that shape or even redefine application design. This mutual influence complicates traditional workflows that assume stable execution environments and late-stage deployment decisions. Heterogeneity across the continuum further amplifies this challenge. Execution environments vary widely in hardware capabilities, operating systems, runtime support, and management interfaces. Developers must therefore anticipate deployment diversity early in development, while deployment mechanisms must accommodate application abstractions that span multiple platforms. Without integrated development and deployment considerations, solutions tend to become fragile, tightly coupled to specific environments, and difficult to evolve. Another challenge arises from the dynamic nature of deployment in the IoT computing continuum. Smart applications often need to adapt to changing conditions, such as workload variations, mobility, intermittent connectivity, or evolving physical contexts. Supporting such adaptation requires continuous feedback between runtime behavior and development-time assumptions. Static deployment models and rigid application designs limit responsiveness to these dynamics, underscoring the need for approaches that treat deployment as an ongoing process rather than a one-time event. These challenges align with principles commonly associated with DevOps practices, which emphasize continuous integration, continuous deployment, and feedback loops between development and operations. However, transferring DevOps concepts to the IoT computing continuum is non-trivial. Conventional DevOps pipelines typically target cloud-centric environments and assume homogeneous infrastructure, reliable connectivity, and centralized control. In contrast, IoT scenarios involve constrained devices, distributed execution across multiple continuum stages, and, in many cases, multiple administrative domains, which complicates the application of traditional DevOps assumptions. Finally, the lack of shared abstractions and terminology for reasoning about development and deployment across the continuum makes it difficult to compare approaches and identify common requirements. When the interplay between development and deployment is not made explicit, solutions often remain ad hoc and platform-specific. Addressing this gap requires an application-centric perspective that explicitly acknowledges development--deployment interdependencies and treats them as first-class concerns. This perspective is essential for advancing research on smart application deployment and informing future standardization efforts for the IoT computing continuum.

Conceptual Deployment Model This section outlines a conceptual model for reasoning about the deployment of smart applications across the IoT computing continuum. The model supports analysis and discussion rather than prescribing specific mechanisms, architectures, or workflows. It provides a shared abstraction that captures how application structure, execution environments, and coordination mechanisms interact in heterogeneous, dynamic IoT scenarios. At the core of the model is the separation between application logic and execution environments. Application logic is represented independently of its execution location, allowing reasoning about functionality, dependencies, and interaction patterns without binding components to specific devices or platforms. Execution environments are treated as abstract resources characterized by capabilities, constraints, and operational context, such as computational power, connectivity, proximity to data sources, and energy availability. Execution environments can include programmable network elements as well as general-purpose computing nodes. Placement therefore selects both a location and a type of execution environment. A function is eligible for execution within the network only if the element supports its computation, state, data access, and interaction requirements. Constraints on the processing model, memory, persistent state, and management interfaces can make only part of an application suitable for such placement. Network forwarding responsibilities and application processing may also share resources, so deployment feasibility depends on their interaction. In this model, a smart application is a set of functional components connected through data and control dependencies, forming a logical application graph. Deployment maps these components onto available execution environments across the IoT computing continuum. This mapping determines where components execute, but it does not, by itself, define how they coordinate during execution. As a result, deployment decisions must be considered together with coordination strategies that govern interactions among distributed components. Application components can coordinate in different ways, most notably through orchestration and choreography. In an orchestration style, explicit control logic drives coordination by managing execution order, data flow, and component interactions. This style provides a global view of application behavior and can simplify reasoning about end-to-end execution, but it may introduce centralization and scalability concerns in highly distributed environments. In contrast, choreography relies on local interactions and shared interaction rules, letting components coordinate in a decentralized way without a single point of control. This style can improve scalability and resilience, but it may complicate global reasoning and debugging. The choice between orchestration and choreography, or combinations thereof, is closely tied to deployment decisions and to the characteristics of the IoT computing continuum. Resource constraints, network conditions, mobility, and administrative boundaries may favor one coordination style over another at different stages of the continuum. Moreover, coordination strategies may need to evolve over time as applications adapt to changing conditions, reinforcing the dynamic nature of deployment. The conceptual deployment model, therefore, treats placement, coordination, and lifecycle management as interrelated concerns. Beyond initial placement, deployment includes reconfiguration, scaling, migration, and adapting coordination strategies. Runtime observations, including performance metrics and failure events, provide feedback that can inform both deployment decisions and future iterations of application design. By explicitly incorporating coordination styles into the deployment model, this abstraction provides a more concrete foundation for discussing development--deployment interdependencies in the IoT computing continuum, while remaining agnostic to specific technologies or implementations.

Illustrative Scenarios We present two illustrative scenarios that ground the conceptual deployment model discussed earlier. The scenarios demonstrate how application-centric concepts, deployment decisions, and coordination styles manifest in realistic settings, without prescribing specific technologies or architectures. The first scenario describes a smart irrigation application deployed in operational agricultural settings, providing a concrete reference for placement and lifecycle concerns under real-world constraints. The second scenario describes a drone-based delivery application that spans a broader range of continuum stages and exhibits a richer interplay between coordination styles.

Smart Irrigation in Precision Agriculture This scenario is grounded in the SWAMP platform , which describes an IoT-based precision-irrigation architecture and deployments for four pilots in Brazil and Europe. Its configurable distribution of components across cloud and farm-side fog resources supports the discussion of deployment diversity and reuse across farms. In particular, the MATOPIBA deployment description includes local processing and resilience to Internet disconnections. The placement and lifecycle considerations below build on that operational motivation; they are not a claim that the paper evaluates every adaptation mechanism discussed here. Smart irrigation applications collect environmental data, such as soil moisture and weather conditions, and use it to determine how much, when, and where to irrigate. In operational deployments, these applications typically span constrained field sensors, low-power gateways that act as radio concentrators, on-premises edge nodes in farm facilities, and cloud services for analytics, forecasting, and long-term storage. End users interact with the application through mobile or web interfaces to inspect data and approve irrigation plans. From an application-centric perspective, the irrigation scenario exemplifies how functional decomposition maps naturally onto multiple continuum stages. Sensing and local preprocessing functions execute on constrained devices and field gateways. Intermediate functions, such as data filtering, sensor calibration, and disconnection resilience, run on on-premises edge nodes near the irrigation infrastructure and remain operational even when cloud connectivity is unavailable. More computationally intensive functions, including data fusion, soil moisture forecasting, and irrigation optimization, run on cloud platforms that offer greater resources and broader data visibility. A defining property of this scenario is the need to keep operating with intermittent wide-area connectivity, common in rural deployments. Functions on on-premises edge nodes must sustain essential behavior when cloud services are temporarily unreachable, such as enforcing safety thresholds or running simplified local models, and reconcile state once connectivity is restored. This requirement directly shapes how developers decompose application functions and where they deploy them, illustrating the bidirectional influence between development and deployment concerns discussed earlier. The irrigation scenario also highlights that deployment decisions extend beyond initial placement. Over time, functions may be updated, reconfigured, or extended to incorporate new models or new sensor modalities, and the same application logic may need to be deployed across multiple farms with different infrastructure configurations. These lifecycle aspects underscore the relevance of an application-centric view that treats deployment as an ongoing process rather than a one-time event.

Drone-Based Delivery in Urban Environments The delivery-service setting and the need for autonomous local collision avoidance are motivated by . That study evaluates non-cooperative geometric collision-avoidance strategies through simulation and analytical modeling, and explains why local strategies remain relevant when communication is unavailable or emergency detours are needed. The distribution of functions across edge nodes, cloudlets, and cloud platforms described below is an illustrative deployment extension; it is not an experimentally validated architecture from that study. In particular, autonomous non-cooperative avoidance is not choreography, which concerns interactions among components. A drone-based delivery application uses unmanned aerial vehicles to deliver packages in urban areas. The application comprises multiple functional components, including mission planning, navigation, sensing, local coordination, and backend services for order management and analytics. From an application-centric perspective, these components form a logical application graph, with dependencies reflecting data flows and control interactions among functions. The application operates across the full span of the IoT computing continuum, leveraging constrained onboard devices, nearby edge nodes, operator-provided cloudlets, and cloud platforms. Low-level sensing, actuation, and real-time navigation run directly on the drone because of strict latency and control requirements. Local coordination and situational awareness functions may execute on nearby edge nodes or gateways that aggregate information from multiple drones operating in the same area. Operator-provided cloudlets, for example, those associated with 5G or future 6G infrastructure, can host functions that support cooperative behavior among drones, such as collision avoidance assistance and shared situational awareness. Backend services, including mission planning, optimization, logging, and analytics, typically run on cloud platforms that provide greater computational resources and global system visibility. This scenario particularly illustrates the coexistence of different coordination styles within a single application. Mission planning and high-level task assignment naturally follow an orchestration style, in which a centralized component coordinates delivery schedules and routes based on global system state. In contrast, local interactions among drones, such as collision avoidance or cooperative sensing, follow a choreography style, relying on decentralized interactions and shared interaction rules without a single controlling entity. Both coordination styles coexist within the same application and are influenced by deployment choices across the continuum, demonstrating that the distinction between orchestration and choreography is not merely theoretical but reflects concrete architectural trade-offs. Deployment decisions in this scenario are also inherently dynamic. As drones move through different environments or face changing network conditions, mappings of coordination functions to edge nodes or cloudlets may need revision, while backend services remain centralized. The application lifecycle extends beyond initial deployment, with components updated, reconfigured, or migrated in response to changes in delivery demand, individual drone failures, or variations in network availability.

Discussion Together, these two scenarios illustrate the spectrum of smart applications that operate over the IoT computing continuum. The first grounds the discussion in operational deployments with documented constraints, particularly around intermittent connectivity and the need for resilient edge behavior. The second reveals the broader architectural space where placement, coordination, and lifecycle concerns fully manifest, including the explicit coexistence of orchestration and choreography within a single application. Both share the fundamental property that application behavior emerges from the coordinated execution of distributed functions across heterogeneous stages, reinforcing the need for application-centric perspectives on deployment and lifecycle management.

The Role of AI Agents in Application Deployment The previously discussed conceptual deployment model considers placement, coordination, and lifecycle management as interconnected and inherently dynamic concerns. As the scale, heterogeneity, and dynamism of the Internet of Things (IoT) computing continuum increase, addressing these concerns through static policies or manual procedures becomes increasingly challenging, especially when application workloads demonstrate heterogeneous and context-sensitive behavior. AI agents, defined as autonomous software entities capable of perceiving their environment, reasoning about objectives, and acting upon deployment infrastructure, present a promising solution for managing this complexity. Foundational research on multi-agent systems offers established abstractions for understanding agent behavior. This section analyzes the role of such agents from an application-centric perspective, without specifying particular agent architectures, frameworks, or protocols. AI agents are connected to application deployment in two complementary ways. First, agents can facilitate the deployment process by assisting with or automating decisions regarding the placement, coordination, adaptation, and lifecycle management of application functions. Second, agents themselves are software components that require execution within the continuum. Therefore, their deployment must also be considered, subject to the same placement criteria as application functions. The following discussion examines these two roles sequentially.

Agents as Enablers of the Deployment Process In their first role, AI agents support deploying the services that comprise a smart application across the IoT computing continuum. Given a logical application graph and a set of available execution environments, agents can evaluate candidate mappings of functions to continuum stages, considering application-level requirements such as latency, resilience, energy consumption, and data locality, as well as runtime observations of infrastructure conditions. Beyond initial placement, agents can drive lifecycle operations, including reconfiguration, scaling, migration, and partial redeployment, in response to workload variations, mobility, connectivity disruptions, or evolving physical contexts. A concrete example arises in deploying inference workloads based on large language models, where placement decisions must balance latency, cost, and resilience to connectivity disruptions. Preliminary work by the authors suggests that agent-driven adaptive placement strategies can outperform static configurations, particularly under variable demand or intermittent wide-area connectivity. Agent-assisted deployment does not presuppose a particular coordination style. A single agent with global visibility may coordinate deployment decisions in an orchestration style, while multiple agents interacting through shared rules may realize deployment coordination in a choreography style. The Model Context Protocol supports interactions between applications and tools or contextual resources, while the Agent2Agent protocol supports interactions among agents. Neither protocol, by itself, determines whether an application follows orchestration, choreography, or a hybrid arrangement; that choice depends on the distribution of coordination logic and decision authority. The IETF Agent Communication Protocols (agentproto) Working Group addresses a complementary concern: the correlation, lifecycle, and continuity of agentic dialogs across participants, intermediaries, and trust boundaries. Such capabilities are relevant when deployment agents exchange observations and actions across the continuum, including when an interaction resumes after interruption, or a participant changes network attachment. Dialog management does not itself preserve application state or guarantee the completion of a deployment action. The group's charter does not standardize agent decision-making or planning semantics, and therefore does not determine placement policies or the application's coordination style. Agents distributed across the continuum may exchange information on local resource availability, observed conditions, and pending deployment actions. These interactions can combine local knowledge available near constrained devices with global objectives maintained on cloud platforms. Their use requires distinguishing communication and dialog continuity from the application-level rules that govern deployment decisions and recovery.

Deployment of the Agents Themselves In their secondary role, agents function as deployable entities. As software components, they require execution environments that provide sufficient computational power, memory, and connectivity. Agents can operate anywhere in the IoT computing continuum, including gateways, edge nodes, cloudlets, and cloud platforms. The selected deployment stage influences the timeliness of agent decisions, the degree of local context awareness, and resilience to connectivity disruptions. Constrained devices require special consideration, as many lack sufficient resources to support a full agent runtime. Nevertheless, deployment strategies must often account for device-level conditions. A proxy-based approach addresses this challenge: a lightweight proxy on the constrained device represents it to a nearby agent, such as a gateway or edge node, which then reasons on the device's behalf. This method enables agent-based deployment at even the most resource-limited stages of the continuum, while adhering to the constraints outlined in . Agent deployment is recursive: the mechanisms agents use to deploy application functions also apply to the agents themselves. The placement, migration, and lifecycle management of agents present challenges analogous to those for application components, but they also raise additional concerns about trust, accountability, and control, especially when agents operate autonomously across multiple administrative domains. The Research Directions section identifies open questions associated with this dual role.

Relationship to Ongoing Research and Standardization The issues discussed in this document build on existing research and standardization efforts on edge computing and the computing continuum, including work within the IETF and IRTF (e.g., ) and broader academic perspectives (e.g., ). Within the IRTF, the T2TRG has explored programmability, coordination, and interoperability among connected devices. Several concrete research efforts have examined application-centric aspects of the IoT computing continuum and informed the perspective adopted in this document. Work on the notion of an IoT computing continuum as a unifying framework for reasoning about development and deployment choices has clarified the role of distributed application stages . Complementary work on deployment-aware approaches, such as IoTDeploy, has explored how application components can be systematically placed and migrated across continuum stages while preserving application-level properties . More recent efforts have investigated integrated frameworks for developing and deploying continuum-aware smart applications, providing concrete examples of how application-centric abstractions can be realized in practice. These efforts are cited here as representative of ongoing work in the area, not as prescriptive references; this document remains agnostic to specific frameworks or implementations. Community-driven efforts, including workshops focused on future Internet research, have also discussed application deployment over the IoT computing continuum in the context of IETF and IRTF engagement, as exemplified by . This document complements these efforts by adopting an application-centric perspective on deployment and lifecycle management.

Device Update, Discovery, and Management The SUIT firmware update architecture addresses secure firmware updates for IoT devices. It provides lifecycle foundations for device software, while application deployment raises additional questions about compatibility and coordinated transitions across device firmware, edge services, and cloud functions. CoRE work provides complementary mechanisms. The Resource Directory supports resource registration and lookup, including for endpoints that cannot remain continuously available. The CoAP Management Interface , an expired work-in-progress draft, is relevant to accessing management data in constrained environments. Resource discovery and management can provide inputs and operations for deployment, but they do not, by themselves, describe an application's entire dependency graph or determine a safe multi-component transition. Investigating how to compose existing mechanisms is preferable to assuming a new management interface is needed.

Computing in the Network and Intent The IoT computing continuum can naturally integrate Computing in the Network (COIN), with eligible application functions executing in processing-capable network elements. Work in COINRG explored using network resources for computation and the relationship between computing and networking. From this application-centric perspective, a network element with suitable processing capabilities can serve as an execution environment for an application function. This extends placement beyond choosing among device, edge, and cloud hosts to considering processing within the network itself. For example, an application may place filtering, aggregation, or preprocessing in a programmable network element while retaining other functions on devices, edge hosts, or cloud platforms. Such a placement is conditional on execution capabilities, application semantics, resource limits, and administrative permissions. The connection to COIN is therefore part of the deployment model: the application graph can be mapped onto heterogeneous environments that include both computing hosts and processing-capable network elements. No particular in-network programming model or protocol is prescribed. This connection is distinct from the relationship to CoRE described above. CoRE discovery and management mechanisms are relevant to finding and managing constrained resources and their interfaces. On the other hand, COIN concerns using network elements as execution environments. The two perspectives can complement each other, but the model does not assume that an in-network execution environment exposes a CoRE interface. NMRG's work on intent-based networking, including the concepts and definitions in , is relevant to expressing desired outcomes separately from operational actions. A research question here is how application objectives, such as retaining local behavior during disconnection, can be translated into deployment constraints and checked against observed behavior. This document does not specify such a mapping.

Agent Communication and Dialog Management The agentproto Working Group is chartered to define a baseline agentic dialog management protocol and a reference architecture integrating related protocol building blocks. Its scope includes dialog identifiers, lifecycle semantics, and propagation of dialog context over existing IETF protocols. Here, dialog context refers to identifiers and lifecycle state used for correlation and continuity, rather than model prompts, retrieved documents, or conversation memory. This work is relevant to agents that coordinate deployment across heterogeneous execution environments and administrative boundaries. Correlating interactions and maintaining dialogs through interruptions can support exchanges among agents, operators, and tools in either orchestrated or choreographed applications. The relationship is complementary: this document considers which functions and agents execute where, how their responsibilities are coordinated, and how application behavior is preserved. Agentproto addresses interoperability of the dialogs used in those interactions. Its charter explicitly leaves agent decision-making and planning semantics outside its scope and does not replace application-layer protocols such as MCP or A2A. A migration of an application function or agent therefore still requires separate handling of execution state, authority, and application recovery.

Descriptions of Things and Application Abstractions The Semantic Definition Format (SDF) describes data and interaction models of Things. W3C WoT Thing Descriptions describe Things and their interaction affordances, including information used to access those interactions. Both are candidates for reuse when describing the device-facing capabilities on which application functions depend. Neither is treated here as a complete deployment language. Open questions include how such descriptions can be related to function dependencies, runtime requirements, permissible placements, state migration, and degraded operation. The appropriate reuse, composition, or extension of existing descriptions requires investigation before proposing new application-centric abstractions.

Research Directions The challenges and conceptual considerations discussed in this document point to several open research directions for smart application development and deployment across the IoT computing continuum. These directions are not exhaustive. Instead, they highlight areas that require further investigation to better understand how application structure, deployment decisions, coordination strategies, and lifecycle management interact in heterogeneous and dynamic environments. One research direction concerns defining application-centric abstractions for deployment. This investigation can start with existing descriptions of Things, including SDF and WoT Thing Descriptions , and assess which deployment information can be reused and which is still missing. While existing work has extensively explored infrastructure-level aspects of edge and continuum computing, a clear need remains for abstractions that let applications express functional decomposition, dependencies, and non-functional requirements independently of specific execution environments. Such abstractions would enable more systematic reasoning about placing, migrating, and adapting application components across stages of the IoT computing continuum, complementing existing architectural perspectives on edge computing and broader analyses of the computing continuum . A second research direction involves integrated approaches to application development and deployment. In the IoT computing continuum, development-time decisions about application structure, communication patterns, and state management are tightly coupled with deployment constraints, such as resource availability, connectivity, and latency. Traditional workflows that treat development and deployment as largely independent phases are therefore insufficient. Further research is needed to explore models, methodologies, and tools that explicitly account for this interdependence and that support feedback loops between design-time assumptions and runtime observations, building on early deployment-aware approaches such as those discussed in . Coordination strategies for distributed applications constitute another important research direction. Orchestration and choreography are complementary styles for coordinating distributed application components, each with distinct trade-offs in scalability, resilience, observability, and manageability. Understanding how these coordination styles can be combined, adapted, or dynamically transitioned as applications evolve and deployment conditions change remains an open problem. This includes investigating how coordination strategies interact with placement decisions, fault handling, and lifecycle operations across heterogeneous execution environments in the IoT computing continuum. Automation and intelligence in deployment and lifecycle management are another research area. Given the scale, heterogeneity, and dynamism of IoT environments, manual deployment, configuration, and adaptation quickly become impractical. Research into automated, declarative, or policy-driven approaches for placement, migration, and reconfiguration may help address these challenges, provided that such approaches remain transparent, controllable, and aligned with application-level objectives. These mechanisms must also account for IoT-specific constraints, including limited resources, intermittent connectivity, and decentralized control across administrative domains. An additional research direction builds on the dual role of AI agents in deployment discussed earlier in this document. That discussion raises open questions that remain largely unresolved: a) how agent responsibilities should be distributed between application-level and infrastructure-level concerns; b) how inter-agent interactions can be made secure, auditable, and aligned with Internet architectural principles, particularly when agents interact across administrative domains and heterogeneous environments; c) how orchestration and choreography styles may be combined dynamically in agent-based deployment; d) how the placement and lifecycle of the agents themselves, including proxy-based representation of constrained devices, can be managed without introducing new points of fragility or centralization. Emerging interaction frameworks such as and remain evolving, and further research is needed to assess how agent-based mechanisms can complement application-centric deployment models in the IoT computing continuum. Finally, a broader need remains for shared terminology and conceptual frameworks that facilitate comparison across research efforts and support dialogue with standardization activities. Without a common vocabulary for reasoning about application-centric deployment and lifecycle management in the IoT computing continuum, research results risk remaining fragmented and difficult to generalize. Informational documents that clarify the problem space, such as this one, can help align research agendas and identify areas where future standardization efforts within the IRTF or the IETF may be beneficial.

Security Considerations This document does not specify protocols, mechanisms, or architectures and therefore does not directly introduce new security vulnerabilities. However, the concepts discussed have important security implications worth considering. In the IoT computing continuum, application components are distributed across heterogeneous and potentially untrusted execution environments, increasing the attack surface and complicating traditional security assumptions. Deployment decisions influence trust boundaries, data exposure, and the ability to isolate faults or compromised components. Coordination strategies also have security implications. Orchestration-based approaches may introduce centralized control points that attackers can target, while choreography-based approaches rely on decentralized interactions that require robust authentication, authorization, and trust management among components. The tight coupling between development and deployment further emphasizes the need to consider security throughout the application lifecycle. Deployment changes, component migration, or runtime adaptation can invalidate design-time assumptions about trust, isolation, and access control. As a result, security considerations must be revisited whenever application structure, placement, or coordination strategies evolve. Finally, the distributed, multi-domain nature of the IoT computing continuum raises challenges in identity management, secure communication, and policy enforcement across administrative boundaries. While this document does not address these challenges, they underscore the importance of integrating security considerations into research and standardization efforts for application-centric deployment and lifecycle management.

IANA Considerations This document has no IANA actions.

Acknowledgments The authors acknowledge CGI.br (Brazilian Internet Steering Committee) for its support through the IETF/IRTF participation program, which enabled engagement in research and discussions within the Internet Research Task Force (IRTF).