Over the last two months, it feels like every company within a 20 mile radius of Stanford has launched some type of “personal agent” product. Grok Bots, Muse, OpenAI’s Dots. Reflexively, whenever I see that much consensus in Silicon Valley, I want someone to argue the opposite.
\nThat person is my friend Nathan Baschez. Nathan is currently a product designer at Notion, and in a previous life was a founder at Lex and Every. Before that he spent some time at Gimlet Media and Substack. Fun career fact about him is that he designed and built the original version of Product Hunt. He is a great writer and was one of the earliest believers in my potential as an blogger. In this post, he argues that personal agents will matter, but the future of work is more multiplayer, more automated, and more complex than any individual agent can handle.
\nAnd with that, here’s Nathan.
\nTechnological revolutions don’t arrive fully formed. They evolve over years, decades even. Early on, crude architectures generate excitement and reveal limitations. Then they eventually make way for newer and better layers of the stack. Take the internet, for example. Decades passed between the first packets sent over TCP and the birth of the web and HTTP; another decade separated the web from the dominance of interactive web applications.
\nWe should expect the LLM revolution to look no different. It would be really weird if, just four years after the ChatGPT moment, we had already figured everything out. We should be open to new paradigms and architectures. In fact, we should be obsessively searching for them, because every paradigm shift creates winners and losers — even the mini-shifts within a mega-shift like AI.
\nIf I had to put my money on the most underrated nascent paradigm shift, it would be factories. Factories are a logical next step after skills and personal agents.
\nThis essay is meant to help you win the next paradigm. In it, I’ll define “factory” in a slightly more broad way than most people use it, make the economic argument for factories’ inevitable dominance, and show you how to build one. If you want to get ahead of the next paradigm shift within the AI revolution, or just use AI more effectively within your business, this is for you.
\nFactory (noun) — a shared AI system designed to handle specific types of tasks within an organization.
\nUsage: “I am rolling out an update to the slide deck factory so it adheres better to our new positioning, along with a few design fixes for issues we observed last week. Let me know what y’all think!”
\nImagine two consulting firms that directly compete with each other. Let’s call them BigBrain, Inc. and DumboCo.
\nBigBrain and DumboCo each have about 100 employees. They do similar revenue and are equally excited about using AI to empower their teams. But they have two very different philosophies for how to use AI: BigBrain is factory-pilled, whereas at DumboCo everyone uses their own personal agent to do everything.
\nAt DumboCo, most people use Codex or Claude Cowork. They have a Slack channel where people share skills and “AI wins,” but everyone is free to pick and choose what they want to adopt. Some people invest far more effort than others in their setups and see corresponding gains in their agents’ performance and productivity. Sometimes they will help other members of the team or do a “show and tell” session, but it’s still hard to get everyone to their level of productivity.
\nFrom my conversations with founders and folks who work in tech, I would estimate that 99% of companies today are operating this way, with varying degrees of intensity. But there is a better way.
\nBigBrain, on the other hand, is a bit more centralized in its approach to AI. Everyone still uses their own personal agent more or less constantly, but there’s also a layer of shared factories for anything complex and frequent. For example: slide deck creation, employee and customer onboarding, data questions, software bug fixes, app designs, and prototypes, etc. They even have a “factory factory” that makes it easy to spin up new factories as needed.
\nThe biggest AI enthusiasts on each team tend to be the ones who create and manage the factories that serve that team. For example, the CFO happens to be a big AI nerd and created a “monthly close” factory for her whole team to use. Meanwhile, people who just need to use the factories don’t have to worry about the details of how they are created and maintained in order to benefit from them.
\nThere are three key attributes that define a factory and differentiate it from a personal agent.
\nFactories are:
\nMost of BigBrain’s factories are fairly simple: each is a Notion database of tasks, with agents hooked up to act on those tasks as they are created, moving them through a sequence of stages. It can be as simple as todo → doing → done.
\nSome factories are purely autonomous; others involve deep collaboration with humans at strategic points. For example, the customer support factory handles emails as they come in, fully autonomously, with human intervention in rare cases. The slide deck factory, by contrast, involves collaboration at many steps (project brief, research, writing, and design). If you ask most people what an “AI factory” is on X, they’d probably emphasize the lack of humans in the loop, but for me this is the least interesting part about the systems commonly called “software factories.” The more important part is that it is a purpose-built, shared system that can be optimized by some people for the benefit of everyone else.
\nYou can buy factories from vendors, or you can build them. The most mature vendor market is for customer support agents, as sold by companies like Sierra, Fin, and Decagon. These all meet my definition of a factory even if they don’t say they are selling factories. Cognition, Cursor, and others are explicitly selling software factories. Amplitude is pivoting from product analytics to selling a “product factory” — a system to autonomously identify, build, and ship potential product improvements by looking at metrics. XBOW, Novee, Snyk, and others are building cybersecurity factories.
\n“What about skills?” you might ask. Skills can be sort of factory-like, in that they help agents perform specific tasks, and the prompts are shared. But the actual runtime environment is not shared, so people running a skill with different agents on different machines may run into configuration issues or other hiccups. And, crucially, skill runs are not easily scrutinized by skill owners. So the feedback loop is broken.
\nIt is as simple as Adam Smith: factories are key to specialization and gains from trade — the root of all productivity and prosperity.
\nDumboCo in the example above is sort of like a hunter-gatherer tribe. Everyone is responsible for reinventing their own wheel (and hand-axe, shelter, clothing, first-aid—you get the idea) . Over the course of a month, let’s say each of the 100 employees spends anywhere from 5 to 50 hours tweaking their agent’s behavior across 5–10 different types of tasks. That is an average of about 3.7 hours per task that month spent moving up the learning curve. (And, let’s be honest, not all hours are created equal. Some people are much better than others at optimizing agents for different kinds of tasks.)
\nBigBrain, on the other hand, is like a modern society with different specialized organizations that build on and depend on each other. One person or team can set up a factory that everyone else can benefit from, without having to learn anything about how the sausage is made. With a good “factory router,” employees’ personal agents can even use the factories on their behalf, getting the job done without the employees having to know the factories exist! For example, the HR team could have a factory to answer questions about benefits, and to the user it just feels like they asked their AI a question and quickly got a good answer.
\nBigBrain has the same budget of 5 to 50 hours of “AI tinkering time” per person but concentrates it on just 1–2 tasks per person. This yields 18.3 hours of optimization time per task per month, which means going 5x deeper into the learning curve on each task. This is the magic of specialization and gains from trade! And this 5x improvement is before taking into account the difference in quality of hours between a specialist and everyone else.
\nBut the “hours into the learning curve” idea is pretty abstract. What benefits do teams actually see when they spend more time optimizing each task?
\nIn general, these things make the difference between a half-baked skill someone threw together once (unused, out of date) and an active workflow that a business can rely on.
\nThere are many ways to build a factory, and, as noted above, you can also buy one. But here is the simplest starting point for most people building their own. Let’s use the example of a slide deck factory.
\nThis is the minimum viable factory setup. In most cases, you should start here and add complexity only as you actually need it, not ahead of time. But there are a few things most serious factory attempts will need sooner rather than later. Here are the most essential patterns I have observed.
\nFirst, at some point you will want to run your factory on an experimental new version of the prompt without messing up the existing flow of traffic. For this, you will need a basic prompt versioning system. You could solve it the software engineering way, with separate development and production environments and prompts deployed as code through a version control system like Git, but that adds overhead.
\nThe easier way is to use something like a Notion database. You can have a “prompts” database for the factory, with a “status” column that can be set to testing, production, or retired. And if you have different types of prompts for different stages in the factory process (e.g., research, writing, and design), you can make another column for that. Then the agents can read their instructions from a central source of truth that is easy for everyone on your team to inspect and understand.
\nSecond, once you have different versions of a prompt, at some point you will want to know whether an experimental new version is actually an improvement. You can test this yourself using your own creativity and judgment, but that takes a lot of time and work, and quality will vary depending on who is doing the testing and what they remember to test for. What you need is basically a checklist of the different tasks you want the factory to be able to handle, plus a rubric for judging whether each task was completed successfully. These are commonly known in the industry as “evals,” and they are much easier to create and use than you may think.
\nFactories — or whatever they end up being called — are AI systems that are shared, specific, and scrutinized. They are inevitable because they are economically rational. They enable specialization and gains from trade.
\nDo not be surprised if you start to hear much more about them over the coming months.
","headings":[{"level":1,"text":"Against the Personal Agents Theory of Everything","id":"against-the-personal-agents-theory-of-everything"},{"level":2,"text":"**What is a factory?**","id":"what-is-a-factory"},{"level":2,"text":"**The economic logic that makes factories inevitable**","id":"the-economic-logic-that-makes-factories-inevitable"},{"level":2,"text":"**How to build a factory: a pattern language**","id":"how-to-build-a-factory-a-pattern-language"},{"level":2,"text":"**Bottom line**","id":"bottom-line"}]}}