Inari: your agents in your pocket

Level AdvancedEstimated time a weekendRead first OpenFox: the coding agent that takes local models seriously, Homelab 10: notifications from your servers and agents, on your phone, Your own Android app, outside the Play Store, with its own updatesA word you don't know? Glossary

Once agents work on their own, the question is no longer "how do I start them" but "how do I know what they are doing, and how do I say yes or no from the sofa". Inari is our answer: a native Android app that is the console of the whole stack. It is open source; what follows is how it is built, so you can build yours.

What you get. Your whole lab in your pocket: sessions followed live, an orchestrator that reads everything, and every decision a single tap. Simple to build: a small API and a native app.

Two screens, one back end. The phone app and the desktop client never talk to an agent directly: they go through a small API that reads the fleet, and a rooms controller that keeps every conversation. Reads run alone; any action waits for your tap on a confirmation card.

1. A small API, not a direct line

The phone never talks to an agent or a database directly. A small HTTP API runs on the host that already holds the fleet's event table. It:

listens on one address only, the one on your private network;
refuses every route but /v1/health without its bearer token;
reads its sources with read-only credentials: events, issues on the Forge, which model is on which card;
has one write: putting the go label on an issue, which starts an agent on it.

Each source fails on its own: if the Forge does not answer, the summary carries an error in that field, never a blank page.

The rule "no code ever adds go" stays true: that route carries a human's tap, authenticated, from the phone. The decision to spend a model's evening on a task is yours.

2. The tabs that earned their place

Sessions: the coding sessions of OpenFox, followed live, with your approval asked when the agent wants to run something sensitive.
Swarm: a chat with a local orchestrator that reads the fleet by itself and proposes actions on cards.
Runs and Control: the agents' logs as they write, the queue, which model is on which card.
Issues: the tasks waiting for you, with the Go button.
Rooms: long conversations that survive a closed app (see rooms and FoxDesk).

3. The orchestrator designates, the code acts

The local orchestrator is a 9B to 27B model with a closed list of tools. Reading tools run alone. Action tools (start a session, switch a model, relaunch a workflow) never run: they return a card, and only your tap executes it. The card says exactly what it will do, including what it will unload.

Measured on a 9B: it announced an action without calling the tool once in three tries, and read counters upside down. The fixes were in the tools, not the prompt: each tool returns its own reading instructions, and date filtering is done by the code. Before trusting a new capability, a bench of ten cases run three times, with every action refused.

4. Without Google

Native Kotlin and Jetpack Compose, no network library: the platform's HTTP client and JSON parser.
The token encrypted by the Android Keystore, the app locked by your fingerprint, HTTPS only.
Notifications by ntfy, not Firebase. A notification carries a link that opens the exact session waiting for you.
Published by the server itself, outside any store.

Traps

Do not decide the scope of a version 1 alone. Our first version was a dashboard; what was wanted was "a coding agent in the pocket, local only". Show a sketch before building.

A double tap must not start two tasks. Generate a request identifier on the phone and let the server return the same receipt for the same identifier.

Found this useful? Tell us what to measure next.