The glossary is here so that the technical terms that appear in The Operator Letter have a single, stable definition you can refer back to. Each entry is written in the same plain register as the letters themselves, and is more comprehensive than the in-letter mention. New terms are added as new letters introduce them. If a term is missing, write and tell me which one.
Agent
An agent is a system that takes a goal, decides on its own what steps to follow, uses other software to act on the world, and adjusts its approach based on what happens along the way. It is the form artificial intelligence will most commonly take inside operating businesses over the next few years.
What distinguishes an agent from the chatbots and automations of the previous decade is that an agent acts. It does not simply respond. Given the goal of resolving a member enquiry, an agent will read the message, retrieve the member’s record, consult the relevant systems, make a decision about the right action, take that action, and log what it did. It does this by combining a language model with the ability to plan and the ability to use tools.
The word is being used loosely in the market right now. Many things being marketed as agents are in fact features with a chat interface attached. The test is whether the system can decide its own sequence of actions to meet a goal it has been given, and whether it can recover when the obvious approach does not work. If the answer to either is no, what you are looking at is closer to an automation than an agent.
APIs
An application programming interface, almost always shortened to API, is the formal way one software system exposes its functions to another. When a roster system, a payment system, and a member database all hold pieces of the same picture, APIs are the channels through which they share information and coordinate action.
Historically, operators have had a difficult relationship with APIs. They were often poorly documented, prone to breaking when the vendor changed something, and required bespoke connector code to be written and maintained for every integration. That experience has left understandable scar tissue.
The picture has changed materially over the last two years. The systems operators run on have invested in their APIs, recognising that their future value depends less on doing everything themselves and more on being a reliable system of record that other systems can read from and write to. APIs are now the foundation on which agents act. Where they are robust and maintained, agents are straightforward to deploy. Where they are not, the constraint sits with the underlying platform rather than the agent itself.
Autonomy
Autonomy is the first of the three properties that make an agent an agent. It means the system decides on its own what steps to take in pursuit of a goal, rather than being given a predetermined script to execute.
This is a meaningful departure from previous generations of software automation. A traditional automation does exactly what it was told to do in exactly the order it was told to do it. Change one input the workflow did not anticipate, and the automation breaks. An autonomous system reads the situation in front of it, decides what the next reasonable action would be, takes that action, observes the result, and decides what to do next.
Autonomy comes in degrees. A fully autonomous agent operates without supervision against a goal you have set. A partially autonomous agent makes the easy decisions itself and escalates the harder ones to a human. Most operators will deploy partially autonomous agents first, with clear rules about what the agent is permitted to decide and what must be checked. This is a governance question as much as a technical one, and it is one of the most important conversations to have before any agent goes live.
Machine learning models
Machine learning models are statistical systems that learn patterns from large bodies of historical data and use those patterns to make predictions about new situations. The previous wave of AI applied to operator businesses, principally focused on churn prediction, dynamic pricing, and member segmentation, was built on this approach.
The constraint on the previous wave was data. Useful machine learning models needed years of clean, consistent, labelled historical data to train on. Most operators, honestly assessed, did not have that. The result was that a generation of CEOs were told they had a data problem that disqualified them from serious participation in AI, and the message stuck.
The current wave of AI, the one centred on agents and the language models that power them, works differently. It draws on live data at the moment of acting rather than on historical data ahead of time. The data question is not gone, but it is a different question, and a more tractable one. Machine learning has itself moved on in the last few years and the picture for things like churn analysis is materially better than it was. That is a subject for a future letter.
Model Context Protocol (MCP)
The Model Context Protocol, almost always shortened to MCP, is an emerging standard for how systems describe their capabilities to other systems in a form that an agent can discover and use. It was introduced in 2024 and has been adopted across the major foundation model providers and a growing share of business software.
The significance for operators is straightforward. Historically, integrating one system with another required custom code, written and maintained for each pairing. MCP replaces that with a common protocol, so that an agent can discover what a tool can do, how to call it, and what to expect back, without bespoke integration work for every system in the stack. The major CRM platforms most operators already rely on, including HubSpot and Salesforce, expose MCP support, and thousands of MCP integrations now exist across the categories of system commonly found in an operator stack.
MCP is not universal yet. Some platforms in any given operator’s stack will not yet expose it, and an agent will fall back to working against the conventional API in those cases. The direction of travel is clear. Where MCP exists, the integration experience is materially cleaner. Where it does not, the existing APIs are the foundation, and as discussed elsewhere in the glossary, those APIs are now broadly fit for purpose.
Planning across multiple steps
Planning is the third of the three properties that make an agent an agent. It is the ability to hold a goal in mind through a chain of actions, including actions that fail or produce unexpected results, and to adjust the approach without losing sight of the original objective.
This is what separates an agent from an automation. An automation executes a predetermined sequence and breaks when one step does not produce the expected outcome. An agent, when a step does not produce the expected outcome, reasons about what to try next. It might retry the step, take a different approach, ask a question of a human, or update its understanding of the situation. The original goal does not change. Only the path to reach it.
Planning is what makes an agent useful for work that is not perfectly predictable. Most operator work is not perfectly predictable. Members ask questions in their own words. Bookings collide with class cancellations. Payment failures arrive at inconvenient moments. An agent that can plan across multiple steps can handle this kind of work in a way a scripted automation cannot.
System of record
A system of record is the authoritative source of truth for a particular kind of data in a business. The club management system is the system of record for membership status. The finance system is the system of record for revenue and cash. The CRM is the system of record for prospects and customer relationships.
For most operators the systems of record were also, until recently, the systems of work. The same software that held the membership data was also where staff did the work of managing memberships. That bundling is now coming apart. Increasingly the system of record holds the data, and other tools, including agents, sit on top to do the work.
For systems of record this is both a constraint and an opportunity. The constraint is that they must invest in robust APIs so that other systems can reliably read from and write to them. Without that, their long-term value erodes. The opportunity is that being a trusted system of record, dependable and well integrated, is a defensible position even as the surrounding work moves to other software. The platforms that recognise this are the ones investing in their API capability accordingly.
Tool use
Tool use is the second of the three properties that make an agent an agent. It is the ability to call other software, read databases, send messages, write to systems, book things, and produce real operational outcomes, rather than simply generating text.
A language model on its own is a clever conversationalist. It can write, summarise, translate, and reason within the text it is given. What it cannot do, on its own, is act on the world. Tool use is the bridge. When a language model is connected to tools, it can read a member’s record, check a class schedule, send an email, charge a card, update a CRM, and many other things, in the same way a colleague with access to the same systems would.
The tools an agent uses are typically the same systems your team already uses. That is one of the more useful things to understand about agents. They do not require a parallel data infrastructure or a replacement of the operator’s existing stack. They sit on top of it, calling the systems that already exist through the APIs those systems already expose. What matters is that the agent has the right authenticated access to the right tools, in the same way a new hire would.