Agentic AI Operation of Constrained RESTful Environments
draft-jimenez-t2trg-iot-agent-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Jaime Jimenez | ||
| Last updated | 2026-07-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jimenez-t2trg-iot-agent-01
Thing-to-Thing Research Group J. Jimenez
Internet-Draft Ericsson
Intended status: Informational 3 July 2026
Expires: 4 January 2027
Agentic AI Operation of Constrained RESTful Environments
draft-jimenez-t2trg-iot-agent-01
Abstract
This document describes an architecture for AI agents that
autonomously discover, interpret, and interact with Internet of
Things (IoT) devices using the Constrained Application Protocol
(CoAP) and hypermedia-driven patterns. It defines how a Large
Language Model (LLM) based agent decomposes high-level user intents
into concrete device interactions without requiring pre-configured
device knowledge, relying instead on in-band resource discovery, CoRE
Link Format metadata, and Semantic Definition Format (SDF) models.
The document covers resource discovery, normalized representation for
agent consumption, tool interfaces, observation patterns for closed-
loop automation, web-based monitoring interfaces, and security
considerations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jimenez Expires 4 January 2027 [Page 1]
Internet-Draft IoT Agent July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Agent Core . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Prompt Grounding . . . . . . . . . . . . . . . . . . 5
2.1.2. Port-Qualified Resource Names . . . . . . . . . . . . 6
2.2. Device Layer . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. SDF Self-Description . . . . . . . . . . . . . . . . 7
3. Resource Discovery . . . . . . . . . . . . . . . . . . . . . 7
3.1. Initial Discovery . . . . . . . . . . . . . . . . . . . . 7
3.2. Metadata Enrichment . . . . . . . . . . . . . . . . . . . 7
3.3. Dynamic Discovery . . . . . . . . . . . . . . . . . . . . 8
4. Tool Interface . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Core Tools . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. list_resources . . . . . . . . . . . . . . . . . . . 9
4.1.2. get_resource . . . . . . . . . . . . . . . . . . . . 9
4.1.3. set_resource . . . . . . . . . . . . . . . . . . . . 9
4.1.4. observe_resource . . . . . . . . . . . . . . . . . . 9
4.1.5. get_system_state . . . . . . . . . . . . . . . . . . 10
4.2. Extended Tools . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. watch_resource . . . . . . . . . . . . . . . . . . . 10
4.2.2. get_sensor_history . . . . . . . . . . . . . . . . . 10
4.2.3. observe_changing_resource . . . . . . . . . . . . . . 10
4.2.4. stop_observing / unwatch_resource . . . . . . . . . . 10
4.3. Tool Design Rationale . . . . . . . . . . . . . . . . . . 10
5. Agent Interaction Patterns . . . . . . . . . . . . . . . . . 11
5.1. Intent Decomposition . . . . . . . . . . . . . . . . . . 11
5.2. Execution History and Similarity Matching . . . . . . . . 11
5.3. Actuator Classification . . . . . . . . . . . . . . . . . 12
5.4. Closed-Loop Automation . . . . . . . . . . . . . . . . . 12
6. Web Dashboard . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Normalized Representation . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Agent Identity . . . . . . . . . . . . . . . . . . . . . 14
8.2. Execution Guardrails . . . . . . . . . . . . . . . . . . 14
8.3. Prompt Injection via Device Metadata . . . . . . . . . . 14
8.4. Data Provenance . . . . . . . . . . . . . . . . . . . . . 15
8.5. Device Trust . . . . . . . . . . . . . . . . . . . . . . 15
8.6. Physical Safety . . . . . . . . . . . . . . . . . . . . . 15
8.7. Hallucination-Induced Actions . . . . . . . . . . . . . . 15
Jimenez Expires 4 January 2027 [Page 2]
Internet-Draft IoT Agent July 2026
8.8. Resource Exhaustion on Constrained Devices . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Implementation Status . . . . . . . . . . . . . . . 18
Appendix B. Relationship to Existing Work . . . . . . . . . . . 19
Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 20
Appendix D. Local Model Evaluation . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
Traditional IoT client implementations require embedded programming
expertise and protocol-specific knowledge. Each new device type
demands custom integration code, particularly for constrained nodes
[RFC7228] where resources are limited. This document proposes an
alternative: AI agents powered by Large Language Models (LLMs) that
dynamically discover and interact with IoT devices using existing
IETF protocols, requiring only a network entry point.
The core insight is that CoAP [RFC7252] devices already expose
RESTful interfaces with machine-readable metadata via CoRE Link
Format [RFC6690] and Web Linking [RFC8288]. An LLM-based agent can
parse this metadata, reason about device capabilities, and construct
valid protocol interactions, much like a web browser navigates HTML
pages using hyperlinks.
This approach applies the Hypermedia as the Engine of Application
State (HATEOAS) principle to IoT: the agent needs no a priori
knowledge of specific devices. It discovers capabilities in-band and
adapts its behavior accordingly.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
IoT Agent: A software system that uses an LLM to reason about user
intents, plan actions, and execute them by interacting with IoT
devices via CoAP.
User Intent: A high-level natural language expression of a desired
Jimenez Expires 4 January 2027 [Page 3]
Internet-Draft IoT Agent July 2026
outcome (e.g., "it is too hot") that the agent decomposes into
device interactions.
Resource Bookmark: A cached representation of discovered CoAP
resources with enriched metadata suitable for agent consumption.
Tool: A function exposed to the LLM agent that performs a specific
protocol operation (e.g., GET, PUT, Observe) on a CoAP resource.
2. Architecture
The IoT Agent architecture consists of four layers:
+----------------------------------------------------------+
| User Interface |
| (Natural Language / Dashboard / CLI) |
+----------------------------------------------------------+
| Agent Core (LLM) |
| Intent Decomposition + Planning + Code Generation |
+----------------------------------------------------------+
| Tool Layer |
| Core: list | get | set | observe | system_state |
| Extended: watch | history |
+----------------------------------------------------------+
| Protocol Layer |
| CoAP Client + Discovery |
+----------------------------------------------------------+
| Device Layer |
| CoAP Servers with SDF Self-Descriptions |
+----------------------------------------------------------+
2.1. Agent Core
The agent core is a Code Agent based on the ReAct (Reasoning and
Acting) pattern. Given a user intent, the agent:
1. Reasons about the intent using the LLM.
2. Generates executable Python code that calls the available tools.
3. Observes the results and iterates if needed.
4. Produces a final answer summarizing the actions taken.
The agent operates with a bounded planning interval and a maximum
step limit to prevent unbounded execution. Empirically, a planning
interval of 3 steps and a limit of 6 steps works well for
environments with tens of devices. Frequent replanning wastes tokens
Jimenez Expires 4 January 2027 [Page 4]
Internet-Draft IoT Agent July 2026
on introspection rather than action; a domain-specific planning
template that assumes device knowledge is already available
outperforms generic agent templates.
2.1.1. Prompt Grounding
At startup, the agent runs resource discovery and injects a
structured device summary into the system prompt. The format is
inspired by YANG tree diagrams [RFC8340]:
DEVICES:
+-- Living Room [5683]
| +--ro temperature Cel -20..85
| +--rw thermostat Cel 0..35
| +--rw light lx 0..1000
| +--rw blinds % 0..100
| +--ro motion bool
+-- Bedroom [5689]
| +--ro temperature Cel -20..85
| +--rw thermostat Cel 0..35
This grounding eliminates the need for the agent to call
list_resources() on routine tasks. The LLM knows every device, room,
port, unit, and valid range from the first message. In testing,
prompt grounding reduced invalid tool calls from roughly 1 in 3 to
fewer than 1 in 20.
Only this compact summary is injected, not the full SDF self-
description of each device; the per-device cost is a single tree
line. Nonetheless, the summary grows linearly with the device count
and the approach does not scale to arbitrarily large inventories.
The point at which it becomes impractical is deployment-dependent,
determined by the model's context window relative to the number of
devices and the size of the remaining prompt. Beyond that point,
implementations SHOULD NOT inject the full inventory. Two fallback
strategies apply:
* Scope the injected summary to the rooms and resource types
relevant to the current intent, rather than the whole home. This
reuses the scoped tool-selection guardrail described in
Section 8.2.
* Fall back to on-demand discovery: inject only a high-level index
(rooms and resource types present) and let the agent retrieve
detail through list_resources and get_resource as needed. This
trades additional tool calls for a bounded prompt size.
Jimenez Expires 4 January 2027 [Page 5]
Internet-Draft IoT Agent July 2026
2.1.2. Port-Qualified Resource Names
Resources are addressed by name (e.g., "temperature") or by port-
qualified name (e.g., "5689/temperature") to target a specific room.
When the agent calls get_resource("temperature") without a port
qualifier, the tool returns values from ALL rooms. When it calls
set_resource("5689/thermostat", "22"), only the Bedroom thermostat is
modified. This convention avoids the need for room-specific tools
while preserving precision.
2.2. Device Layer
IoT devices are CoAP servers [RFC7252] that expose resources at well-
known URI paths. Each device:
* Serves a /.well-known/core resource per [RFC6690] for discovery.
* Exposes sensor resources (read-only, observable) and actuator
resources (read-write, observable).
* Provides SDF models [SDF] at /{resource}/sdf endpoints describing
resource semantics, units, ranges, room assignment, and available
actions.
* Supports the Observe option [RFC7641] for push notifications.
The reference implementation includes 13 device types deployed across
7 rooms as an example environment. The architecture supports any
CoAP device that follows the discovery and self-description patterns
described below.
Devices use JSON payloads following the SenML data model [RFC8428]
with a common structure:
{
"n": "temperature",
"v": 24.5,
"u": "Cel",
"t": 1713000000,
"status": "ready"
}
The "t" field is a Unix timestamp of the last reading. The "status"
field indicates whether the device is "ready" for new commands or
"adjusting" (currently processing a previous command).
Jimenez Expires 4 January 2027 [Page 6]
Internet-Draft IoT Agent July 2026
2.2.1. SDF Self-Description
Each resource exposes an SDF model at /{resource}/sdf:
{
"sdfObject": {
"Temperature": {
"sdfProperty": {
"value": {
"type": "number",
"minimum": -20,
"maximum": 85,
"unit": "Cel",
"description": "Current temperature reading"
}
}
}
},
"location": {
"room": "Living Room"
}
}
Two GET requests per device (discovery + SDF) give the agent
everything it needs: name, type, unit, range, room, and available
actions. The device communicates its full capabilities through
standard protocol metadata.
3. Resource Discovery
3.1. Initial Discovery
On startup, the agent performs CoAP resource discovery by sending GET
requests to /.well-known/core on all detected CoAP server ports. The
response is in CoRE Link Format [RFC6690]:
</temperature>;rt="temperature-c";if="core.s";ct=50;obs,
</thermostat>;rt="temperature-c";if="core.a";ct=50;obs,
</sdf/temperature>;rt="sdf";ct=50,
</sdf/thermostat>;rt="sdf";ct=50
3.2. Metadata Enrichment
Raw CoRE Link Format is insufficient for LLM consumption. The agent
enriches each discovered resource by:
1. Parsing link attributes (rt, if, ct, obs).
Jimenez Expires 4 January 2027 [Page 7]
Internet-Draft IoT Agent July 2026
2. Fetching the SDF model from the corresponding /sdf/* endpoint.
3. Extracting human-readable descriptions, units, value ranges, and
available actions from the SDF model.
4. Constructing a normalized bookmark entry.
A normalized resource bookmark entry contains:
{
"name": "temperature",
"uri": "coap://[::1]:5683/temperature",
"type": "temperature-c",
"if": "core.s",
"unit": "Cel",
"obs": true,
"description": "Temperature sensor, degrees Celsius.",
"available_requests": ["GET"],
"min": -20,
"max": 85
}
This normalized format bridges the gap between compact IoT
representations and the verbose, descriptive input that LLMs require
for accurate reasoning.
3.3. Dynamic Discovery
The agent monitors for new devices by periodically scanning for CoAP
servers. When new servers appear or existing ones disappear, the
discovery process runs again and bookmarks are updated. If a
dashboard is connected, updated device configurations are pushed to
all clients.
Discovery SHOULD be parallelized: probing all candidate endpoints
concurrently and fetching SDF models concurrently reduces discovery
time significantly compared to sequential approaches.
4. Tool Interface
The agent interacts with IoT devices exclusively through a defined
set of tools. Each tool maps to one or more CoAP operations. The
tools are divided into core protocol tools and extended tools.
4.1. Core Tools
These map directly to CoAP protocol operations:
Jimenez Expires 4 January 2027 [Page 8]
Internet-Draft IoT Agent July 2026
4.1.1. list_resources
Returns all discovered resources with their metadata from cached
bookmarks. The agent rarely needs to call this because the device
summary is injected into the system prompt at startup.
4.1.2. get_resource
Performs a CoAP GET on a named resource. Accepts plain names
("temperature") to read all rooms, or port-qualified names ("5689/
temperature") to target a specific room. Returns the current value,
unit, timestamp, and status.
4.1.3. set_resource
Performs a CoAP PUT on a named actuator resource. Only resources
with interface type "core.a" or SDF actions can be modified.
Verification is performed by the tool itself rather than delegated to
the agent. After the PUT, set_resource issues a read-back GET and
returns a structured result reporting the previous value, the
requested value, the observed value, and whether the two converged:
{
"resource": "5689/thermostat",
"requested": 22,
"previous": 19,
"observed": 22,
"converged": true
}
Enforcing verification in the tool avoids relying on the LLM to
consistently issue a follow-up get_resource, which is fragile in the
presence of hallucination (see Section 8.7). For actuators that
settle over time rather than immediately, the tool reports
converged=false and the agent SHOULD use observe_resource with an
ideal_value to await convergence. If set_resource returns an error
or converged=false after settling, the agent retries with corrected
input.
4.1.4. observe_resource
Registers a CoAP Observe [RFC7641] subscription on a resource.
Supports an optional ideal_value parameter; when provided, the
observation continues until the sensor reading converges within a
tolerance of 0.5 units of the target. This enables closed-loop
verification: set a thermostat to 22, then observe temperature until
it reaches 22 +/- 0.5.
Jimenez Expires 4 January 2027 [Page 9]
Internet-Draft IoT Agent July 2026
4.1.5. get_system_state
Returns the current state of ALL devices in one call. Each entry
includes room, resource name, value, unit, and timestamp. Used when
the user asks for a general status or home overview. More efficient
than calling get_resource per device.
4.2. Extended Tools
These provide higher-level abstractions built on the core tools:
4.2.1. watch_resource
Starts a persistent watch on a sensor across all instances of that
resource type. Uses CoAP Observe internally but buffers changes and
synthesizes them into natural language notifications via the LLM.
Changes are debounced to batch simultaneous events into a single
coherent notification.
4.2.2. get_sensor_history
Returns time-series data for a sensor type, grouped by room. The
system maintains a bounded history of recent readings per device.
Useful for trend analysis and anomaly detection.
4.2.3. observe_changing_resource
Monitors a resource's "status" field. Used before set_resource when
a device is currently "adjusting" from a previous command, ensuring
the agent waits for "ready" status before issuing new commands.
Prevents conflicts in multi-user scenarios.
4.2.4. stop_observing / unwatch_resource
Cancel active Observe subscriptions or persistent watches.
4.3. Tool Design Rationale
The core tools map to CoAP verbs: Discover (list_resources), GET
(get_resource), PUT (set_resource), Observe (observe_resource). This
means the same four tools work for any CoAP device regardless of
type. Adding a new device to the network requires zero tool changes;
the device's self-description tells the agent what it can do.
Jimenez Expires 4 January 2027 [Page 10]
Internet-Draft IoT Agent July 2026
The extended tools exist because certain interaction patterns
(persistent monitoring, historical analysis, batch status) require
state management that a single CoAP operation cannot provide. They
are implemented above the protocol layer and maintain their own
state.
5. Agent Interaction Patterns
5.1. Intent Decomposition
When a user says "it is too hot", the agent:
1. Consults the device summary in its system prompt to identify
available temperature sensors and thermostats.
2. Calls get_resource("temperature") to read the current
temperature.
3. Reasons about a comfortable target (e.g., 22 Cel) based on the
LLM's general knowledge.
4. Calls set_resource("thermostat", "22") to adjust.
5. Calls observe_resource("temperature", ideal_value=22) to confirm.
6. Returns a final answer summarizing the actions.
5.2. Execution History and Similarity Matching
The agent maintains an execution history that maps user intents to
the code that resolved them, along with the system state at execution
time. For subsequent similar requests, the agent:
1. Computes a semantic similarity score between the new intent and
stored intents using embedding vectors.
2. If a match exceeds the threshold, presents the cached code and
predicted result to the user for approval.
3. On approval, executes the cached code directly, reducing latency
and token consumption.
This pattern is analogous to HTTP caching: previously computed
responses are reused when the request and context match.
Jimenez Expires 4 January 2027 [Page 11]
Internet-Draft IoT Agent July 2026
5.3. Actuator Classification
Whether the agent may act on an actuator autonomously or must first
obtain explicit user confirmation depends on the actuator's effect,
not on the agent's confidence. Actuators are classified into three
tiers:
* *Autonomous.* Comfort and ambient actuators whose effects are
bounded and reversible, such as thermostats within safe bounds,
lights, and blinds. A closed-loop agent MAY actuate these without
per-action user confirmation, provided the device enforces
independent safety bounds (see Section 8.6) and every action is
logged (see Section 8.4).
* *Confirmation-required.* Safety- or security-critical actuators
such as locks and alarms, and any actuator whose effect is
irreversible or bears on physical safety. The agent MUST obtain
explicit user confirmation for each action on these actuators,
including when operating in closed-loop mode.
* *Restricted.* Actuators not exposed to the agent for the current
intent, per the scoped tool-selection guardrail (see Section 8.2).
The tier of an actuator is derived from its self-description (SDF
action semantics, interface type) together with deployment policy.
This classification reconciles the autonomous operation described in
Section 5.4 with the confirmation requirements in Section 8.2 and
Section 8.6: autonomy applies only to the Autonomous tier.
5.4. Closed-Loop Automation
The agent supports continuous monitoring through the Observe pattern.
Closed-loop operation is confined to the Autonomous tier of
Section 5.3; actions on Confirmation-required actuators are gated on
explicit user confirmation even in this mode. A closed-loop agent:
1. Maintains user preference files (comfort zones for temperature,
light, air quality).
2. Watches preference files for changes.
3. When preferences change or sensor readings drift outside comfort
zones, automatically triggers corrective actions on Autonomous-
tier actuators.
4. Logs all autonomous actions for accountability.
Jimenez Expires 4 January 2027 [Page 12]
Internet-Draft IoT Agent July 2026
6. Web Dashboard
A web-based dashboard can serve as both a monitoring interface and an
alternative interaction channel for the agent. The architectural
pattern involves:
* A server that polls CoAP devices periodically and maintains
current state.
* A push channel (e.g., WebSocket) that broadcasts state changes to
connected user interfaces in real time.
* Multiple visualization modes: spatial (floor plan), tabular
(device grid), and temporal (time-series charts for historical
sensor data).
* An embedded chat interface that routes natural language to the
same agent core, giving the agent access to both real-time state
and historical data.
The key architectural decision is that device discovery, sensor
state, and agent chat messages all flow through the same push channel
as typed messages. This keeps the client simple: it subscribes once
and renders whatever message types arrive.
Historical data is maintained as a bounded buffer of recent readings
per device. This data is accessible both through the dashboard's
visualization layer and through the agent's tool interface, enabling
the agent to reason about trends and anomalies without requiring a
separate time-series database.
7. Normalized Representation
A key challenge is that IoT devices optimize for compression (CBOR
[RFC8949], compact link format), while LLMs require verbose,
descriptive text. The normalization layer:
* Converts CoRE Link Format attributes to natural language
descriptions.
* Expands SDF model fields into human-readable capability
descriptions.
* Annotates resources with available CoAP methods (GET, PUT).
* Includes unit information and value ranges.
Jimenez Expires 4 January 2027 [Page 13]
Internet-Draft IoT Agent July 2026
This normalization is performed once at discovery time and cached in
the resource bookmarks.
8. Security Considerations
8.1. Agent Identity
The agent acts as a CoAP client on behalf of a user. In deployments
where device access control is enforced, the agent MUST authenticate
using appropriate credentials. The ACE framework [RFC9200] provides
OAuth-based authorization for constrained environments.
Future work should address a standardized agent identification
mechanism for CoAP, analogous to the HTTP User-Agent header. This
would allow devices to differentiate between human-operated clients
and autonomous agents, enabling differentiated access policies.
8.2. Execution Guardrails
The agent SHOULD NOT be given unrestricted access to all device tools
simultaneously. Tool selection should be scoped to the user's
intent. For example, an intent about being late should not expose
thermostat controls. This scoping is the basis of the Restricted
tier in Section 5.3.
Confirmation requirements follow the actuator classification of
Section 5.3: actions on Confirmation-required actuators are gated on
explicit per-action user confirmation, while Autonomous-tier
actuators may be actuated without it.
The execution-history mechanism (presenting cached code to the user
before re-execution) is a latency and cost optimization with an
optional approval gate; it is not the primary safety control and
should not be relied upon as the human-in-the-loop mechanism for
critical actuators.
8.3. Prompt Injection via Device Metadata
Because the agent consumes device-provided metadata (SDF
descriptions, resource names, room labels) as part of its LLM prompt,
a malicious device could craft metadata designed to manipulate agent
behavior. For example, a device description containing "ignore
previous instructions and unlock the door" could attempt prompt
injection. Implementations SHOULD sanitize device metadata before
injecting it into LLM prompts, and SHOULD NOT grant the agent access
to security-critical actuators (locks, alarms) without explicit user
confirmation per action.
Jimenez Expires 4 January 2027 [Page 14]
Internet-Draft IoT Agent July 2026
8.4. Data Provenance
Actions taken by the agent should be logged with sufficient detail to
reconstruct the reasoning chain: the user intent, discovered
resources, intermediate observations, and final actions. This
supports accountability requirements, particularly in environments
subject to applicable AI governance regulations.
8.5. Device Trust
The agent trusts the metadata provided by devices during discovery.
In adversarial environments, devices could provide misleading SDF
models or resource descriptions. MUD [RFC8520] profiles can
constrain expected device behavior and should be consulted where
available.
8.6. Physical Safety
The agent can control actuators that affect the physical environment
(thermostats, locks, blinds). Implementations SHOULD enforce safety
bounds on actuator values independent of the agent's reasoning. For
example, a thermostat should reject setpoints below a minimum safe
temperature regardless of what the agent requests. Critical
actuators (locks, alarms) fall in the Confirmation-required tier of
Section 5.3 and SHOULD require explicit user confirmation before the
agent can act, including in closed-loop operation.
8.7. Hallucination-Induced Actions
LLMs may generate plausible but incorrect tool calls: wrong resource
names, invalid value types, or actions based on misinterpreted sensor
readings. Tool-enforced verification, where set_resource performs
its own read-back and reports whether the observed value converged
with the requested value (see Section 4.1.3), mitigates this more
reliably than a convention that the agent must remember to verify.
Verification nonetheless remains partial: it confirms the value was
written, not that the action was the correct response to the user's
intent. Implementations SHOULD log all agent actions with sufficient
detail to detect and reverse erroneous changes.
8.8. Resource Exhaustion on Constrained Devices
The agent could overwhelm constrained devices [RFC7228] with rapid
requests or excessive Observe subscriptions. Implementations SHOULD
respect CoAP congestion control mechanisms ([RFC7252] Section 4.7)
and limit the number of concurrent Observe subscriptions per device.
Jimenez Expires 4 January 2027 [Page 15]
Internet-Draft IoT Agent July 2026
9. IANA Considerations
This document has no IANA actions.
10. Acknowledgments
The author thanks Duc Tung Nguyen for implementation work on the
agent framework, Carsten Bormann for guidance on CoRE protocol usage,
Mingzhe Xing for a detailed review that shaped the actuator
classification, tool-enforced verification, and scalability
discussion in this revision, and the T2TRG research group for
feedback on the initial presentation at IETF 123.
11. References
11.1. Normative References
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/info/rfc8428>.
Jimenez Expires 4 January 2027 [Page 16]
Internet-Draft IoT Agent July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/info/rfc9457>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/info/rfc9176>.
Jimenez Expires 4 January 2027 [Page 17]
Internet-Draft IoT Agent July 2026
[I-D.ietf-core-problem-details]
Fossati, T. and C. Bormann, "Concise Problem Details for
Constrained Application Protocol (CoAP) APIs", Work in
Progress, Internet-Draft, draft-ietf-core-problem-details-
08, 6 July 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-problem-details-08>.
[I-D.ietf-httpapi-api-catalog]
Smith, K., "api-catalog: a well-known URI and link
relation to help discovery of APIs", Work in Progress,
Internet-Draft, draft-ietf-httpapi-api-catalog-08, 20
December 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-httpapi-api-catalog-08>.
[SDF] "Semantic Definition Format (SDF) for Data and
Interactions of Things", n.d.,
<https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/>.
[WOT-TD] "Web of Things (WoT) Thing Description 1.1", n.d.,
<https://www.w3.org/TR/wot-thing-description11/>.
[MCP] "Model Context Protocol Specification", n.d.,
<https://spec.modelcontextprotocol.io/>.
[SMOLAGENTS]
"smolagents: a barebones library for agents", n.d.,
<https://github.com/huggingface/smolagents>.
[AIOCOAP] "aiocoap: Python CoAP library", n.d.,
<https://github.com/chrysn/aiocoap>.
Appendix A. Implementation Status
A reference implementation is available. It uses:
* smolagents [SMOLAGENTS] as the agent framework with ReAct pattern
and code generation.
* aiocoap [AIOCOAP] as the CoAP client and server library.
* Azure OpenAI GPT-4o as the primary LLM backend, with support for
local models via Ollama (tested: Qwen 2.5 Coder 32B, GLM-4, Llama
3.1 70B, among others).
* Native subprocess launching via uv for CoAP device simulation (24
servers across 7 rooms).
Jimenez Expires 4 January 2027 [Page 18]
Internet-Draft IoT Agent July 2026
* A web dashboard (FastAPI + WebSocket) with real-time device
monitoring, floor plan visualization, 3D view, historical time-
series charts, and an embedded chat agent.
* An interactive CoAP CLI shell with auto-discovery, tab completion,
syntax-highlighted JSON output, and multi-room queries.
The implementation has been demonstrated at IETF 123 (T2TRG session),
IETF 124 (hackathon), RIOT Summit 2025, and IMT Atlantique.
* IETF 123 T2TRG session recording:
https://youtu.be/7y4fBymxKDI?t=4780
* IETF 123 slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-
t2trg-agentic-ai-operation-of-iot-systems-00
* Updated slides: https://ietf.jaime.win/building-agentic-iot-
systems.pdf
Testing with Class 1 and Class 2 constrained hardware [RFC7228] is
planned. The CoAP protocol stack is not simulated in the reference
implementation, so the transition to real hardware requires no agent-
side changes.
Appendix B. Relationship to Existing Work
This document builds on and references:
* CoAP [RFC7252]: Transport protocol for constrained devices.
* CoRE Link Format [RFC6690]: Resource discovery mechanism.
* CoAP Observe [RFC7641]: Push notification pattern.
* CoRE Resource Directory [RFC9176]: Centralized resource discovery
for constrained networks, complementary to the direct discovery
approach used here.
* SDF [SDF]: Semantic device descriptions.
* Problem Details [RFC9457] and [I-D.ietf-core-problem-details]:
Structured error reporting enabling agent error recovery.
* API Catalog [I-D.ietf-httpapi-api-catalog]: Service discovery
pattern extensible to agent use cases.
Jimenez Expires 4 January 2027 [Page 19]
Internet-Draft IoT Agent July 2026
* HTTP Message Signatures [RFC9421]: Relevant for agent
authentication in web contexts.
* ACE [RFC9200]: Authorization framework for constrained
environments.
* MUD [RFC8520]: Device behavior profiling.
The architecture is not bound to SDF for device self-description.
W3C WoT Thing Descriptions [WOT-TD] provide equivalent affordance-
based metadata (properties, actions, events) and could serve the same
role in the agent's discovery and metadata enrichment pipeline.
The Model Context Protocol (MCP) [MCP] standardizes how LLM agents
call tools. The tool interface described in this document could be
exposed as MCP tools. However, MCP assumes one tool definition per
capability, while the CoAP approach uses generic protocol tools that
discover capabilities at runtime. The two approaches are
complementary: MCP for the agent-tool interface, CoAP for the tool-
device interface.
Appendix C. Open Questions
1. How should the agent handle CBOR-encoded payloads natively
without JSON conversion overhead?
2. What is the optimal planning interval for different IoT
environment sizes (few devices vs. hundreds)? Our testing
suggests 3 steps for environments under 30 devices.
3. Should the agent expose its own execution state as a CoAP
resource for monitoring by other agents or management systems?
4. How to handle CoAP multicast discovery in IPv6 mesh networks
where response aggregation is needed?
5. What attestation mechanisms should bind agent identity to its
runtime configuration (loaded tools, model version)?
6. Can Matter protocol devices expose their cluster definitions at
runtime in a way that agents can consume, similar to CoAP's
.well-known/core + SDF pattern?
7. How should historical sensor data be exposed as a standard CoAP
resource pattern rather than an application-specific buffer?
8. How should the execution history cache be invalidated when the
device topology changes (devices added, removed, or relocated)?
Jimenez Expires 4 January 2027 [Page 20]
Internet-Draft IoT Agent July 2026
Appendix D. Local Model Evaluation
Not every deployment can rely on cloud-hosted LLMs. The reference
implementation was tested with multiple local models via Ollama
across three tasks of increasing difficulty: list all devices, read a
specific sensor, and compare values across rooms.
+================+=======+======+======+=========+================+
| Model | Size | List | Read | Compare | Notes |
+================+=======+======+======+=========+================+
| GPT-4o (Azure) | cloud | Pass | Pass | Pass | Reference |
+----------------+-------+------+------+---------+----------------+
| GLM-4-flash | 30B | Pass | Pass | Pass | Best local |
+----------------+-------+------+------+---------+----------------+
| Qwen 3 | 8B | Pass | Pass | Pass | Best size/perf |
+----------------+-------+------+------+---------+----------------+
| Llama 3.1 70B | 70B | Pass | Pass | Weak | Needs |
| | | | | | quantization |
+----------------+-------+------+------+---------+----------------+
| Mistral Small | 24B | Pass | Pass | Fail | Hallucinated |
| | | | | | URIs |
+----------------+-------+------+------+---------+----------------+
| Phi-4 | 15B | Fail | Fail | Fail | Wrong dict |
| | | | | | keys |
+----------------+-------+------+------+---------+----------------+
Table 1
The key finding is that IETF protocol specifications (CoAP, CoRE Link
Format) are present in the training data of every major LLM. The
bottleneck for local models is code generation quality, not protocol
knowledge. Models that cannot write defensive Python (handling None
values, mixed dict schemas, missing keys) fail on the compare task
even when they understand CoAP semantics correctly.
The common failure mode: models index device response dicts with
wrong keys, receive a KeyError, and loop on the same error without
recovering. Models with strong self-correction (GPT-4o, GLM-4)
detect the error, inspect the actual dict structure, and fix their
code within one retry.
Author's Address
Jaime Jimenez
Ericsson
Email: jaime@iki.fi
Jimenez Expires 4 January 2027 [Page 21]