Martin Sukany

A month ago I thought I had the right answer: split everything into specialists.

At the peak, my setup had sixteen agents. One for email. One for writing. One for research. One for infrastructure. Several more for code, review, critique, QA, and orchestration. On paper it looked elegant — decomposition, clear ownership, domain-specific memory, explicit routing.

In practice it gradually became something else: an overengineered system that demanded more maintenance than it returned.

I try to keep my Home Assistant setup boring in the best possible way. My blinds are not driven by a giant all-knowing automation. Instead, I use a few small pieces that are easy to understand, easy to disable, and easy to restore.

This post describes the pattern I use at home and how I expose it to Keeper, my Home Assistant assistant agent. If you want something you can reproduce, this is the important part: keep the physical covers, the room-level toggles, and the higher-level automations separate.

I’ve been using gptel daily for three months now. This isn’t a review — it’s a field report from someone running LLMs inside Emacs on a corporate macOS machine with a MITM proxy, compliance requirements, and zero patience for black-box tooling.

For the first few weeks, Daneel did everything. One agent, all domains: email triage, code review, research, smart home control, calendar, blog drafts. The configuration was clean, the setup was simple, and the outputs were consistently mediocre.

Not broken. Just mediocre. And I eventually figured out why.

The single-agent problem

When an agent handles email classification at 09:00 and rewrites a Python module at 10:00, the same context window carries both concerns. A session loaded with inbox threads, calendar events, and Home Assistant device states isn’t an ideal substrate for code review advice. The model isn’t broken — it’s trying to maintain quality across too many unrelated domains simultaneously.

Why I still write on paper

There’s something that happens when I pick up a pen that doesn’t happen when I open a new buffer. The thinking is different — less filtered, less structured, more honest. Ideas that would never survive the friction of forming a heading and choosing a tag actually get written down. First drafts of decisions, rough task lists, things I’m trying to work out, all of it lands on paper before it’s ready to be digital.

I stopped asking my personal AI assistant to write code. That decision — more than any prompt engineering trick or model upgrade — improved the quality of what I get back. This post is about why, and what the setup actually looks like in practice.

The problem with asking your personal assistant to write code

My personal assistant, Daneel, knows a lot about me. It tracks my calendar, triages my email, controls my Home Assistant devices, remembers past conversations, and generates a morning briefing before I’ve had coffee. That rich context is exactly what makes it useful for life-admin. It’s also exactly what makes it a poor choice for writing code.

Two weeks ago I published a post about giving Daneel a soul — replacing Asimov’s Laws with a real priority hierarchy and a decision model. Last week I rewrote it again. Not because the first version was wrong, but because running it in production taught me what was missing: harm prevention has to come before “follow instructions,” trust has to be explicit, and an agent that waits to be asked is an agent that will eventually do the wrong thing at the wrong moment. Here’s what changed and why.

The Problem We Had

Our first multi-agent pipeline was a disaster waiting to happen. The architecture seemed clean: spawn workers, each does its thing, updates a shared `status.json` to record completion, and if it’s the last one in its phase, spawns the next batch. Workers know the workflow, workers drive progress. What could go wrong?

Plenty.

The race condition was textbook. Two parallel research workers — `researcher-a` and `researcher-b` — finish around the same time. At `t=0`, both read `status.json`. Both see themselves as the last remaining worker. At `t=1`, both write back with themselves marked completed. One write wins. The other is silently lost. The “winning” worker sees only its own completion, decides the phase isn’t done, and does nothing. The pipeline stalls. No error. No timeout for another ten minutes. Just silence.

On day 2, the agent tried to re-enable a Twitter integration I had explicitly cancelled the night before. It had forgotten. Not because of a bug — because session restarts wipe context, and nothing in the default setup prevents an AI from re-deriving a decision you already vetoed.

That’s when I started building the infrastructure that turned a chatbot into something that actually works.

This is not a tutorial. It’s what running an autonomous AI agent looks like after 10 days: what it costs, what breaks, and what I’d change.

I run macOS Accessibility Zoom at 16× magnification. Not occasionally — all the time, every day. Apple’s built-in screen magnifier has a mode called “Follow keyboard focus” that’s supposed to track your text cursor as you type, keeping it visible on screen. Every app I use does this correctly. Terminal, VS Code, Safari, iTerm2 — they all work. Emacs did not.

For years.

I type something. The cursor moves. The Zoom viewport doesn’t follow. I have to scroll manually to find it again. Then type another character. Repeat. If you’re reading this without needing magnification, the description might sound like a minor inconvenience. It isn’t. It’s the kind of friction that makes a tool feel broken — and I use Emacs all day.