[← Blog]

Building LastDB with an autonomous agent loop

2026-06-22

We let AI agents build LastDB toward goals we set — and merge their own pull requests — while we sleep. Here’s the system that makes that safe instead of chaotic.

Most “AI coding” demos show a human prompting an agent, watching it work, and steering every turn. That’s autocomplete with extra steps. We wanted something different: set a destination, walk away, and come back to merged, working code. This is how the LastDB development loop actually works.

And there’s a twist we like: the loop is driven by two of our own apps — Brain (a personal knowledge base) and Kanban (a task board) — both open-source apps built on LastDB. We build LastDB using software that runs on LastDB.

Three kinds of pieces

The whole system is built from three kinds of things. Keeping them straight is the trick:

  • Data — inert facts. What we’re building and the rules of engagement. These live in Brain. They don’t do anything on their own; something has to read them.
  • Harness — a recipe. The enforced, written-down process an agent follows.
  • Routine — a recipe plus an alarm clock. A harness that fires itself on a schedule.

So a routine is just a harness with a timer, and data is what they all read.

YOU set destinations · clear the gates SETS THE BRAIN facts & rules — read, never acts alone NORTH STAR ACTIVE PROGRAMS AUTONOMY CONTRACT DRIVING MODEL READ BY THE LOOP scheduled routines, in sequence PROGRAM DRIVER GROOM PICKUP WORKER WATCH PRODUCES MERGED PRS ON DEV SURFACES ONLY THE 5 GATES
Fig. 1 — you set the brain; the loop reads it; only the gates return to you

The unit of work is a North Star

We don’t hand agents tickets. We set North Stars — destinations with a checkable “done.” Each feature is its own North Star, and every North Star carries a mode that tells the agent what kind of work this is:

  • prototype — no working version exists yet; build the rough end-to-end version.
  • harden — a rough version exists; stress it, find the edge cases, stabilize it, and prove it by running the app, not just passing tests.
  • maintain — shipped and stable; keep it healthy in the background.

A North Star moves through those modes over its life. The agent reads the mode and picks its approach.

NORTH STAR a destination with a checkable ‘done’ BY MODE PROTOTYPE build the rough version HARDEN find edges · prove by running MAINTAIN keep it healthy MERGED ON DEV RUNS IN BACKGROUND routines keep it healthy
Fig. 2 — one North Star, three modes; prototype and harden ship, maintain runs on

The contract: drive by default, stop at five gates

The reason most “autonomous” setups stall is that they ask permission constantly. Ours has one rule: drive everything to done on the development track without asking. Build, test, security-review, fix, and merge — all autonomous.

The agents stop for exactly five things, the genuinely human decisions:

  1. Production cutover — flipping a feature on for real users.
  2. Anything public or outward-facing — like, well, publishing this blog post.
  3. Money, legal, or business.
  4. A genuinely novel direction with no precedent.
  5. Anything irreversible.

Everything else is the agent’s call. This single contract is what turns a pile of capable agents into a loop that actually finishes things.

The loop

A handful of small scheduled routines pass work down a line:

  • program-driver turns each North Star into the next concrete card.
  • groom promotes the ready cards.
  • pickup fans out a worker agent per card.
  • the worker builds the change, opens a pull request, and drives it through the merge queue to merged — a card isn’t “done” until its code is actually in the repo.
  • watch reconciles the board: advancing what’s stuck, and — critically — flagging anything it can’t resolve.

That last word matters more than it looks.

A bug worth bragging about

Recently a card sat finished-but-unmoved on the board for five days. The reconciler had a stale assumption baked into its recipe — it skipped a whole class of cards on a belief that was no longer true — and, worse, it skipped them silently. Nobody was told.

The fix wasn’t just correcting the assumption. It was making a rule: a piece of work is either moved forward or it’s surfaced to a human — silence is now a bug. A finished task can no longer quietly stall where no one sees it. We’d rather the system interrupt you with “I’m stuck on this” than let work rot invisibly.

That’s the real difference between a demo and a system you can walk away from: not that it never gets stuck, but that it can’t get stuck quietly.

What this means

The humans set destinations and answer five kinds of questions. Everything else — the building, testing, reviewing, merging, and the honest “I need you on this one” — runs on its own. The same local-first, you-own-your-data philosophy behind LastDB is the philosophy behind how we build it: the tools work for you, in the open, without asking to phone home for permission.

Built with Brain and Kanban — open-source apps on LastDB.

[← Blog]