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; I don't think of AI systems as colleagues. What I meant 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 was redrawing a team structure: whiteboard, reporting lines, a responsibilities matrix, the usual. The question underneath was simple: how do I set this up so each person can do their best work?

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.

So how do you build an Agent Inclusive organisation? In my experience it almost always shows up on the agenda as a software-buying exercise. What it takes 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, but it is a structural liability, and researchers have put numbers on 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.

For an agent, that friction 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 clear priorities. Treat internal documentation as the source code of how the team works, and stop writing it as decoration for stakeholder management. Standardise the format on clean Markdown. The technical reason is that agents read Markdown far more cheaply than HTML. In my own homelab tests, the same documents in Markdown used 68–87% fewer tokens than the equivalent HTML, and retrieval accuracy rose by about 35%. That is my own setup and not a peer-reviewed result, so treat the magnitudes as my own datapoints; the direction matches what public engineering write-ups report. The human reason is that writing Markdown forces you to strip away visual decoration and state what you 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. One source of truth serves 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. 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" 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 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.

The parallel is in how we build agents. 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. People aren't systems, but 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 put the agentic tools around them to work, so those tools stop feeling like a vague threat to their job.