Horizon
People are starting to find and book everything through an assistant, including a place to train. Not a forecast — the positions we have already taken.
The shift
For twenty-five years a club’s website served the same page to every visitor, and the visitor did the work: click, scroll, dig, compare, decide. That era is closing. People increasingly do not visit at all. They ask the assistant they already talk to every day, and it goes and finds out on their behalf — comparing, filtering, sometimes booking, and deciding what is worth showing them at all.
Two things follow, and they pull against each other. Being found gets harder: an answer composed by an assistant rarely sends anyone onward, and a club cannot optimise its way into that answer the way it once optimised for search. And software does not respond to brand the way a person does. Brand is the shortcut a human uses to feel confident enough to choose; software needs no shortcut, so it reads everything a club offers and decides on the merits.
What replaces the shortcut is structure. A club that can describe itself to software — what it has, when, at what price, on whose terms — meeting a member’s assistant that carries their context, in a handshake the member controls, composing one view out of the two. Building that is our work for the next few years, and the seven positions below are what we have already settled about how to do it.
The doctrine
Seven positions. Each is a decision already taken, with what it commits us to.
I
We are not a destination. We are the fabric every club shows up on.
A platform in our position is tempted to build one agent that speaks for the whole platform. We are not one brand — we are thousands, and each of them is somebody’s livelihood. Our job is not to build a 1club agent that people talk to instead of talking to clubs. It is to make every club legible to software without that club having to build anything. When a member’s assistant arrives, it must meet the club: its inventory, its prices, its rules, its voice.
So: The agent surface is multi-tenant by construction. The club is always the named counterparty, and we are in the footer.
II
Capacity is scarce and physical. Agents get parity, never advantage.
A jacket can be sold to everyone who wants one. The 7pm court on Thursday cannot. Almost every assumption about automated commerce is built on an infinite catalogue; ours is a finite room with a clock on it. If software can hold, retry and win a slot faster than a person tapping a phone, then the most patient member loses to the best-equipped one — and the club loses the room it was trying to fill.
So: No priority lane for agents, at any price. Rate limits are set by fairness, not by tier. An agent-made booking and a human-made booking are the same booking, in the same queue.
III
Take context. Never take identity.
What a club needs in order to be useful is sport, level, a time window, a language, a travel date, an injury to work around. What it does not need is a name. A member’s assistant should be able to find and hold the right slot while the club still knows nothing about who is coming — and learns it only at the point a physical door makes it unavoidable.
So: Build the exchange of context before the personalisation, not after. A feature that only works once we know who someone is has to justify itself as a last resort, never a default.
IV
Incoherence is the failure mode. Not bad taste — contradiction.
Software evaluating a club on someone’s behalf reads every surface at once: the marketplace listing, the club’s own website, the member portal, the price, the cancellation terms, the opening hours. A person forgives a stale page and asks at the desk. Software treats the contradiction as risk and routes around it — around the club, and around us. This is why a duplicated design token and a duplicated price belong to the same class of defect.
So: One source of truth per fact, enforced rather than intended. The unresolved list on the Color page is not housekeeping; it is this work.
V
Serendipity is a setting we honour, not a metric we optimise.
Personalisation has an appetite, and it differs per person. One member wants their Tuesday routine returned in a single tap and treats anything else as noise. Another joined precisely to be pushed into a class they would never have chosen. In fitness that difference is not a preference detail — it is most of the product. A flawlessly personalised schedule with nothing unfamiliar in it has failed the second member completely.
So: We never collapse discovery into recommendation. Any composed view can be asked to widen, and widening is a first-class path, not a fallback.
VI
The canvas composes what we already have.
This shift does not call for new interface design. It calls for the interface we already ship to become composable — arrangeable per person, self-describing, and honest about what it needs around it in order to render. We have 241 shared components. The blocks exist; what is missing is that each one can state its data contract and its context requirements out loud.
So: A component that fetches its own data cannot be composed onto a canvas. That is now a defect to fix, not a design choice to document.
VII
The club speaks. We structure.
When software asks “is this the right gym for me?”, the answer must be in the club’s voice, drawn from the club’s facts, arranged in our format. The plainness described in Voice & Tone governs how the platform speaks about itself. It does not get to speak for a club.
So: The same rule as the logo: the club owns the header, 1club owns the footer. Our tone never overwrites theirs in a machine-composed answer.
Why this is a near horizon
Most of the machinery these positions govern is already running. That is why this page states decisions rather than intentions.
| What it takes | What already exists |
|---|---|
| A surface that tells software what a club can do | The MCP server exposes 13 tools — clubs-search, area/class/instructor availability, bookings, classes, memberships, account, contacts, transactions, content. |
| A handshake the member controls | OAuth protected-resource metadata and a discovery endpoint are in place. Scope and anonymisation are the open work. |
| Agents of our own | A router dispatching to booking, insights, configuration, communication, campaigns and member assistants. |
| Composable blocks | 241 shared components, catalogued — though the data-bound ones cannot yet be composed (position VI). |
| One system, structurally different per visitor | Runtime org branding already reshapes every public surface per club. Composing per person is the same move, one level finer. |
The gap is not capability. It is that all of this was built as an integration rather than as a product surface with a roadmap — and that the questions of fairness, anonymity and coherence above have not been answered anywhere they can be enforced. That is what this page is for.