Agents are an org design problem
A standing team of coding agents, each with a named desk and a real schedule. One boundary has never moved, no matter how good the model got.
The question I kept getting wrong was: what kind of problem is this? I treated it as a technical problem for longer than I should have. Pick the right model, get the context window right, wire up the right tools. None of that mattered as much as the next question, which is an organizational one: how does work accumulate into something that compounds?
I run a standing team of coding agents. Each has a named desk and a real schedule. The division of labor is explicit and written down. Agents own everything reversible: code, drafts, analysis, debugging. A human makes every call that touches money, identity, or anything that can't be undone. That boundary is not a preference; it is a hard rule that doesn't move. The moment it moved once, the model for what agents could touch became negotiable, and negotiable rules are useless.
the line at the middle is drawn once and doesn't move — it's the org chart, not a setting.
The organizational insight that took the longest to arrive is about trails. An agent that solves a bug and leaves nothing behind is not much better than a contractor who solves a bug and leaves. The solved bug has to become a document. Not a changelog entry, but a document with enough context that the next agent reading it can treat it as a constraint, not a mystery to re-solve. The compounding happens in the trail, not in the solving. Agents working inside a well-documented system get smarter with each completed task. Agents working in a clean repo with no history get dumber, because they re-derive everything from scratch.
The second insight is about quality. My first instinct was to treat generation and review as one loop: prompt carefully, get good output, ship it. That breaks down almost immediately. The model that generated the code is not well-positioned to catch the class of error it is prone to generating. The review has to be structurally separate. I have agents review each other's work against explicit invariants, things written down and checked mechanically. Where judgment is required, a human looks. The split is about the difference between checking a rule and making a call. Agents are good at the first. The second still needs a person.
the model that wrote it is a poor judge of its own failure mode — the check has to come from somewhere else.
What I did not expect is how much the organizational structure changes what the agents are capable of. Same models, same tools, different desk structure, different trail discipline, different review loop, and the output quality moves significantly. This is the part that resists being shipped as a product, because the product people keep reaching for is a better model or a better prompt interface. What actually moved the needle for me was the org chart: named accountability, explicit ownership boundaries, trails that accumulate, a review process that separates generation from judgment. Those are decisions I had to make deliberately, because the default is to skip them.