I'm building an agent factory without a blueprint, on purpose

The instinct when you want a reusable system is to design the reusable system first, then build products on top of it. I tried that instinct on this project and it stalled, the same way infrastructure-first efforts usually stall: the abstraction had no real pressure forcing it to be right, so it drifted toward whatever felt elegant rather than whatever a real deliverable actually needed.

The approach I switched to instead is what I've started calling extraction, not design. Build three real, different products in parallel, each one pulling shared infrastructure into existence only when it actually needs it, and let the factory emerge from what those three builds turn out to have in common. Extracted from the friction of shipping something real, three times, and noticing what repeats.

The three builds I'm running share almost nothing on the surface. One is a scheduled research pipeline that produces deduplicated findings. One is a personal site and content pipeline. One is an outreach engine that finds businesses with a poor web presence, generates them a site, and tries to close the deal. What they share underneath is the interesting part: a disposition question every one of them hits, build this ourselves or integrate someone else's, a site-generation need two of them hit independently, and an on-brand copy generation need the same two hit independently. That repetition, showing up in more than one build without me planning it, is the actual signal that something deserves to become shared infrastructure rather than staying local to one product.

The rule I've settled on for promoting a pattern into shared infrastructure is deliberately conservative: it has to appear in at least two independently-built products before it gets promoted, and it has to appear as an actual described block in each build's own account of what it built, not as a label, not as something I infer from the outside, not as one build's self-report alone. I had a candidate pattern, an independent review pass gating a high-stakes decision before it reaches me, that felt obviously real and obviously reusable, and I nearly promoted it early. Then a cross-model review of the promotion itself caught that only one build had actually named the pattern in its own written account. The second apparent instance carried a label suggesting the same thing, but its actual description named something else entirely. One qualifying instance isn't two. I demoted it back to a watch item, which felt like a small loss in the moment and was the right call, because promoting on a guess is exactly how a factory accumulates abstractions nobody actually asked for.

The pattern that did clear the bar is more mundane than I expected the first promoted organ to be, and that's fine, because mundane and load-bearing beat clever and speculative. Two separate builds hit the same failure independently: a decision gets made provisionally, explicitly gated on some piece of evidence that hasn't arrived yet, and there's no mechanism that fires the re-decision once the evidence actually lands. Both times, the provisional call just sat there, resolved eventually by someone remembering to go back and check, which in practice meant it mostly didn't get revisited on schedule. The fix that shipped is almost embarrassingly small: a marker attached to the decision, naming exactly what evidence resolves it, checked automatically on a routine schedule. No new tool, no dashboard, just a marker and a nightly check. I'd have built something heavier if I'd designed this up front, because a heavier answer feels more like a real solution. The lightest version that actually closes the gap is usually right, and you only find that out by waiting for a second real instance to confirm the shape before committing to it.

What's changed in how I approach any new capability now is the order of operations. I ask does this specific thing, right now, need to exist for this specific build to ship, not what the general version of this is, build exactly that, and only look for the general version once a second, independent build hits the same wall on its own. The general version built too early is a guess wearing the costume of infrastructure. The general version built on the second real occurrence is something you've actually verified is worth having, because you watched two different problems need the same answer without being told to look for it.