The site as something people's own assistants can use
Inspiration item 17, filed 2026-10-22 from the owner's notes in chat. An idea for the build round, not a change to the settled mechanics; the decision log entry of 2026-10-22 points here.
The owner's words
"I know that websites can have MCP servers, so for example we could maybe embed one so people's agents can interact with the website, or rather we could make it agentically friendly."
"If they use something regularly like ChatGPT or Claude Code, maybe, I don't know if there's such integrations where the website can offer a button and they click it, it'll launch their agent or preferred way to interact with AI."
"Typically the AI already is integrated into the calendars and emails and stuff like that, they could build their itinerary for the event … so that they could have a custom agenda basically emailed to them for the sessions they want, and or add it to their calendar directly."
"I'm just thinking how to integrate into the tools people are already used to, but that'd be great if you could just launch ChatGPT or Claude from the website and let their agents start talking to the website or extracting the information they need."
What it means for ETS27
Three lanes, from cheapest to most ambitious. They stack: the first two need nothing from any vendor, the third makes the site a tool in the visitor's own assistant.
The mind does it itself. The visitor asks for an itinerary in the bar; the mind composes it on the stage; the block offers "email it to me" and "add to calendar". The calendar part is a file (.ics) or a calendar link, both standard and vendor-free; the email part is one consented address, same consent line as the newsletter (item 15). No third-party agent involved, works for everyone, ships with the site.
An agent-readable surface. The same facts the site's own mind reads, published for any assistant that visits: structured event data on the pages (schema.org Event markup with sessions, speakers, venue and times), a calendar feed per track, and a plain-text index for assistants (the llms.txt convention). Any assistant a visitor points at the site can then build the itinerary without a special integration.
The site as a tool. A small remote MCP server that exposes the same catalog the mind uses, read-only: agenda, speakers, venue, search, build_itinerary (returning a calendar file). People add it to the assistant they already use (Claude and ChatGPT both let users connect remote MCP servers; others follow), and "open in your assistant" buttons on the site can start that conversation with a prefilled prompt. What to verify at the build round, with live sources, not memory: the exact connect and prefill mechanisms of each assistant at that date, Chrome's proposal for sites to register tools for in-browser agents (announced under the name WebMCP), and whether an "ask this site" standard has settled.
Scope and guardrails
The same scope as the mind (decision of 2026-10-20): public event data only, read-only, rate-limited, nothing personal stored except a consented address for a sent itinerary. The MCP server is the catalog with a different door, not a second brain, so it shares the data snapshot and the limits of the plumbing (research/claude-wiring.md, section 3, and the addendum of 2026-10-20).
For the samples
Nothing to design yet beyond one block: the itinerary on the stage with its two offers (email, calendar). The "open in your assistant" button is a build-round question, after the lanes above are verified.