PAWR, the Protocol for Agentic Wearable Resources

A CoAP/CBOR protocol for offloading agentic workloads between a constrained body-worn device (smart glasses, an earbud, a ring) and a cloud or edge agent. I am writing it as an IETF draft, draft-bouazizi-core-pawr, and maintaining two implementations of it.

• Try it now: PAWR Wire Bench, a Device and an Agent running in your browser, with every datagram on screen.
• Source: github.com/ibouazizi/wap, MIT licensed. The Python and TypeScript source packages are now named pawr-protocol. The repository URL retains its original name.

Why it exists

The agent protocols the industry has settled on, MCP and Google's A2A, assume an HTTP/JSON substrate and a resource envelope a wearable does not have. Smart glasses run inside a power budget of tens of milliwatts, over a link that comes and goes, and they carry the most privacy-sensitive sensor streams a person owns: their heart rate, what they are looking at, what they are hearing.

PAWR targets that regime directly. It is a CoAP application profile with compact CBOR messages on UDP, device-side budget negotiation, on-device reflex rules, a tamper-evident audit log, and episodic memory the agent can query instead of re-uploading context. A typical control message is under ten bytes.

What is different

The central inversion is authority. In PAWR the Device is authoritative. The Agent proposes a sensor configuration or a budget ceiling; the Device negotiates it downward to stay inside its own limits and reports what it actually granted. An Agent that reads the response instead of assuming it got what it asked for is a well-behaved PAWR Agent.

Four engines sit behind the Device's CoAP resource tree:

• Budget. Power, bandwidth, thermal and sensor-count ceilings. Every request is priced from the driver's own datasheet prediction, and a request that does not fit is stepped down in rate and quality until it does, or refused with a reason. Proposed ceilings are clamped to hard limits the Agent cannot move.
• Delegation. Reflex rules such as when heart rate exceeds 180, fire the haptic and switch the PPG to burst mode. A rule runs on the Device on every reading, with no Agent round trip, so a safety reflex keeps working while the uplink is down.
• Audit. Every protocol event is sealed into a SHA-256 hash chain computed over deterministic CBOR, so any implementation can verify a chain written by any other. It is tamper-evident, not tamper-proof: an edit after the fact breaks every later link.
• Memory. A ring of timestamped embeddings on the Device. The Agent recalls by similarity and receives only the matching segments.

Streaming is an observed GET (CoAP Observe), not a push channel, so the Device controls notification cadence within its budget.

Measured on real glasses

The rename to PAWR does not change the reported results.

I ran the same five agent scenarios (continuous health monitoring, visual perception, audio perception, navigation and motion coaching, a privacy-preserving cognitive assistant) end to end on a RayNeo X3 Pro against the same backend, once over PAWR, once over A2A and once over MCP. The clean energy proxy on a wearable is on-device CPU seconds, because the display floor of roughly 0.6 W buries protocol differences in the fuel gauge.

PAWR delivered the same agent outcomes at about 1.7x lower latency and 2.9x lower on-device CPU cost than MCP, with A2A in between and no loss of capability. The advantage is structural: binary CBOR and a single CoAP exchange, against verbose JSON tool envelopes that the wearable has to parse and serialise on every step.

A sixth use case, split vision-language inference, runs the Qwen3-VL vision encoder on the glasses' NPU and streams the result over PAWR. There the encoder, not the protocol, dominates time and energy (85 to 99 percent of both), and payload compression decides whether a frame is deliverable at all over the real glasses-to-cloud path: raw visual tokens at 459 kB never arrive inside an 8 second deadline, while a 4 kB single-datagram frame arrives in about 150 ms.

Implementations

Python reference. The renamed source distribution is pawr-protocol, with the import package pawr. Install from the repository's oss/ directory using python -m pip install .. It uses aiocoap and cbor2, simulated sensors so a Device runs with no hardware, and the four engines usable on their own. The source rename does not imply publication of the renamed package to PyPI.

TypeScript port. Zero runtime dependencies. It carries its own CBOR codec, SHA-256, and a minimal CoAP core (RFC 7252 messaging with retransmission and Observe) over a pluggable transport, so the same code runs over UDP in Node, in memory in a browser, and later over CoAP-over-WebSockets. It implements the protocol as specified after the review: predictions from the sensor driver, non-negotiable thermal and sensor-count ceilings, clamped budget proposals, delegate actions that execute, and paged audit queries.

Both implementations pass a shared conformance suite generated by the Python reference: message encodings, audit chains with expected hashes, and delegate rules with expected hashes. The TypeScript Agent drives the Python Device over UDP and the Python Agent drives the TypeScript Device, both in continuous integration. A C++17 port for Zephyr and ESP-IDF is planned; the plan is in the repository under docs/PORTING_PLAN.md.

The Wire Bench

The bench is the TypeScript port running in your browser. The Device, with eight simulated sensors and its four engines, lives in one Web Worker; the Agent lives in a second; the main thread only simulates the link and draws. Every row in the middle column is a real CoAP datagram that crossed between the two workers.

Things worth trying:

1. Run the Budget squeeze scenario and watch the Device refuse a camera stream under a 10 mW ceiling, then grant a 1 mW heartbeat embedding instead.
2. Run Reflex under outage: install a heart-rate rule, cut the uplink, inject tachycardia, and see the Device act alone. Restore the link and the delegate event arrives.
3. Click any datagram. The inspector shows the CoAP header, the PAWR map with omitted defaults greyed out, the decoded payload (a PPG sample, an IMU vector, a JPEG frame, a rule, an audit entry), and a hex dump coloured by layer.
4. Press Tamper in the audit panel, then Verify, to see exactly where the chain breaks.
5. Drag the link controls: latency, jitter and loss show CoAP retransmission doing its work.

Every PAWR parameter is editable from the page: mode, rate, quality and burst window per sensor; the budget proposal; the Device's own policy and hard limits; the allowed delegate actions; the rule condition and actions.

Status

The three Internet-Drafts cover the core protocol, discovery, and motivation. Their names use the draft-bouazizi-core-pawr prefix. The Python and TypeScript source packages and the live Wire Bench now use PAWR. Existing /wap/ and /projects/wap links redirect to their PAWR locations. The protocol rename leaves the reported measurements unchanged.