Soe Zayar.
Menu
Book a call
CASE FILE E

Loom: coding agents on a Mac, routed and supervised

A local macOS app that coordinates coding agents in separate Git worktrees, picks a model for each role, and can be controlled from a phone.

Engagement
Own product
Role
Designed and built
Status
Internal

In plain words

Before

Coding agents from different vendors each come with their own command-line tool, limits and failure modes. Running them by hand means watching terminals, copying context between tools, restarting when a free model hits its limit, and hoping nothing was changed in the main copy of the code by accident. Step away from the desk and you lose track of what is running.

What I built

Loom is a local macOS app that coordinates coding agents on a Git project. A Plan task asks a read-only agent to study the code and saves its answer. A Build task turns that plan into work: a team of roles (coordinator, analyzer, planner, developer, tester and reviewer) runs in a separate copy of the repository, records every check it ran, and only delivers once review passes.

Loom chooses a model for each role, explains why, and switches when a model stalls or hits a limit. When a build stops, it shows where and why, and for common problems such as a missing tool, a busy port or a full disk it suggests the fix. Tasks can run on a schedule, and a paired phone can check results and pause, resume or cancel builds from anywhere.

Under the hood

Architecture

  1. Task
  2. Coordinator
  3. Role agents
  4. Checks + review
  5. Worktree

Stack

  • Tauri and Rust
  • TypeScript front end
  • SQLite in WAL mode
  • Git worktrees
  • OpenRouter, Codex CLI, Claude Code, OpenCode
  • Cloudflare Tunnel and an installable phone client
  • macOS Keychain

Decisions

  • Builds run in a separate Git worktree by default, so the original checkout is never changed unless a project explicitly opts into checkout mode or commit-and-push.
  • A Coordinator routes the analyzer, developer and tester roles to verified free models, saves the reason for each choice, switches when a model stalls or hits a limit, and stops offering models that keep failing for a role.
  • Plan mode runs agents under a read-only tool policy with no shell, editing or delegation, and fingerprints tracked and untracked files to detect any change.
  • Each CLI process group is supervised through a pipe the app owns, so an exit or crash stops it without signalling stale process IDs on restart.
  • Source changes invalidate earlier checks and review before delivery, and paid fallback models need an explicit, finite budget.

Related services

Need something like this built?