Running a Software Factory on a Self-Hosted AI Coding Agent Platform

Last Monday morning I had six terminal tabs open. One was a coding agent halfway through an API endpoint in one of our line-of-business systems. Another was watching a build in a second repo. Two more were parked on paused agents I was going to come back to. The last two I actually needed to remember: they had draft PRs open, and I couldn't tell you without checking which one had gotten review comments back overnight.

I wasn't writing code. I was scheduling, dispatching, and tracking status. For three engineers who weren't there. I did most of that in my head.

This Monday morning I opened a browser tab, sorted a kanban board by "needs my review," and read three plans in twenty minutes. Everything else was somebody else's problem, where "somebody else" is thirteen agents on a self-hosted platform running against my real .NET and Angular repos. Seven days in: 81 issues moved through the board, 1,138 agent runs behind them, and one lesson about batching work that did more for the token bill than any other change I made.

This is a field report from the first working week of that setup. It is not a benchmark, it is not a case study, and it is not a product review. It is what one operator saw, on real production code, over seven days.

The bottleneck governance didn't remove

I've written before about why AI-assisted development fails at system assumptions, not syntax, and about using git worktrees and ADRs to govern parallel agents. Per-feature governance keeps the code correct; parallel worktrees scale it across features. Both are prerequisites for what follows, and neither removes the load I described in the cold open.

Once the pipeline works, code generation is the cheapest step. The step I couldn't offload was being the human router. Which agent picks up which issue? Whose plan needs approval? Whose PR is waiting on review? And every routing decision I made in my head was invisible: no queue, no history, no way to hand it to someone else. The dispatcher role didn't show up in any tool, which is exactly why it was so hard to notice it had become the job.

The term "software factory" isn't mine. Hitachi Software Works used it in 1969, Microsoft published a book called Software Factories in 2004, and the agentic version of the idea has been circulating in engineering blogs since early this year. This piece is a report from inside a working week of one, not a fresh definition.

The pattern, not the product

The tool-evaluation trail is worth naming so this doesn't read as an endorsement. I started with Vibe Kanban, which now carries a "sunsetting" banner. I built my own for a few days and decided I don't want to maintain a project-management platform in my spare time. I tried Fusion (Runfusion) and it does too much: agent mesh, mission planner, oversight levels, multi-node routing. Every one of those is a day-one decision I hadn't earned. I landed on Multica because a comment in the Vibe Kanban repo pointed me there and it sat between "abandoned" and "operating system." Different reader, different tool. The pattern is what matters.

Agents are configured workers, not model calls. A squad is a group of agents under a leader agent whose only job is to decide who picks up the next card. Autopilots are agents that run on a cron or a webhook. Skills are reusable prompt-plus-tool bundles the whole squad shares. Multica happens to be the platform I run this on. Vibe Kanban was; Fusion still is; you can write your own.

The board, mid-week: issues move through Plan → Implement → Review → Done, each card assigned to an agent. (Demo workspace with fictional issues; the real one looks the same, minus the client names.)

Here is my instance after one week, capped at the four mechanics that earn their place:

The roster: each agent is a named worker with a one-line job description, its own runtime, and its own run history.

That's the mechanics list. Everything below is what makes them survive contact with a real workload.

Making it affordable was the actual engineering

I want to be direct about the war story of the first week: it was not an outage, it was cost. Most of my time went into making the same throughput cheaper. One change moved the needle more than anything else.

Batch main-issue aggregation. Before: each issue got its own end-to-end run, including an automated review sweep and a user-acceptance pass. That was slow and expensive. Now related issues roll up into a single main issue owned by a final-review agent. That agent combines the sub-PRs, resolves conflicts, runs the acceptance and live tests once, opens one PR, and folds bot and human review comments into one round of fixes. One deliberate rule makes it work: the final-review agent is allowed to fix findings itself instead of bouncing each one back through the pipeline, on the condition that it explains why. That single rule removed most of the back-and-forth between stages. I see one coherent unit at review time. My reviewer's brain gets what it wanted; the token bill gets what it needed. If you take one design idea from this piece, take that.

Two other levers matter but rank behind it. Model per agent: every agent has a bound model, a mid-tier model with medium thinking for Implement (the high-volume, low-judgment stage) and the top-tier model with high thinking for Plan, Review, and Researcher (where a wrong call costs an afternoon). On current Anthropic list prices that's $3 / $15 per million input/output tokens versus $5 / $25, and Implement is where the volume lives, so the split is worth setting up on day one. The principle is the useful part: bind the model to the role, don't ask the agent to choose. Deterministic scripts wherever a gate doesn't need judgment: the verify gates are shell scripts, not model calls. Converting them was honestly the fiddliest work of the week, more debugging than I expected, and still every check I moved from AI inference to a script paid for itself the same day. Prompt caching does the boring rest at 0.1x base input on cache reads.

Move work off AI inference and onto deterministic scripts wherever the gate doesn't need judgment. Every mechanic that survived the week is that one instinct, applied again.

Seven days of counts from this instance, plainly: 81 issues, 1,138 agent task runs, 874 agent comments, ~460 agent workspace sessions on the VM. About 14 agent runs per issue on average — the shape of the scheduling and dispatch load, made visible where it used to sit in my head. I don't have a matched-baseline week from before Multica for the same repos under the same rigor. That comparison would be the honest way to prove a delta and I don't have it. What the counts show is the shape of the workload, not proof of a speedup, and I'd rather say that plainly than dress it up.

What still needs a human

I still read every plan. I still read every diff. I do not think we're at, or we ever will be at, a point where nobody has to review. That is not a scaffold I'm trying to remove; it is the job.

The Done column is a human column. Multica changes my throughput, not my authority. The autopilots don't merge to main. The Review agent doesn't approve its own PR. The Pipeline Lead can misroute a card, and last week it did; a human noticed. If your idea of an agent factory ends with "set it and forget it," this piece isn't going to help you.

The open question: handing it to the team

Here is what I've proven: for one operator, one week, a dozen repos across two products, a managed team of agents removes the scheduling load and stays trustworthy under a human review gate.

Here is what I haven't tried: opening it up. The platform is multi-user, and the next step is as unglamorous as sharing the URL with my team and giving each engineer an account. I'm genuinely curious what happens then. Do they each build their own squad, or do we end up sharing one pipeline? Which of my conventions survive contact with other people's working styles? I don't know yet, and I'm not going to guess in print. What I can say is that this is the direction the setup points: nothing about it is personal tooling. It's a board, with teammates on it, and some of those teammates happen to be agents.

Monday morning, revisited

The board had ten cards this morning. Three were in Review waiting for me. I read three plans, approved two, sent one back with a comment, closed the tab, and wrote this.

I stopped being the scheduler; I became the reviewer. That is the shift the whole week amounts to, at the scope I've earned: one operator, a dozen repos across two products, a review gate that stays human. What happens when the rest of the team gets an account is a question for another post.

If you've already built the governance layer and the scheduling load I described at the top is starting to eat your day, the next step isn't a smarter agent. It's a place to put the agents where they can find their own work. Multica is one place; there are others; the pattern is what matters.

If you have a squad running and you've tried multi-human access on a shared board, I'd like to hear what broke first.