oneM2M TR-0081Release Notes diff from v0.2.0 to v0.1.0oneM2M TR-0081Release Notes diff from v0.2.0 to v0.1.0Figure 6.0‑1 shows an architectural approach for an Interworking Proxy Entity (IPE), which is implemented as an MCP server, positioned between a oneM2M CSE and an AI agent. The interworking enables AI agents to receive data from a oneM2M CSE and/or to provide data to it.
Figure 6.0‑1: IPE architecture overview
An MCP server-based Interworking Proxy Entity can provide different levels of abstraction of the CSE to the agent. This means the AI agent needs to have varying degrees of knowledge about oneM2M and the CSE. The following examples illustrate three exemplary levels of agent knowledge about oneM2M:
The IPE hides all oneM2M functionalities:
The agent does not even need to know that oneM2M is involved behind the MCP server. This might be a solution for verticals, for agentic AI applications addressing certain specialized tasks. The agent might call a tool, for example, retrieving weather data from the IPE that is actually copied from the latest
The IPE allows for basic oneM2M functionalities:
The agent needs basic knowledge about major oneM2M concepts and/or data structures in a CSE. For example, the AI agent is able to read the latest
This solution is feasible when the agentic AI application needs more flexibility in data management. For example, during runtime it might be necessary to extend the data model because new categories of data emerge. So the agent might need to reorganize the data and create new containers. Still, not all oneM2M functionalities need to be covered by the IPE to minimize complexity. Given the fact that every description of available tools in the MCP server is part of the context window, it makes sense to minimize the number of tools. Especially smaller language models could be overwhelmed by too much context, leading to a degradation of accuracy and resulting in errors during tool execution.
The IPE allows (nearly) full control of oneM2M functionalities:
The agent might be a oneM2M expert and is able to manage a CSE and conduct administrative tasks. For example, access policies or subscriptions could be configured for certain data. This might be a solution when an agentic AI application should be used instead of a configuration UI for the CSE.
An IPE allowing nearly full control of a CSE needs a lot of different tools to call. Since language models are not very reliable in choosing one out of many different tools with various parameters, it is recommended to implement this kind of agents as neuro-symbolic systems, where tool calls are conducted by a deterministic software part of the agent. This is especially true for huge software implementations needing many (e.g., more than 20) different tools to fulfill their tasks. Countermeasures to minimize context usage in MCP and increase reliability in tool calling will be discussed in the next section.
The MCP protocol can introduce excessive token consumption, posing a significant challenge for agents and their associated language models. This occurs because the agent processes the complete list of available tools, including all contextual descriptions, to select the most suitable one for its current task. Furthermore, intermediate results are retained when multiple sequential tool calls are executed. Descriptions, intermediate results, system prompts, and user prompts combined can result in significant token overhead, which may either exceed the context window of smaller language models or, more generally, lead to decreased accuracy and errors during tool calls. In large-scale deployments, this problem becomes particularly acute: tool schema definitions for enterprise software platforms can consume well over 100,000 tokens before any user input is processed.
A Common Service Entity (CSE) is the core element of a oneM2M architecture, supporting a broad range of functions and resource types. Consequently, an MCP server for oneM2M may expose a large number of tools with extensive contextual descriptions, making it a prime candidate for the Layered Tool Pattern [i.22]. This applies in particular when the IPE exposes nearly full control over oneM2M functionalities (as described in the third level of agent knowledge about oneM2M, representing the highest degree of CSE control, see Section 6.0), where the number of tools and parameter sets can grow substantially.
The Layered Tool Pattern structures the interaction between the AI agent and the MCP server into three successive phases, rather than exposing the full set of tool definitions upfront:
Discovery: The agent queries only a compact overview of the CSE's general capabilities, for example whether resources can be created, queried, or updated, without loading detailed schemas into the context window.
Planning: The agent selects a specific task and retrieves only the targeted information required for its execution. For instance, when intending to store sensor data, the agent determines that an Application Entity (AE) must be registered and a <container> resource created before <contentInstance> resource can be submitted.
Execution: The agent invokes the actual tools, fully informed and with minimal context overhead.
This step-by-step approach keeps token consumption low and reduces the risk of incorrect tool selection, even when the underlying CSE exposes a large and diverse set of resources and operations.
AI agents need specialized instructions to perform well on specific tasks, but loading all relevant knowledge into context at once consumes excessive context window capacity. Skills [i.25] address this by packaging procedural knowledge into portable, version-controlled folders. The central component of each skill is SKILL.md, a markdown file containing exactly the knowledge an agent needs for a particular type of work, loaded into context only when needed. Because skills follow a common structure, they are reusable across different agents and can be shared, exchanged, or composed into larger systems without modification.
oneM2M-specific procedures can equally be described as skills. For example, a skill named onem2m-resource-subscribe might provide an agent with the procedural knowledge for operations such as creating a subscription on a
A skill package follows a defined directory structure:
onem2m-resource-subscribe/
├── SKILL.md ← metadata + instructions
├── references/ ← domain-specific docs loaded on demand
├── scripts/ ← executable helpers
├── assets/ ← templates, example payloads, schemas
└── ... ← any additional files or directoriesFigure 6.1.2‑1: Agent Skill folder structure
SKILL.md is the only required component. All other directories are optional and are consulted only when the specific situation requires them.
---
name: onem2m-resource-subscribe
description: Use this skill when an agent needs to create a subscription
on a oneM2M resource to receive notifications on state changes.
---Figure 6.1.2‑2: Agent Skill SKILL.md header
Skills follow a progressive disclosure principle. The SKILL.md file is divided into two parts: the name and description as a header in YAML format [i.26] as shown in Figure 6.1.2‑2, and the skill body containing the operational instructions. The header description is always present in the agent's context and serves exclusively as the criterion by which the language model decides whether to retrieve the skill body.
The full skill body is retrieved only when the language model evaluates the user's request and determines that it matches the skill's description. At that point, the language model loads the instructions into the agent's context, making them available for the current task. Supplementary resources in references/, scripts/, and assets/ are consulted only when the specific sub-task requires them. This ensures that an agent carries only the context directly relevant to its current operation.
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.
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
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
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.
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.