Teach the Team, Then Leave

I love building and I love coaching. I did not expect the two to end up as the same job.

Over the last three months, five founders and four sport organisation leaders have asked me for the same thing. None of them asked me to build it.

That is not the request I am set up for. When someone opens a conversation about agentic AI, I assume we are heading towards a scope, a timeline and a delivery team. Every one of these conversations went somewhere else, and they all ended on the same sentence.

Show us how you did it, so we can do it ourselves.

Some of them went away and hired for different positions afterwards. That was the first clue these were not conversations about tooling.

It took me three months to recognise what I was being asked to do, which is embarrassing, because I have done that job for most of my working life under a different name.

The thing that goes wrong first

Start here, because everything else in this article depends on it, and most writing on the subject has it backwards.

People will tell you that an agent cannot execute a process you have never written down. That is comforting and it is false.

An agent will happily execute a process you never wrote down. It will improvise one, at speed, in a tone of total confidence, and produce output that looks exactly like the output you wanted. Nobody audits it because nothing appears to be wrong. You find out six weeks later, usually from a member or a client rather than from a dashboard.

The failure mode is not that the agent stops. It is that the output looks right.

Which means the mapping work is not administrative tidying you do before the interesting part. It is the thing that determines whether the interesting part is safe.

What I actually ask

Here are the questions I use when I sit down with a team and pull a process apart. They are not sophisticated. They are just rarely asked in this order, and by someone with no stake in the answer.

What do you do, how do you do it, and why is it still done that way? The third clause earns its place. It separates a process somebody designed from a process that accumulated.

Where does the work stop and wait? Handovers are where cycle time actually dies, and they are almost never in the process documentation because nobody thinks of waiting as a step.

Who is the only person who can do this? Every organisation has three or four of these people. What they know is not written down anywhere, which is why that step cannot safely be handed over yet, and why it is the most valuable one to document.

What decision is being made here, and what would have to be true for the answer to be different? If nobody can answer the second half, it is not a decision. It is a habit with a meeting attached.

When this goes wrong, how do you find out? If the honest answer is "someone complains", you have just found the step that must not be handed to an agent until it has a check on it.

Run those five on one real process this week. You will find something you cannot justify. I have run them inside my own company repeatedly and I have never come out the other side thinking the old version was fine.

What this looks like when there are no engineers

Most writing about agentic AI assumes a development team. A national federation reads it and concludes, correctly, that it is not about them.

So take a process I know well: coach licensing and continuing education.

A governing body re-licenses a few thousand coaches on a cycle. Each one needs CPD evidence, a valid safeguarding check, and a record that survives an audit. In practice this is one or two people, a spreadsheet, and a great deal of chasing. The safeguarding expiries are the part that keeps people awake, and they are tracked by whoever remembers to look.

Nothing there is a machine learning problem. It is a process problem wearing a staffing shortage as a disguise.

Run the five questions and what surfaces is roughly this. The work stops and waits four times, each time on a human noticing something. One person holds the whole picture of which evidence counts as valid. There is a decision about borderline CPD submissions that nobody can articulate the criteria for, because the criteria live in that same person's judgement. And when something goes wrong, you find out because a club rings to ask why their coach has dropped off the register, or because an insurer asks for evidence of a check that expired months ago.

Now you have something worth automating, and you also know exactly which step must stay human and be made explicit rather than handed over. The borderline judgement gets written down as criteria, reviewed by the person who has been making it, and that document becomes the thing the agent works from. The chasing, the expiry monitoring, the evidence collation and the audit trail go to agents. The judgement stays, but it is now visible, consistent and defensible, which it was not before.

That last part is the actual gain and it has nothing to do with AI. The institutional knowledge came out of one person's head and into the organisation. It survives them leaving.

What changed inside my own company

I should say what I am basing this on, because it is not theory.

We use agentic AI development at SportERP every day. Not as a pilot running next to the real work. It is how the work happens. Three things changed, in this order.

Development. The lifecycle is unchanged and would be recognisable to any engineer. Ideation, PRD, project management, roadmap, execution. What changed is that the execution runs through groups of agents, and that the harness around them matters more than the models inside it.

That distinction is the single most useful thing I can tell anyone. The capability is not in the model. It is in the scaffolding: how work is decomposed, what each agent can see, what it is permitted to do, how output is checked, and what happens when it is wrong. Swap in a better model and change nothing else and you get a marginal gain. Rebuild the harness and the shape of the cycle changes.

Operations. Our agents detect issues, and increasingly some of those issues are other agents, which is a sentence I did not expect to write this year. Some they resolve. Some they escalate with the context already assembled to whoever owns it.

I want to be precise, because this is where people oversell. They are not autonomous operators. They are a very fast first responder attached to a human who is still accountable. The gain is in the handover, not in the removal of the human.

The CEO job. That changed too, and I did not plan for it.

I need a different kind of thinking partner most days. Somewhere to brainstorm when the answer is not obvious, somewhere to keep a knowledge base that does not rot, somewhere to work out what we will need six months from now, which is not a question a dashboard answers.

So I built one. My own RuNari assistant, connected to our business data and operations, running on infrastructure we control, with nothing leaving it to a public-facing model. It works overnight and I get a report in the morning. It does not act on the business. It prepares the day so that I argue with a draft instead of a blank page.

