Two failures taught me the price.

The first was a loop detector. I built six patterns to stop a small-model agent from running away, each with a real incident behind it. In production it bounced a perfectly good research turn between three of those patterns, stripped its tool calls, and dropped the user into a canned "I couldn't settle on one, how would you like to proceed?" The guardrail meant to prevent a runaway had created a worse failure than the runaway. The fix was to delete four of the six patterns, and a thousand lines with them, and let the agent run to a coarse recursion limit instead.

The second was an org format editing bug. Who would have thought that org wasn't a large part of Qwen's training set? The model kept anchoring an edit on the wrong line and splitting a file. My instinct was a deterministic guard that rejects bad edits. I spent days trying to "lightly" detect and surface a bad edit, and landed on doing the agent's job for it before realizing that fights the whole point of the project. What actually worked was a checkable rule on the tool's arguments, written into the instruction, not a wrapper bolted around it.

Both times my reflex was structure, and both times it was worse than what it replaced.

The alternative is a skill. On the phone, "call Ana" has to turn a name into a number, maybe disambiguate, confirm, and dial. The first design added a tool to look up contacts and a server event to drive the confirmation. Hand-holding the whole way. The dial is a dumb, deterministic command: a number in, a call out, no thinking. Everything fuzzy lives in a skill, a plain-English recipe the agent follows: search my notes for a name near a number, pick, confirm, call. No new tool. It runs on the small local model and it actually works.

A skill is the opposite of a commitment. It is text. I can read it, change it, and watch the behavior change, the same way I change anything else on the phone. A tool is a fixed shape with code behind it and a contract that drifts from the recipe that uses it. Given the choice, put the judgment in the text and let the model do the thing it is actually good at.

Leaning in has a backstop, the thin layer of hard structure you cannot skill your way out of. A weak model under pressure falls back to its strongest prior, and prose does not reliably outweigh it. I told an agent eight ways never to answer from its own memory. When search failed it answered anyway and invented a version number. It had not missed the rule, it had no other move. A "stop" handed back in a tool result reads the same way, as one more piece of data, not a command.

So the backstop needs structure, and the craft is keeping it narrow. Guard only the case that is never legitimate work: the same tool, the same arguments, over and over, ended by a counter. "Many distinct searches" is not safe to guard, that is also what thorough work looks like. For anything fuzzier reach for a coarse bound, a timeout or a recursion limit, not a clever per-behavior heuristic.

1. Skill
2. Checkable instruction
3. The narrowest structure that makes the bad state unreachable

Middleware is what you add once you have proven a recipe cannot do the job, not what you start with.

It is also why the functionality on this phone is skills and not apps. An app is someone else's code, a fixed shape I cannot open. A skill is a paragraph of plain English describing how I want my device to work. If the model is good enough to follow the paragraph, and most of the time it is, then the paragraph is the better place to keep the behavior.

I can now call out from it, and it can take a call coming in. When a call arrives the screen shows who is calling and the keyboard turns into two buttons, Accept and Decline. Answer, and those become Hang up. It is a cellular call, over a real modem, on my own number.

However, the path that carries my voice out needs one more piece of hardware I have not wired in. So today it is a phone you listen on. That is a strange half of a phone to have first. It is also the half that proves the hard parts work.

The keyboard grew up too. In May it had no numbers or symbols, which meant I could not type a wifi password or a URL on the device. It has them now. It's a small thing, but it was the line between a toy and something I can set up without reaching for a laptop.

The reason this took a month and not an afternoon was not software. It was power.

The modem kept dropping calls. Every time, the system logged the modem falling off USB and coming back, mid-call. That looks exactly like a driver bug, and I treated it like one for too long. It was a brownout. When the modem keys up its radio to transmit it pulls a hard spike of current, and the five volts was reaching it through the Pi, which cannot supply that spike. The rail sagged and the modem reset. The fix was to feed the modem power straight from a stiff source, in parallel, never through the Pi. With its own supply a call now holds.

There was a dumber lesson in the same week. The call audio went silent and I spent an hour sure it was a software bug, checking the sound config every way I knew. The headphones were dead. A different pair worked on the first try. Nothing in software can tell you a speaker is broken. A dead wire and a bug that eats the audio look identical from where I was sitting.

