ORCH

An agent runtime shipped as a command-line tool. You deploy a team — a CTO, backend agents, a QA agent, a reviewer, each bound to whichever CLI you want it to run — give the team a goal, and an orchestrator loop reconciles processes, dispatches idle agents and collects finished runs on a tick. It drives Claude, Codex, Cursor, Grok, Antigravity, Pi, OpenCode or any shell command through one adapter interface, exposes a full-screen terminal dashboard and a headless mode for CI, and keeps every task, agent, run and message as files under a single hidden directory. The engine is also published as a library, so the same runtime can be embedded in another Node application.

Who built itA single account opened in September 2024, with 50 public repositories, 11 followers, and a bio that says “AI agents creator”. He wrote 581 of the repository’s 585 commits, under an iCloud address, with the remainder from two other contributors and one commit attributed to Claude.

1. 01

   One goal, five agents, and 85% of the commits that say who wrote them

   The repository was created on 2026-03-10 and reached 585 commits by 2026-08-01, of which 497 landed in March alone — then the pace fell to 32, 20, 4, 27 and 5 in the months that followed. One author wrote all but four of them. The build signature is unusually clean: 498 commits carry a co-author trailer, 85% of the total, and they name Claude models almost exclusively — Opus 4.6 on 283, Opus 4.6 with a million-token context on 155, Sonnet 4.6 on 45, Opus 4.7 on 14. In five months the project cut 34 releases across 45 tags, from v0.1.0 on 2026-03-12 to v1.0.34 on 2026-08-01. It has 167 stars, 17 forks and 7 open issues, and its README advertises 1,954 passing tests on the badge — the author’s own count, and the kind that a repository can keep honest or not. Nothing has been pushed since 1 August, and five pull requests are still open.

2. 02

   A terminal interface with a written specification, in Russian

   docs/CLI_UI_DESIGN.md is 35 KB of interface design for a command-line tool, and it is written in Russian. Its opening line sets the aesthetic — instrument-grade terminal, in which every character counts and nothing is drawn for beauty’s sake, because the information should read like a pilot’s panel: glance, understand, act. It then defines three modes as three levels of immersion — a one-shot command that prints and exits, a full-screen dashboard, and a watch daemon with a live log and a compact status line — and treats each as its own design problem. What follows is the part most terminal tools never write down: the status block is specified to fit 80 columns so it works in any terminal, colour is ANSI 256 with a fallback to 16, task rows carry a fixed glyph vocabulary (● running, ○ waiting, ◈ review, ✓ done, ✕ failed, ↻ retrying), priorities have fixed colours from P1 red to P4 dim, rows sort in one defined order, the footer is always a single summary line, and every command has a --json flag so a script does not have to parse the picture.

3. 03

   No database: all the state is files, and every path that could grow has a ceiling

   The storage decision is stated in one line — everything lives under .orchestry/, there is no database — and the consequences are spelled out. Tasks, agents, goals and teams are individual YAML files; a run is a JSON record plus an append-only JSONL event stream; global state is a single JSON file. Two utilities carry the weight: atomicWrite() writes to a temporary file and renames it, so a crash mid-write cannot leave a half-written record, and readJsonlTail() reads the last N lines of an event stream without loading the whole file, which is the difference between a dashboard and an out-of-memory kill after a long run. The same reflex appears in the interface and the daemon: the terminal dashboard batches incoming messages on an 80-millisecond flush, caps any single detail string at 2 KB, and holds run identifiers in a map with an LRU ceiling of 500; the headless mode logs only every sixth idle tick so a quiet night does not fill a disk. This is what a program looks like when its author expects it to run unattended for hours beside processes that emit events faster than a person can read them.

4. 04

   Layers that load only what the command needs

   The architecture is layered domain, application, infrastructure and interface, with dependency injection written by hand — no framework and no decorators. The interesting part is the container, which comes in two tiers: a light one holding only stores and services, used by every read-only command such as listing tasks, reading logs or showing status, and a full one that adds the orchestrator, the process manager, the template engine and the adapters, used by the three commands that actually run work. The command-line entry point decides which tier to build and then lazily imports only the module for that subcommand. For a tool whose job is to start other processes, startup latency is the first thing a user feels, and this is a design that treats it as a feature rather than an accident. Underneath, an adapter interface turns each external agent CLI into the same shape — a spawned process, a process id, and an async stream of events — with registered adapters for Claude, Codex, Cursor, Grok, Antigravity, Pi, OpenCode and a plain shell. Around the tasks sits a small state machine that validates every transition with one function, with a promise-chain mutex serialising state changes and a tick loop that reconciles process liveness, dispatches to idle agents and collects results.

5. 05

   Skills as plain Markdown, injected at dispatch

   Twenty-six skills ship in the repository as ordinary Markdown files, and the loader treats them as two different species. Ones named with letters and hyphens are read at dispatch time and their content is injected into the agent’s prompt; ones named with a colon are passed through untouched, because they belong to the external CLI’s own extension system. The loader caches them for the life of the process, reads them in parallel, and validates every name against a pattern — a file name that could climb out of the skills directory is rejected before it is opened. Each agent names the skills it wants in its own definition, so what an agent knows how to do is data in a file rather than behaviour in the orchestrator. The same instinct produced the memory specification: a 22 KB Russian technical document, marked Research — exploratory design, not committed to the roadmap, which states the problem before proposing anything — each invocation of the underlying CLI is a fresh subprocess with no history, and the only memory an agent has today is what the orchestrator assembles by hand into the prompt, a key-value store with no structure or search, one retry’s worth of previous failure, and a final summary capped at 2 KB.

6. 06

   A release script that keeps three files in step, and a checklist that names the ones it does not

   The version number lives in three places, and the release script owns all of them: it bumps package.json, rewrites the version string in the command-line entry point, and updates the copy on the landing page, which is a hand-written static site in the repository rather than a generated one. The publishing workflow runs the type checker and the tests again on the tag, checks whether that version is already on npm and skips the publish if it is, and pulls the matching section out of the changelog to use as the release body. The documentation is honest about the gap: a section headed “manual updates not covered by the release script” lists the changelog, the test-count badge in the readme, and the statistics and feature copy on the landing page. For a repository that has shipped thirty-four versions, that list is the difference between a release process and a hope. The pull-request history is the quieter half of the same story: eleven requests in total, five merged — including a Pi RPC adapter from one contributor and a light theme palette from another — five still open, and three from a single contributor sitting since April.