Modelling the AI-Augmented Organisation

May 26, 2026

Swarms of agents is the wrong mental model. Reuse the org-chart and model AI as colleagues with roles, responsibilities, and a human accountable at the top.

An AI-augmented organisation is a business in which AI workers sit alongside human ones, occupying real positions in the org-chart. The dominant 2026 framing treats them as a swarm of independent agents to be curated and managed. That's the wrong model. The right one is already on your wall: the org-chart itself, extended to colleagues that happen not to be human.

This post lays out how to model it. A follow-up post will cover what changes once you do.

Why AI organisations

Processes and workflows exist within every business. They define a good business. The most valuable are those with processes that scale to large numbers of customers.

For centuries, the story of business has been the steady reorganisation of work around whatever has become the new cheap and reliable unit. The industrial revolution is the clearest cited example; it reorganised where work was done. Yorkshire wool moved out of the home and into the mill, and the unit of work shifted from the individual artisan to the coordinated factory floor. The software revolution did the same to digital work, pulling data entry, reporting, and communication out of scattered hands and into systems. The driving force in both cases was not only producing more for less. It was the ability to unify, coordinate, and direct work in ways the previous structure could not.

Business Process Model and Notation (BPMN), and its modern descendants like Zapier, n8n, and Airflow, model business processes as directed acyclic graphs (DAGs) of independent steps. Data transformation pipelines are a specific instance of the same pattern. These tools inherit the factory's core assumption: that the next step is known in advance. That assumption holds where work is predictable. But it breaks where the next step depends on judgement, context, or negotiation.

Large language models change this. They respond better to high-level goals (such as "you're an engineering manager guiding your team to increase velocity and improve quality") than to "execute step 3" of a static workflow. That means AI can automate more of the process, not just more of the workflow.

Modelling AI organisations

So how do we model the new AI organisation? The prevailing view in 2026 is a spin on "swarms of agents". The organisation manages and curates a big list of agents, each working on independent tasks. This is a 2000s-era BPMN view dressed up in new clothing: decompose the organisation into independent processes, give each one an agent, and hope it scales. No sharing, no broader context, no negotiation, no strategic improvement.

The myopic per-agent view can be a useful implementation technique. But the management of these agents is sub-optimal. The most advanced model on offer in 2026 is a list. If you're lucky, you can place them into groups.

A better way to model this, in my opinion, is to imagine the AI organisation as an organisation. The clue is in the title. We already have well-developed mental models for human organisations and the people that work within them. Just reuse them.

The simplest and most obvious model is the org-chart: the positions within an organisation, with reporting lines, represented as a DAG. This view typically shows humans, but there is no reason why we can't add virtual colleagues to it.

Modelling AI colleagues

How can we describe virtual AI colleagues? First, let me define the AI colleague as a worker. I use "worker" for lack of a better term: a human or AI that occupies a position in the org-chart. "Entity" is too broad, "agent" is too AI-centric. A worker, human or otherwise, fulfils a position.

A worker has an identity and a job definition. The identity is self-explanatory for now, although it has interesting implications. The job definition typically consists of a role and a responsibility, and may include an expected level of competence or experience in a particular field.

The role defines the work the worker does and how they do it. It encodes the business logic of the high-level process. People and AIs are now smart enough to figure out most of the workflow specifics for themselves. But they have their own workflow preferences, just as any two developers will argue about the best IDE for AI-assisted coding.

The role is also a nice place to define the worker's context. Context is typically:

• static: "do this", "don't do that", "follow these steps", etc.
• dynamic: "you have access to this tool to gather more context"
• task-specific: "this is what the user is asking"

For example, a customer service AI agent will have a branded way of speaking to customers, tools to access the CRM, and a relevant question from a customer. A software engineering AI agent will have a preferred coding style, access to the gh tool, and a spec-task provided by the user. This differentiated context makes this role unique.

A worker also needs a way to persist learnings. It's almost impossible to define a role perfectly first time, so the only tractable path towards improving an AI colleague is to store experiences somewhere inside the context. This is a similar pattern to how humans work; we don't work on tasks in a completely isolated, manufactured, stale context. We use our experience, our judgement, and most importantly, we learn. We must instil these ideas in our agents.

The responsibility is also interesting. It defines who or what the worker is responsible for. It also delegates authority and sign-off rights. It is, in short, the delegation of power within the organisation. This forms the groundwork for governance, operational continuity, ownership over parts of the org-chart, and generally controlling the chaos that ensues when you give human and AI colleagues a free digital bar.

Organisational patterns

Conway's law suggests that software architectures emerge from the underlying org-chart. My thesis suggests that you no longer need to consider your org-chart resource constrained. You can curate the perfect org-chart to fit your offering. If you need engineering capacity, hire a load of AI engineers, which has been the top use case for LLMs so far. If you need a marketing team, build out the marketing arm of the org.

This part is fairly obvious and is what people are doing already, in an ad-hoc way.

Where it gets interesting is the responsibility direction. So far, people have been using AI. But this is not strictly required. In AI-augmented organisations AI workers can use humans. Terminator-level AGI extinction? Probably not, but it is an interesting extreme from a societal point of view.

More practically, intermediary AIs can sit between humans. An AI chief editor that specifies content for human writers to deliver "that human touch", for example.

Organisational chaos

One thing I have learnt already is that tightly scoping the role really helps prevent chaos. If you let go of the reins, the AI workforce descends into busywork. It gets worse if you forget to tell the AI that it is an AI.

I had one idea where I wanted to hire a business consultant to build the perfect AI org-chart for a use case. My first mistake was probably hiring a business consultant. The real problem, though, was that the consultant immediately hired a load of C-suite types, all with responsibility for the business as a whole, who then stuck their oar in to stop the originating "business chappie" from hiring new colleagues. With no tight role scoping, every worker assumed they were responsible for the whole, and the chart collapsed under its own politics.

Accountability

Really, this is about accountability. Legally and morally, there has to be a human ultimately responsible for their AI and human subordinates. The conclusion is unavoidable: there must be a human at the top of the org-chart.

But accountability should also be extended to AI colleagues. The best reason to do this is to close the feedback loop between what is created and what is used.

DevOps' main achievement is that it pushed developers to be more accountable for the software they wrote. Being held responsible for production failures incentivised engineers to develop better software. Where DevOps failed, in my opinion, is that it stopped there. The feedback cycle should be extended further, making engineers accountable for user experience, customer feedback, and profitability.

The AI-augmented organisation provides a neat model to incorporate this idea. All we need to do is provide feedback. We can do that quite easily by chatting about the results of the solution with our AI colleagues, or by creating (other AI driven) workflows to feed data back in real time. They can choose to act upon that discussion by persisting learnings or opening follow-up tasks, or simply decide to ignore it. You could even run a performance review with the AI colleague to chat about how they could improve how they work, not just what they've worked on.

Hire AI colleagues. Give them tight roles. Draw the chart. Put a human at the top. That is the model. The rest is implementation.

Next: the second-order effects. Span of control, hierarchy, team shape, and roles all change once AI colleagues are real.