6.2 Interworking Scenarios

6.2.1 Agentic IPE Generation Framework

6.2.1.1 Introduction

TS-0033 [i.23] defines the oneM2M interworking framework for representing interactions with devices or functions in proximal IoT networks that are not aware of oneM2M. At its core, the interworking architecture relies on the Interworking Proxy Entity (IPE) shown in Figure 6.2.1.1-1, which connects non-oneM2M Device Nodes (NoDNs) to a Common Services Entity (CSE).

This section introduces an agentic framework in which an AI Coding Agent autonomously implements an Interworking Proxy Entity using the Model Context Protocol (MCP) and associated skill definitions. The framework is designed to apply across a wide range of protocols, including MQTT, SensorThings API, OCF, Zigbee, among others.

Figure 6.2.1.1-1: Autonomous generated IPE

The objective of this interworking scenario is to enable the fully autonomous integration of non-oneM2M devices into the oneM2M ecosystem. For example, in an industrial context, new devices that do not natively speak oneM2M could be autonomously integrated into the oneM2M based production process, or new devices in home automation could be integrated into an existing oneM2M-based solution and controlled via a central app.

6.2.1.2 Framework Overview

Figure 6.2.1.2-1 provides an overview of the framework. The framework does not assume a specific deployment topology. Its elements may be co-located on a single machine or distributed across multiple nodes. Furthermore, not all elements are required in every deployment. The subset of elements to be instantiated depends on the use case. The framework operates in three phases and comprises the following components:

Phase Initialization:

Coding Agent: The coding agent is a neuro-symbolic system responsible for generating the IPE source code. While code generation is performed by an AI model, other functions such as workflow control, tool invocation, and resource management may be implemented as deterministic, symbolic processes.

The coding agent operates in three phases:

• Discovery and Setup: The coding agent performs an initial discovery phase, scanning the target network to identify active endpoints, their associated devices, and running services. Discovered URLs, IP addresses and ports are persisted for subsequent operations.

  Where required, additional infrastructure components are deployed to support the interworking function. This is necessary where no direct interworking specification exists between a device and the oneM2M CSE, but a standardised interface is defined between the oneM2M CSE and an intermediary component (e.g. MQTT-Broker, SensorThings API Server).

  Additionally, any authentication and authorization credentials required for accessing the discovered endpoints are to be provided by the user, either directly or by specifying a configuration from which the agent retrieves them.

  Depending on the service, additional service- or provider-specific resource paths are to be resolved beyond IP addresses and ports. For a oneM2M CSE, this includes the <CSEBase> resource path.

  The coding agent then determines the format, content, and frequency of messages from the target device and its supported protocol. The device node to be connected to the CSE may expose dedicated functions or configurations through a Device Node MCP Server. A Device Node Specific Skill provided by the device node vendor can describe detailed device properties and capabilities, along with the procedures required to interact with them.

  On the CSE side, the coding agent prepares the required data structures by creating <AE> resource and <container resources as needed. This may be facilitated through a oneM2M MCP Server connected to the hosting CSE. oneM2M-Specific skills, which may be self-authored, obtained from third-party sources, or published on the oneM2M repository, may further assist in this process by providing the agent with the necessary knowledge about resource structures, attribute definitions, and protocol bindings required to correctly provision the CSE resource tree

• Implementation: In this phase, the coding agent implements the Interworking Proxy Entity (IPE) based on the knowledge acquired in the previous steps. Coding agents typically produce higher quality code when provided with reference examples. Such examples can be made available through a Code Repository, for instance a Git-based version control system. Successfully validated and tested implementations can be stored there to serve as reference examples for future code generation tasks.

• Deployment: The completed IPE source code is deployed via a Deployment MCP Server to the designated staging environment. Typically, this is not the operational target environment, but a sandboxed environment in which the newly built application can be validated and tested without affecting live operations.

A more detailed description of the coding agent and its operations is provided in oneM2M TR-0085 [i.24].

Figure 6.2.1.2-1: Autonomous IPE Generation Framework

Phase Test and Validation:

As soon as the AI-generated IPE is deployed, it can be validated and tested. Since coding agents produce probabilistic outputs with no guarantee of functional correctness, deterministic tests are preferable. These may include verifying whether the IPE correctly writes data to the CSE.

In agentic coding, test driven development (TDD) is a common practice, where tests are defined prior to the actual implementation. Once the IPE is built, the predefined tests are expected to pass. The Validation and Test MCP Server supports this process by executing the appropriate tests either in the sandbox or at the interfaces of the IPE towards the IoT device or the CSE. The coding agent can configure the desired test setup and receive feedback on any errors encountered. In an additional validation step, it shall be verified that the data written to the CSE, such as <contentInstance> resources, meets the requirements of the use case and contains semantically meaningful content.

Phase Operation:

Once validated, the IPE is deployed to the operational target environment. To ensure that the IPE can operate independently outside of the framework, it shall be verified during the implementation phase that operational prerequisites, such as the preparation of data structures on the CSE, are encapsulated within the IPE itself and are checked and created by the IPE as required.

6.2.1.3 Scenario Discussion

MCP-Enabled Devices

Manufacturers of devices, services, or APIs may additionally provide an MCP server, either as a standalone component or as a hosted service, enabling agents to fully leverage the capabilities of the respective interface.

While skills describe the necessary processes, MCP servers provide the tools required to execute them. Exposing dedicated MCP servers and skills lowers integration complexity and enables agents to operate with higher reliability and efficiency.

Self-Evolving Systems

The scenario discussed in this document points to a broader architectural paradigm that may be described as self-evolving software architecture. If coding agents are capable of autonomously implementing missing interworking proxies on demand, entirely new usage scenarios and integration patterns become conceivable. Software components can autonomously integrate into existing infrastructures, with missing drivers or adapters generated as required. Infrastructures, software architectures, and networks become capable of extending themselves and expanding their operational scope without human intervention.

Agent-Native Specifications

The target audience of technical standards is undergoing a fundamental shift. While such documents have traditionally been authored for human readers, including technical decision-makers, architects, and developers, they are increasingly being consumed by AI coding agents as primary clients.

As coding agents become more prevalent in software development, the role of the human developer is shifting towards supervision and oversight, while the coding agent handles the technical implementation details. Consequently, the agent depends on precise and reliable knowledge of how specific processes and procedures actually operate.

This has direct implications for how specifications are structured and published. Documents will need to adopt machine-readable formats, such as Markdown or HTML, optimized for programmatic consumption. Terminology should be consistent and unambiguous, procedures should follow predictable patterns, and formal notations should be preferred over prose where applicable. Content should focus on precise, normative statements rather than background rationale or narrative overviews.

Furthermore, for truly agent-native specifications, it may become necessary to publish dedicated skills, enabling agents to directly translate the latest version of a specification into functional code.