Morndo

By morning, it's done

I run many coding agents at once, on more than one machine. In September 2026 that added up to 2,219 agent-hours in 427 hours of wall-clock time, with about five agents running at once on average. At that scale the bottleneck is no longer the agents. It's me: my attention, my decisions, and whether I can trust what comes back.

Morndo is the tool I built for that person. The agents stay what they are (Claude Code, Codex and others, unmodified in tmux). Morndo serves the human who holds merge, deploy and spend.

Four things kept happening

1. An agent asked me the same thing twice. I had already decided. It came back as a fresh question, sometimes on two devices.
2. A question waited for hours. An agent blocked on me at 23:10, and I found out at 08:30.
3. "Done" that wasn't done. The agent said it passed. I trusted it. It hadn't.
4. The box died with everything on it. The machine running every agent ran out of memory, and I lost sight of all of them at once.

Every tool I tried served the agent: more tools, more autonomy, a better harness. None served the one person whose attention is the scarce resource.

Three pillars, and only three

• Authority. An irreversible action (a protected merge, a deploy, a push to shared history, a deletion) needs a mandate you gave once, from a device proven to be yours with a passkey. Silence, timeouts and defaults grant nothing.
• Escalation. A question is one item with one answer, delivered exactly once. It stays open until you answer it. Nothing counts as seen because a transport said "ok".
• Verification. A claim of "done" is judged by checks fixed before the work started and run by someone other than the worker. A missing check shows as "unverified", never as success.

The verification pillar comes straight out of my own research: in my agent transcripts, the most common failure wasn't destruction, it was an unverified "done". See Sleipa.

Architecture

• Hub: the principal's server, with the app's API, passkeys, sends and decisions.
• Web app: a SvelteKit desktop shaped like a team chat (one manager you talk to, one channel per worker) plus a phone view that shows open decisions first.
• Fleet service and node agents: each machine dials in with its own key and exposes its tmux sessions, transcripts and files through typed operations only. If one machine goes down, its agents show as offline, not gone, and the rest keep working.
• A pure domain package with no infrastructure, shared protocol schemas, and SQLite on each machine's local disk (network file systems are refused).
• Negative controls kept as data, so every safety check is shown to fail when it should.

A latency fix worth telling

Agents block on hooks, so hook latency is the user experience. On a machine with a spinning disk, a blocking hook took a median of 911 ms and 28.9 s at the 95th percentile. Making only the commit that guards a side effect durable, and relaxing durability everywhere it didn't matter, brought that down to 1.8 ms median and 4.6 ms at p95.

Three generations

Morndo is my third attempt at the same idea. The first was a team of named agents for planning, coding, review and research; its coding agent made 301 commits in 15 days, around the clock. The second was a fleet on a home PC with a night shift and a Telegram bot for questions. It ended when one VM holding every lane hung for three hours. Each rebuild fixed the failure that ended the previous one.

Status

Honest version, from the README: the desktop, the phone view, passkey decisions, push and the multi-machine fleet run on my own setup every day. Verification is designed and written down but not built yet. It is one person's project, a few weeks old, and not yet installable by anyone else. The first public release was on 10 October 2026.