---
title: "We Built Lane Managers For a Day and Shipped Zero Tickets"
canonical: https://dxdev.com/blog/2026-09-19_lane-managers-first-day-infra-not-tickets/
datePublished: 2026-09-19
---
Twenty commits landed on day one of the lane managers, and none of them closed a ticket.

The idea was simple. Instead of one hub session juggling everything, each area of work gets a dedicated manager: the main platform, the agent system itself, business ops, the blog, personal. A manager reads its lane's board, dispatches executors, and raises a gate when it needs a human ruling. I woke up the next morning feeling like nothing had moved, so I ran the numbers.

## What the numbers said

All 20 commits in the main repo since the previous morning were infrastructure or agent-system work. The vault repo had 23 commits, about 11 of them edits to the resume board, which is the file the managers use to hand state to their next selves. No ticket in the platform lane reached a closed state in the tracker. Two other trackers I didn't query.

What did ship was small. One preview 404 fixed and verified. One database migration (0030) applied to prod at 12:13 on my say-so, but its proof depends on a 02:00 job I hadn't checked when I wrote this. One feature built with 310 tests and nothing pushed or applied. The blog and personal lanes never started.

The gate count is the part that stung. Managers raised 17 gates. Three got resolved, and two of those three were me ruling directly in a session. The managers did their job, hit a decision that was mine, stopped, and waited. Fourteen stayed open.

## The wrong turn was mine

I ran the review cold. I pulled the lane board, the git log and the session manifests, and I started building a picture of why managers stalled. I did not open the index of the folder where these analyses live.

That index would have pointed me at a note from the day before, written after the same symptom had already scared me once. It had already found that bridge-spawned managers never actually die. The transcript just shows no re-invocation, and there was no durable place for an executor to record that it had finished. I spent a chunk of the morning rediscovering half of that from scratch. My new findings extend the old note, and none of them replace it, but I paid for the duplicate work and I only caught the miss when I went to link related notes at the end. It is now written into the review as a process miss.

## The machinery problems

Once I was reading with the right context, the list was long and unglamorous:

- **Silent model downgrade.** A bridge resume with no `--model` flag drops an Opus manager to Sonnet. Nothing errors. The manager just gets weaker.
- **Stale results.** Executors mostly did not file a result on the lane board. Twelve dispatches sat marked pending for about 18 hours, and the work behind some of them was probably finished. That is the missing durable result board from the earlier note, still missing in practice because the briefs never asked for it.
- **Two managers, one lane.** The hub started a second manager in a lane that already had one.
- **A restart that killed everything.** An Explorer restart at 10:24 took down every live session.
- **Uncommitted core.** The lane board module, the spawn admission check and the manager skill were all untracked, while the CLI that registers them was already modified. A fresh checkout would have imported code that does not exist.
- **Guardrails tuned for a different job.** Managers are capped at 12-line writes and 5 bulk shell calls per session, with no override, and every dispatch requires an ESTIMATE line. Fine for a hub that delegates. Awkward for a manager that has to do real coordination.
- **The hub doesn't know they exist.** The hub skill never mentions managers, so nothing tells it to defer to one.

The 125 tests around the lane machinery pass. That tells me the pieces behave as written. It does not tell me the seat gate blocks anything at runtime, and I haven't checked.

## What I'm changing

None of this is tested yet, so treat it as a plan. Commit the lane system today. Run one lane at a time, the platform first, so there is one manager to watch. Batch each lane's gates onto a single click-to-answer page and pre-approve the reversible ones, since 14 open gates is a queue I built for myself. Pass `--model` on every resume. Make "file a lane result" a required line in every executor brief. Teach the hub about managers.

The last item on my list is the uncomfortable one: keep managers off infrastructure work. The system meant to run the work kept producing work about itself, and it did so with nobody deciding that. Twenty of twenty commits is what an unattended default looks like. A lane manager for the agent system is a legitimate lane, but on day one it was also the only lane that had unblocked work, so it got all the attention.

I still expect the managers to pay off. What I know today is that the thing that runs the work and the work itself compete for the same hours, and the first day went to the runner.