--- title: "The future software factory" description: "Software factories built around crystallized agent skills." doc_version: "1.1" last_updated: "2026-05-01" canonical: "https://modiqo.ai/blog/the-future-software-factory.txt" --- # The Future Software Factory *On agents as operators, the milieu they live in, the risk of factory abandonment, and what Christopher Alexander would say if he saw the current rush.* --- ## Everyone is a factory builder now Something strange has happened in the last eighteen months. The raw material of software — code — has effectively been commoditized. A founder with no engineering team can produce in a weekend what a five-person team would have shipped in a quarter. A senior engineer with Claude Code or Cursor can stand up infrastructure that, three years ago, would have required a small department. This is, by any reasonable measure, a miracle. It is also a problem. When the cost of producing the *raw material* of a factory drops to near zero, the bottleneck stops being production. It becomes *design*. And the industry has not yet caught up to this shift. Everyone is now a factory builder, but very few people are asking whether the factories they are throwing up will still be standing in two years. The empty factories are starting to pile up. Half-finished agent harnesses, abandoned repositories, demos that worked once and were never run again, integrations that cost more in maintenance than they ever produced in value. The output of the AI era is going to be, in part, a vast graveyard of factories nobody bothered to design. This essay is about how to build a factory worth keeping. --- ## The picture I have in my head When I think about what an agent system actually *is*, the metaphor that holds up — better than "assistant" or "copilot" or "coworker" — is **factory**. Not in the heavy-industry sense. In the sense Henry Ford or Toyota or Taiichi Ohno would have recognized. A place where work flows, where stations have specific functions, where raw inputs become finished outputs through a sequence of well-defined transformations, and where the design of the place determines what it can produce and at what cost. In this picture, an **agent is an operator** — the person at the station, with hands on the work. The agent has identity (it is *this* agent, not any agent). It has intelligence (it can reason about what is in front of it). It has memory (it can recall what it did yesterday). It has domain expertise (it knows the difference between a Stripe webhook and a Linear ticket). It has the ability to coordinate with other operators when the work crosses station boundaries. It can use tools. It can use other tools to use tools. It can loop with goals that have been set, and it can stop when those goals are met. And critically — for any operator who is going to be trusted with anything that matters — it can elicit permission, or a nonce, before performing a destructive operation. The agent operates in a **milieu**. I have written about this elsewhere, in the philosophical register: an organism is not a brain in a jar; it is a thing that lives in an environment, and the environment is part of the cognition. In the factory picture, the milieu is the operator's actual workspace. There are **micro-environments** — the bash shells, the individual sandboxes, the per-task workspaces where a single thread of work happens. And there are **macro-environments** — sets of distributed shells, the cross-team or cross-customer fabric where work that exceeds any one station has to flow. The factory has structure. There are **toll booths** — the points where authentication happens, where credentials are checked, where the operator is asked *are you really supposed to be doing this?* There are **assembly lines** — the sequenced procedures where the output of one operation becomes the input of the next. And there are **commons** — the places where what one station has learned becomes available to every other station, so the same problem never has to be solved twice. If you are building an agent system in 2026, you are building a factory whether you mean to or not. The only question is whether you are doing it on purpose. --- ## What factory abandonment looks like The reason most factories get abandoned is not that the demand disappears. It is that the *design* was never serious in the first place. Someone put up walls fast enough to ship a demo. They didn't think about how the line would actually flow when there were three operators instead of one. They didn't think about what would happen when one station broke. They didn't think about what the floor would feel like to walk on after a year of use. They didn't think about how new operators would learn the place. They didn't think about whether the building would still be the right shape when the work changed. I have watched this happen across three previous waves of infrastructure I worked on — financial protocols, virtualization, cybersecurity. Each wave produced a vast crop of half-finished factories. The pattern was always the same. The early movers built something that worked for one specific configuration. They could not adapt when the configuration shifted. They had hard-coded the operator's job into the walls of the building, and when the operator's job changed, the walls had to come down. The AI factory wave is going to be worse. The capital cost of putting up a factory has dropped so far that the discipline-cost of *not designing one carefully* has effectively vanished too. People are throwing up factories before they have a clear picture of what the factory is for. They are building demo-shaped buildings, not work-shaped buildings. So the question I have been sitting with, since we started Modiqo, is: *what would a factory look like that would still be standing in five years?* --- ## What Christopher Alexander would have said In 1977, three architects from the Center for Environmental Structure in Berkeley — Christopher Alexander, Sara Ishikawa, and Murray Silverstein — published *A Pattern Language*. It is a 1,141-page book that catalogs 253 patterns of human-scaled design, each one a problem-statement-and-solution at a specific level of scale: from the layout of regions and cities, down through neighborhoods and streets and buildings and rooms, all the way to the height of a window sill and the placement of a bench. Two years later, Alexander published the philosophical introduction to that work, *The Timeless Way of Building*, in which he argued that great architecture is recognizable by what he called *the quality without a name* — a quality that emerges when a place is alive with the patterns of how the people who use it actually live. Alexander's diagnosis of mid-century modernism was simple and devastating. Modernist architects had stopped designing for the human at the center of the building. They had started designing for the building itself — for the photograph, for the manifesto, for the abstract idea. The result, he argued, was buildings that were technically remarkable and existentially miserable. People walked around in them but did not feel at home in them. Workers used them but did not love them. Communities lived in them but did not become communities through them. The fix, in Alexander's framework, was not to abandon design. It was to *redistribute it*. A place is alive when the patterns of its design are coherent at every scale, when each pattern leaves room for the patterns above and below it to do their own work. The architect's job is not to dictate every detail. It is to provide a *language* — a vocabulary of patterns — that the inhabitants can use to make the place their own, while ensuring that the patterns at each scale support the patterns at every other scale. I think this is exactly the right frame for an agent factory. And I think the industry is currently making, at speed, the same mistake mid-century modernism made. --- ## The mistake: compressing all the intelligence into the operator Here is the temptation, and you can feel it in every piece of agent tooling shipped in the last year. The model is the smart thing. The model can reason. The model can plan. So the natural-feeling design is to *give the model more responsibility, more context, more tools*, and let it sort everything out. This is the architectural equivalent of designing a building by making the human inside it work harder. It produces operators surrounded by dumb tools — a screwdriver that does nothing but turn, a wrench that does nothing but grip — and asks the operator to keep the entire factory in its head. Every shift, every batch, every change of work order. The operator burns enormous amounts of attention on coordination tasks the building should have been doing for it. And when the operator forgets something, it burns even more attention re-deriving what it knew yesterday. What Alexander would say — and what every Toyota Production System engineer would also say — is that this is exactly backwards. The intelligence in a great factory is not concentrated in the operator. It is *distributed* between the operator and the environment. A jig that holds a part in the right orientation so it can only be assembled the correct way. A pull cord every operator can reach to stop the line when something is wrong. A kanban card that carries the next instruction without anyone having to ask. A shadow board that shows, at a glance, when a tool is missing. This is the *poka-yoke* principle in lean manufacturing — error-proofing built into the place, not into the human. It is the *jidoka* principle — autonomation, machines that know to stop themselves when something is off. And it is, in Alexander's vocabulary, the difference between a building that has the quality without a name and a building that doesn't. The patterns are at every scale, including the scale below the operator's awareness. A factory in which the operator is responsible for everything is a factory that will be abandoned the moment the operator gets tired. --- ## What this looks like in software So if I were going to design an agent factory today — and I have been, for few months now, with Modiqo — here is what I would carry with me from Alexander. I would distribute the intelligence between the operator (the agent) and the place (the runtime, the workspace, the protocols, the memory). I would refuse to compress it all into the model, no matter how smart the model became. I would design patterns at every scale — at the level of the individual call, at the level of the workflow, at the level of the team's library of crystallized procedures, at the level of the cross-organization fabric where work flows. And I would make sure those patterns fit together: that what worked at one scale composed cleanly with what worked at the scales above and below it. This is, concretely, what Rote is. I have written about the primitives separately, and each of them has its own intellectual lineage. But the thing I want to name in this essay is the integration. None of the primitives is sufficient on its own. The system is the point. Five patterns, designed as a single thing, each shaped to fit the others — and two of them quietly accumulating, over time, into the factory's memory. The Catalog is the world outside the gate. It is the set of APIs that exist out there — Stripe, Linear, Salesforce, the internal services your company runs, the long tail of everything else — discoverable as specs the factory knows how to read. The Catalog is not part of the factory; it is what the factory opens onto. The discipline here is restraint. The factory does not pretend to own the world's APIs, and it does not try to wrap them in proprietary clients. It simply knows how to find them, and knows that finding them is the first place a rediscovery tax gets paid if you are not careful. The Adapter is the toll booth, and it is the first form of memory the factory keeps. An Adapter is what happens when a spec from the Catalog gets bound into the factory as a working station — credentials checked, protocol spoken, contract enforced. It is intelligent at the level it needs to be: it speaks MCP to anything with an OpenAPI spec, and it stays out of the way at every other level. But here is the move that matters. The Adapter is not consumed when it is used. Once an operator has bound Stripe or Linear or some internal service into the factory, that binding does not evaporate when the work is done. It becomes memory. The next operator who needs Stripe does not re-bind Stripe; they recall what was already bound. The Adapter is the factory remembering, on the operator's behalf, what systems exist and how to reach them. The Canvas is the floor of the factory. It is where the work is visible — every probe, every call, every interaction with the bound Adapters leaving a trace that can be examined. It is not observability for humans; it is the surface on which the agent reflects on its own work. It is the shadow board. It is the kanban wall. The operator who walks onto it can see, at a glance, what has been done before and what is in progress now. And critically, the Canvas is the substrate on which Flows are grown. You cannot crystallize a procedure that was never visible in the first place. The Canvas is what makes the next primitive possible. The Flow is the assembly line, and it is the second form of memory the factory keeps. A Flow is what happens when a sequence of work on the Canvas has been done well enough, often enough, that it no longer needs to be re-derived. It is the part of the operator's deliberate practice that has been compressed into something deterministic — something that runs the same way every time, costs almost nothing, and can be invoked the same way by any operator who needs the same outcome. A Flow is the jig that holds the part in the right orientation. And like the Adapter, it is not consumed in use. Once a Flow exists, the operator who needs that work done again does not rebuild it from scratch. They recall it. The Flow is the factory remembering not just what systems exist but how good work through them goes. The Hub is the commons. It is the macro-environment — the fabric across distributed factories that lets an Adapter bound in one team's Canvas, or a Flow crystallized in one operator's workshop, be recalled by another operator in another organization without paying the discovery tax a second time. The Hub is not a marketplace, and it is not a registry of products. It is the commons of accumulated factory memory. Both Adapters and Flows were designed from the start to travel — bolt-compatible across team and organizational boundaries — because the value of a factory that remembers is bounded, and the value of a network of factories that remember is not. Each one of these is doing exactly the job Alexander would assign to a pattern. Each one is small — one job, one responsibility, one well-defined boundary. Each one fits with the others — the Catalog feeds the Adapter, the Adapter is invoked on the Canvas, the Canvas accumulates into a Flow, the Flow joins the Hub, the Hub feeds back into every other operator's Canvas. And the result, when you build with them, is a factory in which the operator is not asked to do every job. The operator is asked to do the job that only the operator can do — the genuinely creative, genuinely first-time-encountering reasoning that the model is uniquely good at — and the rest of the work is done by the place, or by what the place has already learned and is holding in memory on the operator's behalf. --- ## What this looks like when you walk in Alexander, in *The Timeless Way of Building*, kept coming back to a test for whether a building had the quality without a name. The test was experiential. You walked in, and you knew. The corridors made sense. The rooms felt the right size. The light came in where you expected it. The seat in the corner was where you would have wanted a seat in the corner. You did not have to be taught how to use the building, because the building was teaching you how to use it as you moved through it. I think this is also the test for an agent factory. You walk into it — as an operator, as a developer, as someone using the system to get work done — and you can tell immediately whether the design was serious. The operator does not have to be told what tools are available, because the workspace shows it. The operator does not have to remember what worked yesterday, because the Canvas remembers it. The operator does not have to rebuild what another team already built, because the Hub holds it as memory. The operator does not have to build coordination logic for cross-team work, because the Hub fabric is already doing it. The operator does not have to write defensive code around destructive operations, because the elicitation pattern is built into the protocol, not into the prompt. The factory teaches the operator how to use it. The intelligence is in the place, not just in the head of the person walking through it. --- ## A short answer to the long question So how would I build a factory if I had to start tomorrow? I would do it the way Alexander told us to design buildings, and the way Toyota told us to design assembly lines, and the way every great factory in history has been designed. I would distribute the intelligence. I would design at every scale. I would make sure the patterns at one scale leave room for the patterns at every other scale. I would refuse to compress the work into the operator, even when the operator was a reasoning model that seemed willing to take it. I would build small things that fit together cleanly, and I would build them as a single coherent system rather than as a stack of independent products. And I would design the factory to remember. Because the bricks are free now — but the learning about how to lay them is not. Every operator who re-derives an API binding, every team that rebuilds a workflow another team already perfected, every organization that re-figures-out what some other organization figured out last quarter, is paying a rediscovery tax that the AI factory wave has so far made no attempt to eliminate. The factories that get built without serious design will be abandoned within the year. The factories that treat their Adapters and Flows as recallable memory, and that connect to a Hub where that memory crosses organizational boundaries without friction, will compound. They will get faster every quarter, not because the models got better, but because the factory remembered more. Then I would walk through the factory I had built, and I would ask Alexander's test: *does this have the quality?* Does the operator feel at home here? Does the work flow? Does the place teach the operator how to use it? Does the place remember on the operator's behalf, so the operator is free to do only what the operator can uniquely do? That is the future I am building toward. That is what Rote is. Catalog opens the gate. Adapter binds the world. Canvas makes the work visible. Flow crystallizes what was learned. Hub makes the learning shared. The operators inside such a factory will, I think, look back at this moment and recognize it for what it was: not the moment when software production got cheap, but the moment when software *design* — and software *memory* — finally started to matter again.