Over the years, I've lost many evenings to factory-building games. The one that really got its hooks into me was Satisfactory. You land on an alien planet, mine ore by hand, and gradually build production lines that feed raw materials into smelters, components into assemblers, and sub-assemblies into the next machine, until everything runs itself. My biggest build ended up looking like a massive microchip, with supply lines running everywhere and every product in the game being made automatically.
I used to assume those hours were wasted. Now I'm not so sure. What I spend most of my working week doing looks a lot like those games, and the spare time that once went into them now goes into building agent automations instead.
In my last article, I wrote about moving from using AI to running a team of agents, and how the centre of gravity shifts once you stop being the engine and become the architect. A few months further in, I'd describe it a little differently. I'm not really managing a team. I'm designing a production line, and then spending my days hunting down whatever is holding it up.
To give you a sense of the scale, my own businesses run on fourteen long-running agent sessions, each with its own instructions and its own role. They aren't spun up to answer a question and then thrown away. They stay live, hold their context, and work together as a team. There's a product lead and an engineer for each product, plus specialists across operations, marketing, privacy, finance, security and a few others.
In October, those specialists responded to around 1,500 requests. About half came from me. The other half came from other agents. Over the same month, the team spun up nearly 5,000 short-lived, single-use agents for things like reviews, research, building and testing. And that's before counting the ten agents I run inside a business where I'm the fractional Chief AI Officer.
The software side of this will sound familiar if you've been following the conversation about software factories, where AI agents plan, build, test and ship software with very little hands-on human work. The lead writes the specification and the engineer builds it. Every change is reviewed by models from other AI providers before it goes into the product, because a different model family tends to catch different mistakes. Agents log into the live site to test what they've built, and when an error turns up in production, the agent that owns it picks it up and pushes a fix back through the same process.
And the reviews are not a rubber stamp. Of the 265 review reports we've kept, close to nine in ten came back as a block. One particularly complex piece of work went through fifty-six rounds of review and fixes.
None of this is really specific to software, and for me that was obvious from the start. My career has been operating models and business processes. The AI is new, and honestly, so is the software development. So I've been building for my business operations just as much as for my software products, in parallel, and the designs and mechanisms keep feeding each other. That's become especially clear over the last twelve months, as agents have become far more capable.
My business partner gives me a lot of feedback on one of my products, mostly about the look and feel of the site and how we describe things. That used to land in my inbox and wait for me. Now my marketing agent reads it, works out whether we agree, and packages it up for the product lead, who writes the spec and hands it to the engineer. Most of that can happen without me ever reading the email.
In one of my Chief AI Officer roles, the CEO asked me to make one process a transformation priority. It was a monthly payments process that had been a bugbear for the business for over a decade. It had always been done by hand, and several attempts to automate it, through both external providers and internal projects, had never quite got there. Files arrive from dozens of partners in all kinds of formats, and they're matched against rules that mostly lived in people's heads. I used AI to design the automation and, in many cases, to work out the rules from years of past files. Of the two hundred or so rules it now runs on, fewer than half were ever written down or explained to us. The rest were recovered from the business's own past work, or put back to the business as "this is our reading, can you confirm?"
That agent now knows the process far better than I do. When someone asks me a detailed question about it, I ask the agent.
That's increasingly what my client work looks like. I agree with leadership which processes matter most, work out how they really operate, and rebuild them so an agent does the running. Then the people in the business who used to do the work start working alongside the agent instead, tuning the rules and acting on what it surfaces. Getting something working is the easy part now. Making it hold up inside a real business, with all its exceptions, controls and people, is where twenty-five years of operating model work earns its keep.
So the inputs are different and the outputs are different. One line turns feedback into shipped features. The other turns a pile of messy files into payments. But the underlying machinery is almost identical.
When I strip it back, I keep finding the same few building blocks. Something that triggers work. Agents with a clear role and only the context they need. Handoffs between them. Review before anything leaves the line. A way for problems to flow back in, whether that's an error in the code or someone in the business saying "that's not right". And a way for the line to talk to the people around it.
Take review. My payments agent doesn't just send messages to the business. Each draft goes to other models first, which check it against the rules for that process, the same way a code change gets checked. It's the same component, plugged into a different line. And in a regulated business, it matters. Every message is labelled as coming from the agent, nothing it sends goes out unreviewed, and no agent can approve another agent's actions.
I think the software factory is simply the first version of this that most people have seen. Software happened to be where the tools matured first. It won't be the only place they end up.
One of the more interesting design questions is when to add a new agent. I've ended up with a simple model in my head, and it comes down to two things.
The first is load, meaning how much an agent has to hold at once. A model may know a lot about tax law and a lot about advertising, but if you fill its working memory with both, it does neither job well. That's why my finance and marketing specialists are separate. It's less about what they know and more about what each of them doesn't have to carry around.
The second is frequency, meaning how often a busy agent gets interrupted with something new. An agent being pulled onto a fresh task every few minutes starts to drop things, much like a person would.
If an agent is high on load, you split it by focus. If it's high on frequency, you run copies of it in parallel. If it's high on both, you split first and then copy, because copying an overloaded agent just gives you two overloaded agents. And if two agents are both quiet and lightly loaded, that's a hint they could probably be one.
The parallel copies need one rule, which is that lots of agents can read, but only one should write. At the client, four agents share the same codebase and instructions. They all read freely and do their own work, but only the infrastructure agent is allowed to change the shared knowledge base and workflows. Otherwise they'd slowly overwrite each other.
The other thing that matters a lot is what wakes an agent up.
My heavier agents, the ones carrying a lot of context, don't sit there watching an inbox. That would be a very expensive way to wait. A basic script, with no AI in it at all, checks every ten minutes for anything that's due. Where the decision needs a bit of judgement, like whether a Slack message is actually meant for a particular agent, a small, cheap model makes the call. The expensive agent only wakes up when there's genuine work.
I got this wrong early on. One agent was set to wake every couple of hours to deal with overdue messages, but they were messages it had sent, which only the recipient could close. It could never finish, so it kept waking, and it chewed through a week's worth of model allowance on its own. Now nothing wakes on something that's merely open. I also learned that a small model is fine for deciding whether to wake someone up, but not for checking work. In one test, a small model happily reported reading files it had never actually opened.
So my job has become designing the line. Where the agents sit, what each one carries, what wakes them, and where the checks happen. And then, just like in the game, finding the next bottleneck, because there's always one.
The uncomfortable bit is that I'm still the biggest bottleneck. Not for lack of trying. I've worked hard at taking myself out of the line, and a lot of it has worked. One of my products now ships around twenty-eight changes a week, most of them without a yes from me. But when my operations agent measured it recently, around 57 questions still made their way to me in three days, and only about thirteen genuinely needed me. Part of the reason is that the line keeps getting busier. Every time I take myself out of a step, the factory does more, so even a shrinking share of the decisions still adds up to a full day. The difference is that it's now a full day steering the output of what used to take a whole team.
Getting myself off the middle of the factory floor is my main focus right now. It's not a single fix. It's a constant flow of optimisations, and it's what I'll dig into in my next article. In the meantime, wherever you are on this journey, it's worth noticing where work stops and waits for you. That's usually the first place to look.
Your move, human.
Damien Healy is the founder of Qanara, an Australian AI consultancy helping businesses accelerate from strategy to impact. He writes about AI-native workflows, frontier AI capabilities, and practical transformation.
My LinkedIn articles are available via my post history and here: LinkedIn Articles | Damien Healy