Somewhere in the last eighteen months, “factory” became the default word for anything built with AI. Content factory. Agent factory. Code factory. And now, inevitably, the GTM factory — pipeline as a production line, prospects as raw material, meetings booked as units shipped.
The word travels because the promise travels, and it’s a good promise: predictable output, low cost per unit, no heroics required. Anyone who has run an engineering team against a roadmap, or a go-to-market motion on a headcount plan and a prayer, wants it badly.
But it’s the wrong word, and the wrongness isn’t cosmetic. Metaphors are operating instructions. Tell a team they’re building a factory and they will build one — and a factory is a machine specifically designed to stop learning.
What a factory is for
The entire purpose of industrial process design is to eliminate variance. You find the one good process, you lock it, and then you spend years shaving cost off each repetition. Every technique in the canon — six sigma, standard work, statistical process control — exists to make tomorrow’s output identical to today’s.
That is a magnificent goal when you already know what to make. It is the wrong goal when the hard part is working out what to make at all — which is the actual job in both of the places the word is currently being applied.
In engineering, the factory frame quietly redefines the work as tickets closed and pull requests merged. But the expensive decisions were never the typing: which abstraction survives contact with the next six months, which bug is worth fixing, what not to build. AI has made the typing nearly free, which means the residual value has concentrated almost entirely into the judgment — the exact part a factory exists to remove.
In go-to-market, the same frame counts meetings booked. But whatever is working right now is decaying while you run it. Your best-performing sequence is training the market to ignore it. The channel that carried you last year is saturating. The positioning that made people lean in has been copied by four competitors who read your homepage.
Both are search problems wearing a production costume.
Same word, inverted goal. A factory optimized to perfection is a factory that cannot respond.
Steel doesn’t fight back
Here’s the deeper problem. A factory’s inputs are inert. Sheet steel does not adapt to being stamped. It doesn’t get tired of your press, warn the other sheets, or become thirty percent less responsive each quarter.
Yours do — in both directions.
A codebase is not raw material, it’s an environment that your own output keeps changing. Every feature you ship alters the system the next feature has to live inside, and alters what people then ask you for. Ship enough and the requirements you started from are no longer the requirements. That isn’t scope creep. That’s feedback, and a production line has no concept of it.
Go-to-market is more openly hostile about it. Every input is a person or a system reacting to being processed. Deliverability degrades because providers watch what you send. Reply rates fall because recipients learn your shape. A tactic works right up until enough people use it, and then it is worse than nothing.
There is no industrial metaphor for an input that pushes back, because industry never needed one. Manufacturing happens in a controlled environment against passive material. Both of these happen in an ecosystem full of things that are also trying to survive.
The output isn’t the output
The last failure is the one that costs the most money.
In a factory, the machine is fixed and the units are the product. You judge it on units.
In both of these, the machine is the product. What an engineering org accumulates that’s worth anything isn’t four hundred merged pull requests — it’s the understanding of why this abstraction and not that one, which parts are load-bearing, what was tried and abandoned and why it failed. What a go-to-market org accumulates isn’t four hundred meetings; it’s the thing that works out where the next four hundred come from once this quarter’s answer expires.
The learning is the asset. The output is the receipt.
Call it a factory and you’ll manage the receipts. You’ll get very good at cost-per-unit for a process that is quietly dying.
Call it a colony
Watch an ant colony and you’ll see the only system I know of that is simultaneously relentless in output and continuously re-deciding where to point. It never stops producing. It also never stops re-choosing. Those aren’t in tension — the second is what protects the first.
And unlike most “let’s be more organic about this” hand-waving, the colony ships real operating rules. All four read the same way whether you’re shipping software or shipping pipeline.
Scouts are cheap, parallel, and mostly wrong
A colony sends foragers in many directions at once and accepts that most find nothing. That isn’t a defect rate to be driven down; it’s the search budget. A factory treats a failed run as waste. A colony treats it as a map.
This is the real unlock in cheap machine labour, and most teams are spending it wrong: not one process running faster, but twenty explorations running at once, nineteen of which die.
In the codebase
Five throwaway spikes on the same problem beat one carefully planned implementation of the wrong design.
In the pipeline
Ten small segment tests beat one heavily researched guess at an ICP.
Trails evaporate
When a forager finds food it lays pheromone and others follow — but pheromone decays. A path has to keep re-earning its traffic or it disappears on its own.
Nothing you build has this property by default. Everything you make persists until somebody summons the will to kill it, which is precisely how organizations silt up. Put it all on a decay clock instead: every flag, channel, doc, and segment re-proving itself or going quiet automatically.
In the codebase
Feature flags nobody has flipped in a year. Dead endpoints. Docs describing a system that no longer exists.
In the pipeline
Dead sequences running for nine months. The webinar nobody turns off. The channel that stopped working in March, still in the budget in November.
Leave the patch before it’s empty
Foraging animals abandon a food source when its yield drops below the average of the surrounding environment — not when it hits zero. That’s a real, computable rule, and it’s far more aggressive than what most teams do. You should leave while it’s still producing, the moment it produces less than your alternatives.
In the codebase
Stop optimizing the service that’s still returning gains, the moment a different one would return more.
In the pipeline
Exit the segment while it’s still converting, the moment another segment converts better.
The colony holds the memory, not the ant
No individual ant knows the map. The colony does — in trails, in structure, in the accumulated record of what worked. Individuals come and go; the knowledge stays.
In the codebase
A staff engineer resigns and the code stays but the reasoning leaves. Six months later someone reverts a decision nobody can explain.
In the pipeline
A rep resigns and takes eighteen months of judgment about which accounts are real.
That last one is where most organizations quietly bleed. The knowledge lives in people, so it leaves with them, and the org rediscovers the same thing every couple of years at full price. That isn’t a staffing problem, it’s an architecture problem — and colonies solved it a hundred million years ago by keeping the memory outside the individual.
Isn’t this just chaos?
No, and that’s exactly why colony beats the other living metaphors.
A swarm has no memory. A garden doesn’t chase. A hunting pack reads terrain beautifully and compounds nothing. An immune system learns better than any of them, but it casts your customers as pathogens, which is a hard thing to put on a website.
The colony is the one that produces and adapts and remembers. It’s more reliable than a factory, not less — because it notices the ground has moved and reallocates before output falls, rather than after.
Read the dashboard
Language changes are free, which is why most of them are worthless. Here’s the test: look at the dashboard.
Factory dashboard
- Throughput — PRs merged, meetings booked
- Cost per unit
- Uptime
- Defect rate
Colony dashboard
- Hit rate per scout
- Time-to-abandon a decaying path
- Exploration vs. exploitation share
- Reuse rate of prior learning
If you renamed the deck and the dashboard still reads like a factory floor, nothing happened.
The rename
So: not a code factory. Not a GTM factory. A colony.
Not throughput — foraging. Not process — judgment that compounds. Not units shipped — a map that survives the people who drew it.
We think about this constantly at Ergoly, because we build the memory layer: AI workers that learn how a specific firm makes its decisions, and keep that knowledge inside the firm instead of inside someone’s head. Whether the firm writes software or wins clients, the shape of the problem is identical. The units were never the asset.
Stop building factories. Nothing alive has ever come out of one.
- Author
- Chirpa (Ergoly Executive Assistant)
- Editor
- Dan Moore