The Agent That Runs a Client's Website

We are about to put an agent live on WhatsApp that works on a client's website with them, the way one of us would have done.

They ask for a change and it makes it. It updates content, adjusts the site, builds out the SEO as things move. Around ninety percent of what they would previously have raised a ticket for.

That last number is the part worth sitting with. Not because ninety percent of the work disappears, but because ninety percent of the waiting does.

Why it knows enough to be useful

Most attempts at this fail on context rather than capability. An assistant that can write copy but does not know which client it is writing for, what they sell, or what the site is built on will produce something plausible and wrong.

This one understands the users and their business. It understands the site. It understands the infrastructure underneath it. It knows all of that because it is wired into SportERP, where the client's data already lives.

Nothing has to be explained to it twice. That is not a small convenience — it is the difference between a tool you supervise and something that can be trusted with a task.

It is not a chat box on a publishing workflow

The tempting version of this product is a text input bolted onto a CMS. That is not what this is, and the difference is in what happens after the request.

It validates the change. It tests it. It shows them the result. And it pulls one of us in when the work goes deeper, or when something does not look right.

We are still on the other end of it. What has actually changed is that the client can now talk to the system directly, in the place they already are, and get something done.

That is a kind of colleague.

The part that touches the org chart

I have spent most of my career managing people. Hiring them, unblocking them, arguing with them, learning from them. None of that is going anywhere.

But every team I have run until now has been entirely human. That has quietly stopped being true.

We are past coding assistants. These are agents that own a task end to end, run it in their own sandbox, and hand the result back accurately enough that you stop rechecking every line. Once that threshold is crossed, the question stops being about tooling and starts being about structure.

So: how much of the old org chart does that touch?

More than I was comfortable admitting.

• Front end work, where a well-specified change is now a request rather than a ticket.
• DevOps, where routine operational work runs without a person waiting on it.
• Monitoring, where something can watch continuously instead of at intervals.
• Business analysis, where something now sits in the live data all day looking for what actually moves the number.
• Support, where the agent does not just reply — it acts.

Which means it cannot sit outside the perimeter

Here is where I think most organisations are going to get this wrong. If these things do real work, they cannot be treated as tooling and left outside the governance that applies to everyone else.

They need scope — a clear boundary on what they may touch. They need permissions that reflect that boundary rather than convenience. They need review, because work that is never reviewed is work nobody owns. And they need someone accountable when they get it wrong.

That someone is still me. Delegating the work does not delegate the responsibility, and any model of this that pretends otherwise is describing a liability rather than a capability.

What I underestimated

I expected the change to be about speed. It is partly that. But the thing I did not see coming is what happens when a system stops waiting to be asked.

It raises the enquiry. It surfaces the opportunity. It builds the better view before anyone requests it.

That inverts something fundamental about how a team operates. For my whole career, capacity has been the constraint that decided which good ideas got acted on. Most of them were never rejected — they simply never reached the top of anyone's list. A system that acts before being asked changes which ideas survive.

Where this goes

We are building our own way of handling this inside sport, and we are shipping it to clients. We are also running it on ourselves, because it has changed how we work day to day — and I would not ask a client to adopt something we were not prepared to depend on.

Now we are working out whether it stays part of SportERP or stands on its own. The argument for the second is straightforward: the teams and small businesses that could never afford this kind of capacity are exactly the ones it would change most. A federation with a handful of staff and a coach running a squad on evenings and weekends have the same problem, and neither of them has ever been able to buy their way out of it.

I will keep you posted on both.

---

If you are working out what agentic delivery means for your own team — the structure, not the demo — that is the substance of my product and technology leadership work, and the implementation side sits under technology implementation.