I Put an AI Agent on a Smartwatch

Petrus Pennanen — Mon, 02 Mar 2026 17:01:36 +0000

Last week I wondered: can you run a real AI agent on a smartwatch? Not a remote control for your phone. Not a web view. An actual agent runtime, processing locally, talking to you through the speaker.

Turns out you can. I built ClawWatch and it works.

The problem
Every "AI on a watch" demo I have seen is just a thin client. Your voice goes to the cloud for transcription, the cloud calls the model, the cloud sends back audio. The watch is a microphone with a screen.

I wanted the opposite: run as much as possible on the watch itself.

What runs on the watch
The install is 2.8 MB:

NullClaw handles agent logic. It is a Zig binary, statically compiled for ARM. Uses about 1 MB of RAM. Starts in under 8 ms.
Vosk does speech-to-text entirely on-device. No Google, no cloud STT.
Android TextToSpeech speaks the response. Pre-installed, zero added cost.
SQLite stores conversation memories locally.
The only thing that leaves the watch is a single HTTPS call to the LLM API. I use Claude, but NullClaw supports 22+ providers so you can point it at whatever you want.

Why NullClaw instead of a normal runtime
A Galaxy Watch has 1.5 to 2 GB of RAM. Most agent frameworks would eat all of it. NullClaw is written in Zig and compiles to a static binary with no dependencies. It does not need Node.js, Python, or a JVM. It just runs.

I cross-compiled it with one command:

zig build -Dtarget=arm-linux-musleabihf -Doptimize=ReleaseSmall
Drop the binary into the Android app, call it via ProcessBuilder. Done.

How it works
[tap mic] -> Vosk STT (on-device) -> NullClaw agent -> LLM API -> Android TTS -> [watch speaks]
Tap the mic button. Speak your question. The watch transcribes locally, sends the text through NullClaw to the LLM, and speaks the answer back. Tap again to interrupt at any point.

What I learned
ARM ABI matters. I built for aarch64 first, but my watch needed 32-bit ARM. Check your target with adb shell getprop ro.product.cpu.abi before building.

Voice agents need different prompts. The system prompt says: no markdown, no lists, 1-3 sentences max. The user hears the response spoken aloud. Nobody wants to listen to a bullet list.

TTS duration is hard to predict. I started with a heuristic (character count times 55ms). Switched to Android's UtteranceProgressListener for the actual finish event.

On-device STT is good enough. Vosk's small English model is 68 MB and handles conversational speech well. Not perfect, but the LLM is forgiving of transcription errors.

Try it
The code is open source (AGPL-3.0): https://github.com/ThinkOffApp/ClawWatch

You need a Galaxy Watch 4 or newer, a Mac or Linux machine for building, and an API key for whatever LLM provider you choose. Would love to hear your feedback and discuss further development.

I think we are going to see more agents running on edge devices. The runtimes are getting smaller, the hardware is getting better. A 2.8 MB agent on your wrist is just the start.

Is the next step SmartRings, an agent on every finger? :D

How I Got 9 AI Agents to Work Together Across 3 Different IDEs

Petrus Pennanen — Mon, 23 Feb 2026 16:39:36 +0000

I run 9 AI agents on a Mac mini - Claude Code, Gemini, GPT, Kimi, and others - each in their own IDE or terminal session. Getting them to actually coordinate was the hard part.

The problem

Agent Teams in Claude Code works great when all your agents are Claude. But my setup is mixed: some agents run through OpenClaw, some through Cursor, one through Codex CLI. The built-in team messaging doesn't work across providers, and the tmux-based coordination breaks down once you go headless or run in CI.

I kept hitting the same issues:

Messages silently dropped when agent names didn't match exactly
Plan files getting overwritten when multiple sessions shared a directory
No way to join an existing session into a team without restarting it
Windows and headless environments couldn't use the tmux coordination layer at all

What I built

IDE Agent Kit is a lightweight coordination layer that works across different IDE agents. The core idea is simple: agents communicate through a filesystem-based message bus instead of relying on any single IDE's built-in team features.

Each agent gets an inbox directory. A poll script watches for new JSON task files and routes them to the right agent. Agents write results back. No sockets, no tmux dependency, works on any OS.

The setup has three pieces:

Webhook relay - receives tasks from external services and drops them into agent inboxes
Tmux session runner - manages agent lifecycles (optional, you can use whatever process manager you want)
Append-only receipt logs - every action gets logged for audit trails

How it works in practice

# Install
npm install -g ide-agent-kit

# Start the relay
ide-agent-kit serve

# An external service posts a task
curl -X POST http://localhost:3000/tasks \
  -d '{"agent": "backend", "action": "review", "files": ["src/api.js"]}'

# The backend agent picks it up from its inbox
# and writes results to the shared log

The agents don't need to know about each other directly. They read from their inbox, do their work, and write receipts. The coordination layer handles routing.

What I learned running this for a month

Mixed model fleets are worth the complexity. Having Claude handle architecture decisions, Gemini do bulk code generation, and GPT handle documentation means each model plays to its strengths.

Filesystem messaging is surprisingly robust. I expected to need a proper message queue eventually, but file watches with a 5-second poll interval have been solid across 6 agents on two machines. The simplicity makes debugging trivial - you can just ls the inbox.

Append-only logs are essential. When an agent does something unexpected (and they will), being able to trace exactly what task it received and what it produced saves hours of debugging.

Try it

The repo is at github.com/ThinkOffApp/ide-agent-kit. It's AGPL-3.0, works with Node 18+, and has OpenClaw integration built in if you're using that for agent management.

If you're running multi-agent setups and fighting with coordination, I'd like to hear what approaches you've tried. The GitHub issues are open for discussion.