I can also give any of the team access to it. It is a second brain, and I do not mean that as a figure of speech. Things that used to exist only in my head are now somewhere a colleague can query without waiting for me to be free.

Which took me somewhere I had not expected. If something happens to me, RuNari can initiate a handover to my wife: access, credentials, where everything lives, and the reasoning behind the decisions that got us here. The data, the IP and the know-how survive me.

Every founder carries that risk and very few do anything about it, because the usual answer is a document nobody maintains and nobody can find. Mine is maintained daily as a side effect of being used.

Why being taught is the harder ask

Nobody serious wants to outsource the decisions that define how their organisation works. Not the infrastructure, not the operating model. In two years you will have to defend those decisions, and the consultant will be somewhere else.

But almost everyone is willing to be taught.

That is not the smaller ask. Delivery ends when the thing works. Teaching ends when they no longer need you, which means the work has to survive your absence, and that is a much higher bar to clear.

I have been on the receiving end of it more than once. There have been decisions I could not reach alone, and I have been lucky in who was around me: Chris Hall and Iqball Ullah as week by week advisors, co-founders like Yash Deshpande and Mark King, and a wider group I can call when I am stuck. None of them made a decision for me. They made me capable of making it.

This is coach development with different vocabulary

I spent years as a coach, and then as a coach developer, which is a different job entirely. Coaching makes the athlete better. Developing coaches makes other people capable of doing that without you, which requires giving away the thing you are best at and then deliberately getting out of the way.

That profession has spent decades working out how to do this well, and the method transfers almost intact.

You assess before you programme. No competent coach writes a training plan before testing the athlete. Yet most AI programmes begin with a tool selection and a licence. The mapping comes first, always, and it is not billable padding.

You set a target you can be held to. In sport this is trivially obvious and nobody argues. In business it becomes "we want to use AI", which is not a target, it is a mood. So the first phase is with leadership only, deciding what the KPIs and OKRs actually are and what has to move in six months for this to have been worth doing.

You train on the real thing. Not a sandbox, not a toy dataset. The team rebuilds a live process, in their own stack, on work that matters, with someone experienced in the room while it goes wrong the first time.

You withdraw the instruction on purpose. Coaching understands this and consultancy generally does not. The coach who is still shouting from the sideline in year three has failed, however good the shouting is. Support has to be faded deliberately and on a schedule, or dependence is the outcome you have accidentally trained.

Independence is the measured outcome. Not satisfaction. Not adoption. Whether they can run the next process themselves without calling.

To some extent we already work like this with ASOIF, as external consultants making AI accessible and realistic for international federations and national governing bodies. The ASDEG workshop on AI and new technologies in coaching is the clearest example, and I wrote up what came out of it at the time. The aim there has never been to run their AI for them.

The obvious conflict, and my actual motive

I sell SportERP, both the platform and the implementation services around it. I am building RuNari. And I am now selling a service that teaches organisations to build their own AI operating model.

You should be suspicious of that, so let me put it plainly. The framework is stack-agnostic and works on whatever you already have. Where the right answer is not one of my products, I will say so, and I have. If a framework only ever concludes that you need the consultant's software, it is not a framework, it is a funnel.

While we are being plain about motives, here is mine. I became a coach because I like helping people directly. Now I mostly coach the people who go on to help others.

I am really good at this and I love coaching. That is the honest reason this service exists, rather than a market gap I spotted.

There is one limit worth stating up front. If you ask me to help a startup build what we are building at SportERP, do not be offended when I say no :)

Does this mean I have stopped selling consultancy?

No, and I want to head off an apparent contradiction with what I wrote a few weeks ago, which was that I would never put the consultancy hat away.

Clients stop needing me for their operating model. That is the point. What tends to remain is the occasional outside head on a decision that genuinely benefits from one, which is a relationship rather than a dependency, and is what I have with my own advisors.

The distinction that matters: you should not need me to run your week. You might still want me in the room twice a year.

The shape of it

Leadership first, setting the measures. Then hands-on with the delivery or operations team, rebuilding real flows around agents in their own environment. Then a documented handover, and support that is faded on a schedule agreed at the start rather than whenever it happens to tail off.

It is not a keynote. It is not a two-day workshop everyone enjoys and nobody applies. It is not me building your agents and invoicing monthly to keep them alive.

Who this does not work for

Worth saying, because it will save us both a call.

It does not work if leadership will not commit to a measure they can be held to. Without that, the implementation work has no destination and the engagement becomes an expensive series of interesting conversations.

It does not work if the people who actually do the work are not in the room. Operational knowledge sits with them, not with whoever commissioned the project, and a process map built without them describes how the work is supposed to happen rather than how it does.

And it does not work if what you want is for someone to run this for you indefinitely. That is a legitimate thing to want. It is a different service, and there are people who do it well.

The success condition is that you stop calling.

If that sounds like a strange thing to sell, I would say it is the only thing worth selling to anyone who will still be doing this in ten years.

---

If you want to work out where your team currently sits, AI enablement for teams is the new service line. Where the decision is already made and the question is delivery, that is technology implementation.

And if you would rather score yourself before speaking to anyone, the technology readiness audit is ten questions and about five minutes. You see your result before I see your email address.