Don't build the agent.
Enable the access.

§ 01 · The channel history nobody talks about

For the past twenty years, there were three ways users reached your content. HTTP — the website. SMTP — email. And eventually, native apps. Every information architecture decision, every engagement strategy, every analytics stack was built around those three assumptions. You owned a surface, drove people to it, and measured what happened when they arrived.

That model shaped how we think about products at a level so fundamental it's become invisible. When we say "build an experience," we mean: design a surface. When we say "meet users where they are," we mean: optimize for mobile, or send a better email. The destination is always implicit. It never occurs to us to question it, because for twenty years it was the only model that existed.

A fourth channel has arrived. It doesn't have a homepage. It doesn't arrive at your front door. And it's growing faster than any of the three that came before it.

§ 02 · The channel you're not designing for

When an attendee asks ChatGPT what AI sessions they should attend at a conference, they're not opening the event app. When they tell Claude to help plan their day, they're not on the website. When a Slack copilot surfaces a speaker recommendation mid-conversation, your content either shows up — correctly, usefully, in context — or it doesn't show up at all.

These aren't edge cases. They're becoming primary surfaces for how people research, plan, and act. And for most organizations, the answer those agents return is a hallucination, a poorly parsed scrape of a web page, or an honest "I don't have that information."

We're invisible to the fastest-growing engagement channel in a generation — and we built that invisibility into our architecture.

This isn't a content problem. It's a distribution problem. And unlike prior distribution shifts, this one doesn't reward you for showing up late.

§ 03 · The mistake hiding in plain sight

The instinct when AI arrived was to build an agent. A conversational experience, powered by a model, that helps users navigate content. It's the right instinct — that work matters and should continue.

But it's too narrow. Building an agent means building another destination — a different interface, a smarter one, but still something the user has to find and open and stay inside. We replaced the app with a chatbot and called it transformation.

The deeper shift isn't about building a better agent. It's about enabling agentic access — exposing your content and capabilities as skills that any agent can invoke, regardless of where the user happens to be. The question isn't "how do we make our agent better?" It's "how do we make our content work inside the agents our users are already using?"

That reframe changes everything downstream: what you build, what you instrument, what you measure, and what counts as success.

§ 04 · What agentic access actually looks like

Making your content agent-accessible isn't speculative. The infrastructure exists now and the patterns are becoming clear.

Structured data as the foundation. Agents retrieve and synthesize; they don't browse. If your content isn't marked up semantically — Schema.org, JSON-LD, clean and queryable APIs — agents either can't use it or use it incorrectly. This is the unglamorous work that determines whether you exist in AI-mediated contexts at all.

llms.txt as your agent-facing front door. An emerging convention that gives AI systems a curated, trustworthy map of your content and capabilities. Think of it as what robots.txt did for search — a deliberate signal about how you want to be found and represented. Companies that adopt it early are making an intentional choice. Companies that ignore it are making that choice too, just passively.

MCP servers as the capability layer. The Model Context Protocol is becoming a standard interface for exposing tools and data to AI agents. An MCP server means any of them — Claude, ChatGPT, a Slack copilot, a custom enterprise agent — can query your content, surface personalized recommendations, and act on a user's behalf, without that user ever opening your app. You stop being a destination and start being a capability that travels.

Together, these aren't features you ship in a release. They're infrastructure — the layer beneath the experience that determines whether your value can exist outside the surface you control.

§ 05 · The discipline we've been avoiding

Here's the uncomfortable part. Most organizations can't do this yet — not because the technology isn't ready, but because the underlying content isn't. We've spent twenty years producing pages, not knowledge.

A page is a human-readable container. It has a URL, a layout, navigation, a designed context. It was built to be seen, not queried. The information inside it — a session description, a speaker bio, a product detail, a pricing tier — is embedded in HTML, wrapped in design decisions, tangled with adjacent content. An agent trying to extract a clean fact from a typical web page is doing archaeology.

Knowledge is different. It's structured, typed, and relationship-aware. A session isn't a block of text on a page — it's an entity with attributes: title, format, track, speakers, time, room, prerequisites, related content. Those attributes have relationships to other entities. A speaker belongs to a company, has a role, has spoken at prior events, has expertise tags that connect to sessions in adjacent tracks. When that structure exists, agents can do something genuinely useful with it. When it doesn't, they guess.

The shift from pages to knowledge isn't a content strategy refresh. It's a different discipline entirely — one most product and marketing teams have never had to develop.

Knowledge management means treating your content as a data model, not a publishing workflow. It means asking: what are the entities that matter in our domain? What are their attributes? How do they relate to each other? Who owns the quality of each? How does it stay current? These are questions that information architects and data engineers think about. They're not questions that content teams or web producers have historically been asked to answer — and that gap is now a strategic liability.

The organizations that will be most visible in an agentic world aren't the ones with the most content. They're the ones with the most legible content — structured, maintained, and queryable at the entity level. Getting there requires investing in knowledge infrastructure the same way we invested in web infrastructure in the early 2000s. It felt like plumbing then too. It turned out to be the foundation everything else ran on.

§ 06 · What this means for how we build

I've spent most of my career designing destinations. The discipline was: understand the user's journey, design each step, instrument everything, iterate toward better outcomes on the surface you control. It's good work. It produced real value.

It's the wrong frame for what's coming.

In an agentic world, the product leader's job shifts from designing experiences to designing access. The questions change. Instead of "what does the user see when they land here?" you ask "can our content be found, understood, and acted on by a system we don't control?" Instead of "how do we increase engagement on our property?" you ask "how do we make our value portable enough to exist in any context?"

Build for the surface, and you're one channel shift away from irrelevance. Build for the capability underneath, and the surface becomes secondary.

This requires different instincts and, honestly, different metrics. Engagement on your property is still worth measuring. But if that's the only thing you're measuring, you're blind to the growing share of value you're delivering — or failing to deliver — through channels you never see.

§ 07 · The bet worth making

The organizations I'm watching most carefully aren't the ones with the most sophisticated apps or the most polished conversational agents. They're the ones treating their content and capabilities as infrastructure that should work anywhere — in any agent, through any interface, on behalf of any user whose AI has decided this is worth their attention.

That's a different kind of product work. Less visible, harder to demo, slower to show in a dashboard. But it's the work that determines whether you're present in the world that's arriving — or whether you're a well-designed destination that fewer and fewer people visit, because fewer and fewer people are browsing.

We built twenty years of strategy on three channels. The fourth one is here. The question is whether we treat it like a feature or like the shift it actually is.