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 — materially fewer tokens than the equivalent HTML, meaningfully lower inference cost in retrieval-augmented pipelines, and a measurable lift in retrieval accuracy in the RAG benchmarks (measured in my own homelab setup; directionally consistent with public engineering literature but not a peer-reviewed result, so treat the magnitudes as my datapoints, not a law). 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 the measurable jumps in information overload and decision fatigue — and the drop in focused work — that show up 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. Give people the clarity you'd give an agent.

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

Start with the person, not the system. The clarity is the gift. People deserve to know the inputs they will be given, the boundaries they are allowed to operate inside, and what "good" actually looks like at the end of the next two quarters. Most of us have worked under the opposite — graded on a rubric nobody could articulate — and it is quietly corrosive. So this is a personal management philosophy more than a claim about how PDPs are run in the wild: the most respectful thing you can do for someone is to be precise about what you are asking of them.

Personal Development Plans, in most enterprises I have seen, are the opposite of that. 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 — and the person on the receiving end can feel it.

Here is the parallel I keep coming back to. When we design a serious agentic system, we are forced to be exact: the inputs, the guardrails, the success criteria, the expected output, the escalation conditions. Vagueness in any of those fields silently breaks the system weeks later. My argument is simply that a person deserves at least that much clarity — so give a person the same clarity you'd give an agent. Not because people are systems. Because the clarity we reflexively grant the machine is the same clarity we keep failing to grant each other.

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.