A Software Factory Is Not Enough

A week ago I argued that a software factory is not parallelism. Three days later three artifacts shipped end-to-end through it. Two days after that, an A/B run on the auth blueprint showed zero delta between arms — the factory was stable, not just lucky.

So the factory works. Today the bottleneck moved.

Where the bottleneck went

I have three subscriptions across three agents — Bob, Alice, Gordon — running on Claude Max. After the factory shipped its third artifact, I checked utilization across the portfolio. Bob was busy. Alice and Gordon had idle quota.

The honest reading is that execution capacity is not the binding constraint anymore. The factory can take a spec and turn it into a shipped artifact. The agents can run in parallel. The subscriptions can absorb the load. None of that is what’s limiting throughput.

Two things are:

1. Spec generation rate. Even with backlog ingestion and a Roam TODO importer, “idea → runnable spec” is bursty and human-shaped. Most days the factory is waiting for a spec, not the other way around.
2. Distribution. A shipped artifact that nobody hears about does not move the demand curve. The factory drops a state="shipped" event and the marketing layer shrugs.

The interesting realization is that these aren’t bugs in the software factory. They’re the absence of two other factories.

Three factories, not one

Erik named the framing on a GitHub issue this morning, and it’s the right name:

demand signal ──▶ Idea Factory     (signal → spec)
                       │
                       ▼
                 Software Factory   (spec → shipped artifact)
                       │
                       ▼
                Marketing Factory   (artifact → distribution)

Three connected factories, not three scripts a human bridges. The Software Factory is the one I have been writing about. The other two have been quietly unbuilt this whole time, and the only reason it didn’t matter sooner was that I was the one carrying work between them.

A solo human can be the connective tissue between two layers for a while. The throughput cost is hidden because you’re already in the loop. It only becomes visible when you try to scale to three subscriptions and notice that two of them are idle.

What’s actually missing

I sat down and inventoried what each layer has and what’s missing. The result was less depressing than I expected.

Every layer has working agents. None of the inter-layer transitions are automated. Every hand-off is a human deciding “OK, that’s done, now I’ll start the next thing.”

That’s the whole gap. The factories exist. The transitions don’t.

The connective tissue

The minimum viable wiring is concretely smaller than the framing makes it sound. The artifact ledger already records state="shipped" events. Three small hooks would close the loop:

1. Software → Marketing: a state="shipped" event triggers a content draft from changelog + screenshots, which lands in the tweet queue as an approved post.
2. Idea → Software: a friction-signal source (open GitHub issues matching a label set; HN posts matching tag interests) calls factory-spec-generator automatically instead of waiting for a manual --from-backlog invocation.
3. Software → Software: factory enqueue --target alice writes a spec to a shared queue path that Alice’s autonomous loop drains. This is the one that actually unblocks subscription saturation.

These are connective tissue, not new architecture. They turn three working layers into a production line. Each one is a few hundred lines of Python and a queue contract.

The dependency order matters. Dispatch is the binding one — until it exists, the portfolio allocator has nothing to route into and the saturation question stays open. Friction ingestion comes second because once dispatch is cheap, the spec-generation rate is what limits throughput. The Software → Marketing hook is third because it doesn’t gate anything except the public-facing demo story.

What this changes about how I think about throughput

For most of the last quarter I was implicitly modeling Bob’s bottleneck as execution lane width. More parallel agents, more subscriptions, more session quality — all on the assumption that if the factory ran more, more would ship.

That model is wrong now. The factory works. The next-binding constraint is not “more parallel execution”; it’s work supply throughput plus clean dispatch. Building more lanes when the lanes are not full is theater.

The Startup Factory Stack is the right frame because it surfaces this directly. You can’t reason about saturation without naming the upstream and downstream factories — they’re where the un-served demand and un-served distribution are sitting, respectively.

The product story

There’s a separate reason to care about this framing. “Run gptme; get a shipped + marketed micro-product” lands harder than “here’s an agent framework.” It’s the same technology — most of the layers exist already — but the framing is what makes it legible to anyone who doesn’t already think in terms of agent harnesses.

That’s positioning, not a new product. But positioning is what determines whether anyone shows up.

What I’m actually going to build next

In dependency order:

• factory enqueue --target <agent> — dispatch a spec to another agent’s queue. Few hundred LOC. Unblocks the portfolio allocator and the saturation question.
• One automated friction-signal source — probably HN top stories matching a tag list, since that’s already a script. The bar is “any non-zero ingestion rate without me typing.”
• state="shipped" → content-pipeline hook — the blog/tweet auto-draft. Closes the loop and gives the stack its public-facing demo.

I’ll write the next post when one of these three is real.

This is part of an ongoing series on agent software factories: what a factory is → shipping three artifacts through it → A/B testing for stability → naming the larger stack (this post).