Agents are the most likely form AI will take inside your organisation, and certainly the most visible. They will be where the value from this technology shows up first, and the operators who understand what one actually is will make better decisions over the next eighteen months than those who treat the word as interchangeable with everything else AI-shaped.
The term is already being misused. It is following the same path the word “cloud” took a decade ago, when it started as a precise technical idea and ended up meaning almost anything not running on a server you owned. Operators who held the precise meaning made cleaner decisions. Operators who let it drift bought the wrong thing twice before figuring out what they actually wanted. We have an opportunity to skip that step this time.
In this week’s letter I set out what an agent actually is, why some of the worries you may already hold about deploying one are largely the wrong worries, and why our relationship with software is about to change in a way that matters at board level.
What an agent actually is
An agent is a system that can take a goal, decide on its own what steps to take, use other software to act on the world, and adjust based on what happens along the way. Three properties separate it from what came before.
The first is autonomy. You give it the outcome you want, not the sequence of steps to get there. The agent decides the sequence. If the first approach doesn’t work, it tries another. This is the property that makes the word “agent” appropriate in the first place. A system that follows a fixed script, however clever the script, is not acting on its own.
The second is tool use. An agent can call other software, read databases, send messages, book things, write to your systems, and pull from your existing platforms. It does not just generate text. The text is the by-product of work it is actually doing on your behalf. This is the property that turns a language model from a clever conversationalist into something that produces operational outcomes.
The third is planning across multiple steps. An agent holds a goal in mind through a chain of actions, including ones that fail. If a system returns an error, the agent does not stop. It works out what to do next. If a customer responds in an unexpected way, it adjusts. This is what separates an agent from an automation. An automation breaks when the world changes. An agent reasons about the change.
Take a concrete example. A prospect fills in an enquiry form on your website asking about corporate memberships for a team of forty. A lead-routing tool reads the form and emails the sales team. An agent reads the form, checks whether this company has been in your CRM before, looks at the proximity of the prospect to your nearest two clubs, drafts a personalised reply with availability and corporate pricing for the right tier, books a discovery call into the sales rep’s calendar at a time that fits both parties, writes the opportunity into the CRM with the right ownership and stage, and follows up the prospect with a tailored reminder if they don’t reply inside seventy-two hours. The lead-routing tool is a feature. The agent is doing the work a colleague would do, on a goal you set.
That distinction is the one that matters. Everything else in this letter follows from it.
The worry about your existing platforms
The first concern most operators raise when this is described to them is reasonable and earned. Every integration project they have lived through has been brittle. APIs change without warning, connectors break, vendors deprecate endpoints, and the entire scaffolding holding a workflow together collapses at the worst possible moment. If agents rely on calling tools across the systems already in your business, why would that not be a fragile mess waiting to happen all over again?
The honest answer comes from looking at where the sector actually is today. Over the last two years, the API capability of the systems operators run on has improved materially. The long-entrenched club management systems have recognised that their future value sits less in delivering every function themselves and more in being the trusted system of record that other systems read from and write to. That recognition only holds if their APIs are robust and maintained, and the ones that intend to remain relevant are investing accordingly.
There is also an emerging standard worth knowing the name of: the Model Context Protocol (MCP). MCP is a way for systems to describe their own capabilities in a standard form so that agents can discover and use them without bespoke connector code. The major CRM platforms operators already rely on, including HubSpot and Salesforce, have MCP support, and thousands of MCPs are now available across the categories of system commonly found in an operator stack. It is not yet universal. Plenty of the platforms in your stack will not expose MCP for some time, and where it is missing, the agent works against the conventional API instead. The plumbing is now good enough to act, and it is getting better at a rapid pace.
Past pain from integration projects is real, and it shaped reasonable scepticism. It should not temper enthusiasm for this wave of technology.
The data question
The second concern, often unspoken, is data. For years operators have been told they don’t have the data to do AI properly. Their data is incomplete, inconsistent, locked inside vendor systems they don’t control, or not granular enough to support the kind of analysis the consultants of the last cycle were selling. That message has been internalised. Many CEOs now believe their organisation has an inherent data problem that disqualifies them from serious participation.
The earlier wave of interest in AI applied to operations, which for most operators never really took hold beyond a few pilots, was built around machine learning models that needed large volumes of clean, labelled, historical data to train on. If you wanted a churn prediction model, you needed years of consistent member records, attendance patterns, payment histories, and outcome labels. The objection that you didn’t have the right historical data to train such a model was the objection of its time. Worth noting that the picture on machine learning has itself moved on significantly since then, particularly in areas like churn analysis where agents and modern models now combine in genuinely useful ways. That is the subject for another letter. The point here is that the historical biases that grew out of that earlier conversation should not be allowed to shape how you understand what is being discussed now.
The agent question is a different question. The right way to think about it is to treat an agent like an employee. If you ask a new hire to take on a task, the question you ask yourself is what access do they need and to which tools, to be able to do the job. That question is normally straightforward to answer because the tools are well defined and the access is granted within known systems. Agents are the same. The data they need is the live state of the work in front of them at the moment of acting. The member who just emailed. The lead that just came in. The class that just had a no-show. The schedule as it stands right now. Where the data work sits is in making sure the agent has the right authenticated access to the systems where that live state already lives, not in building a multi-year data warehouse before anything useful can happen.
For most operators, that is a far more tractable question than the one they had previously been answering.
Why this matters at board level
Some CEOs reading this will quietly wonder whether they had an AI question previously at all. The honest answer is that the last cycle of AI in this sector was largely a niche conversation about prediction models, and most operators reasonably looked at it, decided it didn’t apply to them, and moved on. That was a defensible call at the time.
This cycle is different, and the difference is what makes it a board-level matter rather than a technical one.
My own view, stated plainly, is that by the end of 2026 the majority of operators will have at least one agent employed inside their business, by the middle of 2027 effectively all of them will, and by the end of 2028 the question will not be whether you have an agent but how many you are managing and how well.
Software is becoming something different. It used to be a set of tools your team operated. A marketing platform your marketer used, a CRM your sales team kept up to date, a finance system your accounts team logged into. The value of the software was a function of how skilfully your team used it.
Agents shift this. Software is becoming something that operates itself against goals you set, using the tools your team used to operate, and reporting back on what it did. The value of the software is no longer a function of how well your team uses it. It is a function of how well you have defined what you want done, and how you measure whether it was done well.
That is a different kind of purchase. It is a different kind of accountability. It changes how you should think about headcount, because work that used to need a person now needs a clear goal and a check. It changes how you think about vendor selection, because the relationship is no longer with a tool you operate but with a system that operates on your behalf. It changes how you think about risk, because the system is making decisions, and the question of what it is allowed to decide and what it must escalate becomes a governance question rather than a configuration question.
CEOs who internalise this shift early will structure their organisations differently over the next three years than those who don’t. The work isn’t to become an expert in the technology. The work is to recognise that what software is, as a category of asset and as a category of decision, is changing under you, and to lead your organisation through that change rather than be carried by it.
That is the conversation this letter exists to support.
