The bottleneck moved.

Harbour is a provider-agnostic control plane for AI-augmented software development. It reads an issue backend, generates a grounded prompt for a specific task, dispatches that prompt to an AI agent, and verifies the result against real evidence. It began as a read-only Linear project tree and grew into the cockpit for that loop.

The system is two repositories. Harbour is the web control plane — provider adapters for Linear, GitHub Issues, GitHub Projects and a local store; a dual-path prompt engine; a dispatch queue; and a source-neutral workspace API that external agents authenticate against with single-use bootstrap tokens. simple-dispatcher is the runtime that executes the work. Its design is the unusual part: there is no in-process agent. A session is a detached terminal process driven entirely from the outside at hook boundaries, coordinating through a single JSON file as its IPC bus — which is what lets the same substrate run on a developer's Mac or a headless Linux box under tmux.

One sentence governs the whole thing: verified beats claimed. Work counts only when its evidence chain closes — CI green, merged, ledger discharged. The architecture is largely downstream of that: a review step that may only issue a conditional approval, a mandatory ledger of what CI did not prove, and a separate close-out step that owns the irreversible finish. "Done" is a claim; the artifact is the fact.

Delivery is down by about a third from its late-June peak, and the decline is steady rather than a single bad week. Two independent measures agree: tickets reaching code fell -39%, and mainline delivery units — one per merged pull request, immune to how commits are squashed — fell -37%.

What shipped is coherent. The runtime became more portable, more bounded and more observable: a tmux driver took the substrate off macOS onto headless Linux, autonomous runs gained an enforced task budget at the dispatch seam, per-task cost capture landed, and a Live Console timeline made in-flight execution legible. Alongside those, a broad run of incident fixes covered launch, wake, restart, transcript and completion recovery.

What did not change is as important. Work per ticket stayed flat — 1.18 to 1.22 mainline units per ticket, +4%. Tickets did not get bigger or harder. Fewer of them simply arrived at code.

One measurement gap is worth stating plainly. Of 1,112 tasks marked complete, 743 can be traced to a commit citing their identifier — leaving 369 that cannot. Some of that is legitimate: research notes, documentation, decisions, and work predating the current history. But the residue is unverifiable by the project's own standard, and the gap is not measured anywhere.

The effort did not disappear. It changed what it was spent on, and the change is visible in what the code actually is.

The same shift shows up in what the agents spend their sessions doing. Across 68 tickets and 500 worker sessions sampled from the live API, fewer than one session in four writes code:

Four causes are visible in the record, and they are not equally weighted.

The sharpest detail. The plan-review gate shipped with a recorded baseline and an explicit guard — "the step must not tax the throughput it exists to protect" — plus a follow-up ticket, LIN-1661, to re-read the number one cycle later. LIN-1661 is still Todo. The gate's own falsification test has never been run, and the window it would have covered is exactly the window delivery fell in.

Harbour began in January 2026 as a read-only viewer for Linear projects, little more than a tree and a footer. Within weeks it started generating prompts, and the story becomes one of an app teaching itself to act: grounded prompts gave the work shape, a safe API gave it hands, and the autonomous run loop turned a person clicking dispatch into a fleet of agents dispatching each other. That autonomy exposed how much the system lied to itself, so the largest single investment became making the runner honest — watched by the observation surfaces and defended by the test suite. In parallel the foundations were generalised: the backend became swappable, then the agent engine, then the host, then the human. The remaining frontier is the north star itself — cost per verified task is only now becoming measurable, recurring self-review has stalled short of true cadence, and the steering layer is being rebuilt around planned voyages.

At the current rate of 69.8 tickets/week, the 549 open tasks represent 7.9 weeks of work — reaching 27 September 2026. At the prior rate it would be 4.8 weeks.

But that figure is a floor, and a receding one. Tickets are being created at about 190 a week against 69.8 reaching code — so the backlog grows by roughly 120 tasks every week at current rates. The burn-down above answers "how long if creation stopped", which it will not. And nothing in this workspace carries a due date — 0 of 1,810 tasks — so there is no schedule to be on or off. Every colour in this brief is flow health, never schedule health.

The more useful forward statement is about sequencing, not dates. Harbour's own north-star reading names the open question directly:

That question has force because of a specific inversion. The project's stated headline metric is cost per verified task, visible and falling — and the task that would derive it from existing capture (LIN-1625) is in progress, stale, and blocking eight others. Meanwhile the raw data to compute it already exists and is queryable today: the figures in the metrics below were derived from the live API in about fifteen seconds.

This brief was assembled by an AI agent from live data, then attacked by another one. The attack succeeded, and the headline changed — so it is worth showing the work.

What the adversary found. The first draft claimed raw commits fell only 18% against a 49% fall in tickets, and concluded the work per ticket had inflated by ~77%. Three things were wrong with it. The two series were computed on different repository sets — a missing directory change had silently made one of them a duplicate of the other. The commit counts were inflated by a merge-policy shift: squashed pull requests contribute one commit, merged ones contribute a whole branch, and the mix moved from 92% squash to about 25%. And the four-week window was the only window length at which the two measures diverged at all — at three weeks and five weeks they track each other.

Re-measured on one consistent basis, using mainline units that are immune to merge policy, work per ticket is flat (+4%). Delivery genuinely fell by about a third. The composition shift and the session evidence — both independent of git — are what survived, and they are what this brief now rests on.

That is not an aside. Harbour's own thesis is that an optimizer scored on a surface it authored itself will drift, and that the fix is a check it cannot author. This page was written by an agent, checked by an agent it did not control, and corrected against its own first conclusion. The method is the subject.