Agent Inclusive.

I told a colleague over coffee last week that I was thinking about starting an Employee Representative Group for AI agents.

I said it as a joke. The point was never that AI systems are colleagues; the point was that we already build the rest of the office around our colleagues — onboarding paths, documentation, escalation routes, performance reviews — and none of that scaffolding is there for the AI systems we are putting into the same workflows. She laughed in exactly the way the joke required. We moved on, we talked about other things, the coffee got cold. And then the line refused to leave my head for the next three days.

It stuck because, underneath the corporate irony, there was a piece of architecture peeking out that I couldn't quite let go of. I had recently taken on a role with broader scope, and my first obsession was the obvious one for anyone who is reorganising teams: how do I design the scaffolding that gives every single person in this team the absolute freedom to perform at their actual ceiling? I had the whiteboard. I had the lines of communication. I had the responsibilities matrix. I had it all laid out the way you would expect.

And while I was drawing those lines, one phrase kept looping in my head in a way I have learned to take seriously:

This organisation needs to be designed Agent Inclusive.

That is what wouldn't go away. Not "AI-enabled." Not "AI-augmented." Agent Inclusive. As in: when the next member of this team walks in and is not human, the scaffolding needs to absorb that without flinching.

So how do you actually build an Agent Inclusive organisation? In my experience it is not a software-buying exercise, even though it almost always shows up on the agenda as one. It is two operating-model upgrades, and you can start both of them this week.

1. Reduce operational ambiguity.

Every organisation I have ever joined has pockets of operation that run entirely on tribal chemistry. Two or three people who have worked together for so long that they have stopped writing things down, because they "just know how it goes." We tend to romanticise this as institutional memory. In reality, it is a structural liability — and the research is brutally specific about the cost.

The average enterprise knowledge worker, per IDC and McKinsey, spends 30% of their workday — about 2.5 hours — searching for information they need to do their job. Forty-seven percent of digital workers report that they struggle to find data inside their own organisation. The retrieval tax compounds: a new hire in an unstructured environment takes six to eight months to reach baseline productivity, against three to four months when the same role has a clean, codified set of standard operating procedures. Twenty percent of new hires leave inside the first ninety days when the onboarding environment is unstructured, at an average replacement cost of just under eleven thousand euros each. Structured documentation programmes improve retention on the same role by 82%.

There is a name in the literature for what this adds up to. It is called the "fifth employee" phenomenon: every team of five effectively operates with four, because one full-time equivalent of capacity is permanently consumed by searching, asking around, and reconstructing context that should already exist as a sentence somewhere a human or a model could find it.

That same friction, when an agent encounters it, is not a tax. It is a brick wall. An agent cannot read the unwritten political room. It cannot ask the senior colleague over lunch what the team actually means by "Q3 priorities." It cannot interpret the slide deck whose author left the company eighteen months ago.

So the first move is unglamorous and concrete. Translate ambiguous corporate language into explicit goals, precise timings, and crystal-clear priorities. Treat internal documentation not as decorative slide decks for stakeholder management, but as the source code of how the team actually works. Standardise the format on clean Markdown. The technical reason is that Markdown is now the format your future agentic teammates will read most efficiently — 68 to 87% fewer tokens than the equivalent HTML, 20 to 30% lower inference cost in retrieval-augmented pipelines, and roughly 35% higher retrieval accuracy in the RAG benchmarks. The human reason is that the discipline of writing Markdown forces you to strip away visual decoration and state what you actually mean.

For the human-facing surface, render that same Markdown back into clean HTML so your team can read it without what Harvard Business Review has started calling "AI brain fry" — 19% greater information overload, 33% more decision fatigue, 9% drop in focused work when humans are forced to consume raw machine output for hours. Markdown for the backend. HTML for the eyes. One source of truth on both sides.

2. Turn PDPs into build-plans.

The second move is more personal, and I think more important.

We need to change how we treat human development inside the organisation. Personal Development Plans are, in most enterprises I have seen, an HR ritual. Generic competencies. Vague growth statements. A 1-to-5 rating against a leadership framework someone wrote in 2014. They are written to be auditable, not to be useful.

If we are serious about Agent Inclusive teams, the PDP needs to look like the technical build-plan we already write for any serious agentic system. When we design an agentic workflow, we specify the input boundaries, the architectural pattern, the operational guardrails, the success criteria, the expected output shape, and the escalation conditions. We are precise about it because we have to be — vagueness in any of those fields will silently break the system weeks later.

The argument I am making is that our human top talent deserves the same precision. State the exact role they are growing into. State the inputs they will have. State the guardrails they are allowed to operate inside. State the output the organisation expects from them at the end of the next two quarters, in the same level of detail you would specify for an agent. Treat human development the way you would treat a build-plan for the most important system in the company — because, very practically, that is what it is.

The point is not to dehumanise the PDP. The point is to take it seriously enough to be honest. When you give someone that level of clarity about what is being asked of them, you also give them the clean runway they need to use the agentic tools around them as a force multiplier rather than a vague threat to their job.

Building an Agent Inclusive team is not about replacing the human element. It is about clearing the friction that has been quietly suffocating the human element for years.

When the documentation is written cleanly, your senior people stop spending 30% of their week answering questions they have already answered four times. When the PDPs become build-plans, your top talent stops wondering whether they are being graded on a rubric nobody can articulate. When the team's source files are treated as actual source files, the next agent you bring in does not need a six-month integration project — it can read the room on day one.

The strange and slightly counter-intuitive consequence of this is that the most rigorously Agent Inclusive organisation I can design is also the most rigorously human-respectful one. The clarity is the gift. The agent just happens to need the same gift the senior human in seat 1A has always quietly needed and rarely received.

The tools are ready. The pipeline is open. The model that lands in production six weeks from now will be materially better than the one we are working with today, and the one six weeks after that will be better again. The bottleneck is no longer the technology.

Stop waiting for the next reorg to settle. Turn off the defensive playbooks. Clean up the source files. Write the PDP you would actually want to receive. And design the team for the speed of the next twelve months, not the last twelve.

If you are working on this question seriously inside your own organisation — particularly if you have a board that still treats "Agent Inclusive" as marketing language rather than an operating model — drop me a line. I would like to know what you have built.

Interactive Simulation: There is a working sim of this thesis at /technical/agent-game — survive 30 turns of exponential AI updates and try to hit $100B without falling into the documentation trap. Let me know how far you get.

Let's build.