I've spent 27 years building and optimising operations and teams. Ground-up builds, regional structures, global operating models. Right now, I'm building a different kind of organisation. One made of AI agents.
The parallels are striking. The divergences are the story. And the divergences aren't small process tweaks. They change what organisational design even is.
My AI organisation hired in the same order a real startup does. The CFO came early. So did my trademark lawyer, because money and IP obligations exist from day one, even when you're tiny. My development agents were early too, though they were pretty raw back then. The CMO arrived later, once my projects had matured enough to need one. And the COO came last, just last month, because a coordination layer is only worth having once there's enough complexity to coordinate. The pattern of organisational need hasn't changed at all.
What's changed is the cost of meeting it. That COO took an afternoon to hire. I'd reached the point of tracking too many things across too many projects, which in a normal business is when you'd start a weeks-long search followed by months of onboarding. Instead I stood one up from a blueprint, most of the setup ran itself while I did other things, and it was operating by end of day. When a hire costs an afternoon instead of a quarter, you stop rationing capability. You add a specialist the moment you notice friction, not when you're drowning.
Same organisational logic. Radically different economics. That's the first divergence, and it's the smallest one.
The bigger divergences are in how the organisation coordinates itself.
When I set up the COO, I didn't design its reporting inputs. I asked it what it needed to do its job. It said it needed visibility of timelines and milestones across everything I'm running, and suggested how it wanted to receive them. A simple structured file, in a simple schema.
So the COO got a standing order approved. Alongside the changelog my projects already maintain as they work, each one now publishes a small structured file with its key dates and milestones, in the schema the COO asked for. And here's a detail worth pausing on: once we'd agreed the pattern, I didn't implement it. The COO did. It went out to the other projects and put the standing order in place itself. As the work progresses, the published information updates with it. If a project has a trademark deadline in flight, that deadline is sitting there, current, visible.
The result is that nobody hunts for context. The COO sweeps across the projects whenever it needs the latest state, because every project has already made itself legible. Any project can check any other project's timelines the same way. The information is just there. No status meeting required, because the status is a by-product of the work itself.
And the published files are only the fast path. The act of publishing does something useful in itself: it forces each project to distil its own high-signal summary, continuously, as part of the work. But when a specialist needs more than the summary, it reaches directly into the project. It reads the changelog. It reads the working files. It can even spin up an agent inside the project to investigate something properly. In a human organisation, that would be a specialist walking into a team's office, reading every document they've ever produced, and interviewing the team, all in seconds, without interrupting anyone's work. Between the fast path and the deep path, the context problem isn't reduced. It's closed.
That capability quietly resolves one of the oldest dilemmas in organisational design. Do you embed your specialists in cross-functional teams, close to the project and the customer, where context is rich but the craft thins out? Or do you pool them in specialist divisions, where the skill deepens but the project context fades? I've watched organisations oscillate between those two models for decades. Whichever one they choose, the cons eventually bite, and rather than offsetting them, they reorganise to the other model and start the cycle again.
I chose centralised specialists without hesitation, because the main con is gone. My specialists sit outside every project, operating at full depth, and the context comes to them. When the transfer of knowledge from the project is free and always current, pulling the specialist out of the room costs nothing.
The specialists talk to each other, too. Nothing elaborate. Each of my specialists and projects lives in its own repo. If you're not technical, a repo is the workspace developers use to hold a project's files and history. Think of it as each agent's own office, containing everything it knows and everything it's working on. One repo can simply post a query into another, choosing the right model for the job. Privacy policy needs redrafting? The request goes to the CPO. And it runs in every direction. An agent building UI inside a project doesn't guess at the approved messaging. It queries the CMO. Context flows down, work flows across, questions flow up. It's the corridor conversation of a real organisation, except nothing gets forgotten and nobody forgets to ask.
And underneath it all sits something I set up very early, knowing I'd be generating a lot of IP and know-how: an artefacts repo. Whenever I build something I want to be repeatable, the agents publish a specification into its inbox, and a curator agent categorises and compiles it. The design of the projects themselves is one of those artefacts. So is the design of the agents. New specialist? Point it at the template. New project? Bootstrap it from the repo. The organisation captures how it does its work as it does the work, then uses that knowledge to reproduce and extend itself. Institutional memory that doesn't live in anyone's head.
Now, here's the thing. If you've run operations, none of those ideas are new. Status publishing. Shared timelines. Knowledge capture. Playbooks. Organisations have been trying to do all of this for as long as I've been working in them.
And it can be done. I've done it, and done it well. But every time, it's a fight.
People produce their documentation in different formats, or late, or not at all. Someone's on leave the week it matters. Departments keep their own records but can't see anyone else's, so nobody knows whether they're aligned or quietly pulling in different directions. The playbook goes stale because nobody reads it, and nobody reads it because it's stale. None of this is because people are bad at their jobs. It's because organisations are made of humans, and humans don't natively operate like machines.
So here's what you actually do as an operations designer. You design the clean system. Then you implement it in full knowledge that the world is messy, which means layering on additional processes, checks, cadences and consequences to handle the flaws and fuzziness and jaggedness of the real world. Templates. Nagging. Roll-up meetings, and meetings to prepare for the roll-up meetings. That layer works, but it's expensive, it never stops, and as the organisation grows it grows faster, until coordination consumes more energy than the work it's meant to coordinate. Managing that layer is a huge part of what management actually is.
In my AI organisation, that entire layer is gone. The standing orders actually stand. Every project publishes, every time, in the same schema, without being asked twice. Not because the ideas are new, but because the execution is finally reliable. The sharing of information has become part of the work rather than an overhead on top of it. The clean system I designed is the system that's running. No compensating layer required.
Which is why I think the popular framing of "AI will flatten the org chart" misses what's actually happening. It's not that agents do everything and design stops mattering. The opposite. Design becomes the whole job.
Organisational design has always been constrained by what you can get humans to reliably do, not by what you can imagine. Every structure ends up as a compromise with human variability, and the org chart is the crude instrument we use to approximate a system out of people. Remove that constraint and the compromise disappears, but the design work intensifies. Someone still has to hold the vision and the detail at once. How the work flows. How the parts communicate. Where the quality checks sit. What gets captured for reuse. That's systems thinking, end to end, and it's the most demanding work in the entire setup.
I've done ground-up builds my whole career. Imagine what the thing should be, find the pieces, make them work together. The difference is that I used to implement those designs through people, then build and maintain the compensating layer that kept them true. Now the system I design is the system that runs.
I can hear the question forming: what about the people? It's the right question, and it deserves better than a paragraph. This organisation is a greenfield build. One person doing what would previously have taken a team of fifteen, and nobody was displaced to create it. What happens when structures like this meet established organisations full of actual humans is a genuinely hard transition problem, and it's a subject for another article. This one is about what the destination looks like.
Most businesses are currently asking how to add AI to their existing structure. The better question is what they'd design if they could assume the standing orders would actually stand and communication was nearly free. The people who can answer that, the ones who can genuinely design systems rather than draw org charts, are about to matter more than they ever have.
Stop building organisations. Start designing systems.
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