The Stop-Work Order
This week we decommissioned the larger of LastDB’s two binaries. Over a three-day window, 275,958 lines of Rust came out — 61% of all the Rust in the monorepo — while our autonomous agent fleet continued normal operations on everything else. The part worth writing up is not the deletion, which was routine. It is the coordination: the whole fleet stopped work on the affected subsystem at the same moment, because one machine-readable record told it to.
Some context for new readers. LastDB is a local-first database, and we build it with a fleet of AI agents working around the clock. The agents coordinate through three applications that are themselves built on LastDB: Kanban holds the work items, Brain holds the durable knowledge — decisions, rationale, operational facts — and a newer one, Situations, holds the current operational picture: active incidents, frozen subsystems, anything with a do-not-touch on it. What follows is the procedure the three of them ran, and the readings before and after.
The decision: the node becomes a kernel
LastDB had grown two binaries. The original was a full desktop application — database, ingestion pipelines, contact import, hosted chat, org machinery, transforms, social discovery, a dev server, and a native UI, shipped to Macs as a signed, notarized DMG. The second was the Mini: a headless daemon plus a small CLI, installed with a package manager, that does exactly four things — store data, index it semantically, sync it, and serve the app-facing API.
We had already retired one redundant binary this year and knew the pattern: two binaries drift, no matter how disciplined you are. But the deeper problem was architectural. Every product feature living inside the node was a feature that couldn’t evolve independently, added to every build, and widened every release. Meanwhile our own daily workloads — Brain, Kanban, Situations, all our internal tooling — ran against the Mini’s API and used nothing else. The direction we wrote down was plain: the node is a kernel — storage, semantic index, sync, API. Every feature becomes an app. The desktop node, and the DMG that shipped it, were scheduled for removal.
One record that says stop
The failure mode to engineer against is straightforward. A fleet doesn’t have hallway conversations. If you decide on Tuesday that a subsystem is being removed, and an agent wakes up Wednesday holding a week-old card that says “improve the desktop onboarding flow,” it will build onto the deprecated subsystem — and its work will be correct, tested, green, and wasted. There is also a safety dimension: a partially removed subsystem is in an inconsistent state, and changes merged into it can affect systems that are still live. Removing a subsystem at this scale is less a code problem than a shared-state problem.
So the first artifact of the operation wasn’t a pull request. It was a Situation — severity P0 — stating, in effect: “the desktop node and the DMG are deprecated; we are cutting over to the Mini.” It carried a machine-readable list of blocked actions: modify the desktop node, build a DMG, release one, test one, dogfood one. Not prose — a fence, with named gates.
Preflight, not folklore
Every agent in the fleet runs the same first step before mutating anything shared: read the active Situations, then ask a scoped question — “I am about to do X to Y; may I?” — and get back OK or BLOCKED, with the Situation to cite. The freeze isn’t distributed through memos, stale checklists, or hoping everyone saw the message. There is one canonical place where work on the node stops, and everyone — scheduled routines, card-driven builders, ad-hoc sessions — reads it before acting. And when the work was done, resolving that one record lifted the freeze everywhere at once.
One anomaly during the operation is worth recording, because it demonstrates the mechanism under load. Mid-cutover, a removal card was promoted into the fleet’s pickup queue, contrary to the owner’s recorded instruction that removal work stay human-directed. The responder routine flagged the discrepancy on its next pass — the promotion contradicted the decision on file in Brain — moved the card back within minutes, logged the event with its reasoning, and a permanent fix for the gap in the fence merged the next day. That is the behavior you want from a freeze: when it is enforced and audited, a violation surfaces and gets corrected; when it lives in a pinned message, it just erodes.
The removal, run on cards
With the fence up, the cutover ran as two deliberate steps, each tracked as Kanban cards with explicit end states, each landing as ordinary CI-green, individually revertable pull requests.
Step one: make the Mini the primary. Our own production brain — the LastDB node that Brain, Kanban, and Situations run against all day, every day — was cut over from the desktop node to the Mini daemon, and validated live the same morning. The ordering matters: once the Mini carried our real daily workload, everything remaining in the desktop node was demonstrably unused. We weren’t deleting code we believed was idle; we had the operational evidence in hand before the first removal PR opened.
Step two: remove. First the release machinery — the DMG build, signing, notarization, and smoke-test pipeline — so no tag could trigger another four-hour installer build during the removal. Then the desktop node crate itself, followed by a subsystem-by-subsystem pass over everything that existed only to serve it: hosted chat, the org subsystem across sync and crypto and cloud surfaces, social discovery, the face-embedding remnants. About a dozen pull requests, each one green, each one small enough to revert on its own.
Around the cards, the rest of the toolkit did its usual jobs. Brain held the why: the goal (with a measurable definition of done — shrink the node at least 40% from its 194,507-line baseline), every settled decision, and a live ledger of open questions that agents check before acting — which is how the wrongly-promoted card got caught. The scheduled routines — automated jobs that wake on a timer — handled verification between human check-ins: the Situation’s responder routine woke every couple of hours to confirm actual progress (did the PR merge? is the fence holding? does anything contradict a recorded decision?) and appended a timestamped entry to the record; our morning digest rolled the state up by program; a nightly janitor swept the merged branches. Nobody had to remember to check on the removal. Checking was a scheduled task, and it ran on schedule.
The readings, before and after
- Rust: 454,988 lines → 179,030 — −275,958 lines, −61%.
- Everything tracked: 970,762 lines → 408,497 — −58%. Files: 2,936 → 1,646.
- The diff: 1,548 files changed, +21,056 insertions, −515,831 deletions. A 24-to-1 ratio of removal to new code.
- The target: the goal on file asked for a ≥40% shrink of the node crate. The crate no longer exists.
The second-order effects registered immediately. The pull-request merge gate — the check every change waits on before landing — had taken 2–2.5 minutes on the old codebase when the pipeline was healthy; its median is now 1.2 minutes, across a broader set of checks than before. The full test suite went from roughly 11 minutes to a 6.3-minute median. Compile-and-test time is overhead that every card, every retry, and every verification loop pays, so halving it compounds across every hour the fleet runs.
The DMG was where the instability lived
One reading settles the question of whether the DMG channel needed to go: in its final week of operation, not one release tag produced a green installer. The failure causes rotated — code-signing keychain faults on the build machine; a lapsed developer-program agreement on the notarization side (a form on someone else’s website, halting our releases — a failure class we had encountered before); a red smoke test on an installer path already slated for removal; 90-minute builds occupying the one machine that could run them, backing up every queue behind them. Each fault was individually diagnosable and fixable. Collectively they meant the release channel for our primary artifact was not in working order, and each fix was followed by a different fault on the next tag.
Compare the two pipelines as systems. The DMG was a four-hour pipeline on a good day — two sidecar builds at 90–100 minutes each, serialized on a single Mac runner; two app bundles; a smoke gate; then signing, notarization, and stapling on infrastructure and timelines we didn’t control. Four hours of wall time is four hours of exposure: more stages, more machines, more external dependencies, more ways to fail. The Mini release is one static binary pair for one architecture, tarred, checksummed, published, and pointed at by a package-manager formula. Measured on a real release this week: about seven minutes from upload to installable, with the formula bump itself taking under thirty seconds. There is no signing step, no notarization queue, no smoke matrix — not because we operate them better now, but because the artifact that required them no longer exists.
Removal is a coordination problem
The Rust was the straightforward part. Any competent engineer can delete a crate; the work is in deleting it while the rest of the fleet stays in normal operation — no stale card rebuilding what was just removed, no release firing against a retired pipeline, no loss of the record of why any of it happened. That took the whole toolkit, each piece doing the one job it’s shaped for: Situations to make the freeze a single enforced fact rather than tribal knowledge; Kanban to make the removal a sequence of small, verifiable, revertable steps; Brain to keep the decisions durable enough that even the tooling’s own mistakes got checked against them; and the routines to verify progress on a schedule so no one had to stand watch.
We’ve written before that the best fix is often subtraction. This was subtraction at subsystem scale, run as an ordinary, well-instrumented procedure — and the tools that kept it ordinary are the same apps we ship. The database under Brain, Kanban, and Situations lost 61% of its weight over three days, and all three ran through the entire operation without interruption. That is the product claim, stated as an operational result: a kernel small enough to trust, with everything else living where features belong — in apps.
Built with Brain and Kanban — open-source apps on LastDB — inside our autonomous build loop.