125 passing tests and a seat gate nobody had checked at runtime

20 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. We came back the next morning feeling like nothing had moved, so we ran the numbers.

What the numbers said

Every one of the 20 commits in the main repo since the previous morning was infrastructure or agent-system work. The notes 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 we 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 our say-so, but its proof depends on a 02:00 job we hadn’t checked when we 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 us ruling directly in a session. The managers did their job, hit a decision that was ours, stopped, and waited. Fourteen stayed open.

Reviewing cold cost us a morning

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

That index would have pointed us at a note from the day before, written after the same symptom had already scared us 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. We spent a chunk of the morning rediscovering half of that from scratch. Our new findings extend the old note and none of them replace it, but we paid for the duplicate work, and we only caught the miss when we went to link related notes at the end. It is now written into the review as a process miss.

The machinery problems

Once we were 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 us the pieces behave as written. It does not tell us the seat gate blocks anything at runtime, and we haven’t checked.

What we’re 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 we built for ourselves. 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 our 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. That 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.

We still expect the managers to pay off. What we 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.

If you put automated managers over your work, check two things before anything else: where each manager records finished work, and whether a resume keeps the model you intended. Ours did neither without being told.

dxdev LESSON · paste into your AI coding agent
LESSON: Managers Compete With Their Own Work For The Same Hours
SOURCE: dxdev.com/blog/lane-managers-first-day-infra-not-tickets
WHAT HAPPENED: A hub session was split into per-lane managers that dispatch executors and raise gates for human decisions. The next morning, every commit in the main repo was infrastructure or agent-system work rather than ticket work, and no ticket in the platform lane closed. Managers raised 17 gates but only three resolved, two of those by direct human intervention, leaving 14 open. The author also skipped an existing notes index and duplicated a prior day's analysis of the same stall symptom before catching the miss. A long list of unglamorous machinery problems surfaced: silent model downgrades on resume, executors not filing results, duplicate managers in one lane, an unrelated restart killing all sessions, uncommitted core files, guardrails sized for a delegating hub instead of a coordinating manager, and a hub skill that never mentions managers exist.
THE RULE: When you introduce a system meant to run the work, watch for it silently consuming the available hours on work about itself; if it's the only lane with unblocked tasks on day one, it will absorb all the attention by default, so deciding what NOT to run it on is as important as building it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Before starting a new investigation, check whether an existing index or notes folder already covers the same symptom
      2. Verify that every resume/spawn call explicitly passes required flags like --model instead of relying on defaults
      3. Confirm executors have a required, checked step to file results to a durable/shared board rather than leaving dispatches marked pending
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.