The nicest part to build was the call screen itself. The bottom of the phone is a fixed keyboard, and the obvious move was to put Accept and Decline up in the call window. Instead I made the keyboard reactive. It is not "the keyboard," it is the control surface, and what it shows should follow what is on screen. A call replaces the keys with call controls. A normal screen shows the keys. The agent and I built that on a branch, reviewed it, and merged it like any other change.

And it's all wired up through a phone call skill, and this is shaping the way I'm thinking about this phone. The smartphone era brought us apps: some functionality, UX, some data, and connection to a service. But this was all contained, owned, and driven by a faceless company with a team of engineers. And thousands of lines of code.

Now with AI agents, functionality can be contained within a skill: plain english, describing how you, the user want to use your device. Here's a snippet of how calls are handled on my phone:

# Place a call

Your job is the *interpretive* part — turn what the user said into one concrete
phone number — then hand it to the deterministic `emacos-call` command. You
work through `eval_elisp`: **evaluate elisp to SEARCH for the number, then
invoke the `emacos-call` command to DIAL.** Stay on the call task.

And yes, it works! I type "Call Ana" and it searches through my files, finds her number, and calls.

It is held together with a wall charger and alligator clips. The proper power board and a smaller antenna are in the mail. I cannot put my voice on a call until a headset adapter arrives. Speech to text is still planned and not built, so the keyboard is the only way in, and it is still slow to type on.

So I'm still very far from where I want to be.

Get my voice onto the call, which is the headset adapter plus the software to run both directions of audio at once. Move the power off the bench rig and onto the real board. Then back to input, where speech would change how this feels more than anything else I could do.

But there's progress: In May it was a malleable Emacs handheld that could not make a call. In June it makes calls and I can hear them. That is still less than a phone, but I'll still call it a phone, my phone.

For the why, read the manifesto.

assist is a local-first agent. It runs against a small open-weight model (currently Qwen3.6-27B) on a box at home, so nothing I say to it leaves the house. It has the parts you would expect, tools and memory and skills and sub-agents for research and exploration, but tuned for a small model, where reliability is the hard part. Each conversation works inside its own git branch of a repo I choose, so the agent's edits stay isolated until I merge them. It has a web UI, a CLI, and an Emacs integration, all sharing one agent core.

emacsos is the phone. It is Emacs on a small touchscreen (sounds fun, right?), a 320x240 frame with a nine-key keyboard, on a Raspberry Pi. I chose this as the starting point because the phone is the most personal device I own, so it should be the most malleable. Everything on it is elisp and changeable at runtime. The catch is that editing elisp on a 320x240 screen with a nine-key keyboard is miserable. So I don't. The agent does!

The two are wired together. The phone has a chat page. I type a request, it streams to a small server sitting next to assist, and the agent answers token by token in the buffer. I can abort mid-answer.

The part I care about most works: I can change the phone by talking to it. "Set the cursor blue." The agent reads the current config, writes the new elisp, and applies it. Every change is a git commit, with the agent's own summary as the commit message. So the history of how my phone became what it is, is just git log. When a change is wrong, one tap reverts it. That rollback is not a feature I built. It is git revert, which I already understood.

All of this runs at home, on my hardware, against my model. The phone depends on no remote service to keep working. The config, the history, and the decisions stay on machines I own.

Let's be honest: this is all very painful, input being the weakest link. The keyboard has no number or symbol keys yet, which means I cannot type a wifi password or a URL on the device. Speech-to-text is planned but not built. The phone and the agent assume they are on the same network. Taking the phone out into the world, over a tunnel home, is designed but not done. And it is not a phone in the way you mean. No cellular modem, no audio, no calls, no texts. Those need hardware I have not connected yet.

So today it is a malleable Emacs handheld that I talk to my own agent through, and that the agent reshapes for me on command. That is less than a phone, and in the one way that matters to me, more.

The next step just unblocked. Until this week the agent could not reliably read the current config after a reset, which made targeted edits fragile. That is fixed now. So the next experiment is conversational, targeted revert: "undo the cursor change but keep the font change," driven from chat, mapped to the right commit, reverted without disturbing the rest. After that the road runs through input, numbers first and then speech, and then the actual phone build: a modem, audio, and the slow work of making this thing ring.

None of it is finished. That is why I want to write it down every month. For the why, read my manifesto.