Topics discussed:

• Jean showed a two-day experiment: what would FHIR look like if it were built for agents from the ground up rather than as a facade over old APIs? An R6 server with a context envelope that limits what a given agent can see, Safe Harbor de-identification so PHI never reaches the model, validation before commit, and a hard human-in-the-loop gate on writing clinical resources back. The question from the group was where you'd actually use it, given the rest of the world is on R4 — the answer being that if everyone ends up with a personal health agent, you don't want to start it on a ten-year-old standard.
• PHRs have stagnated for 15 years and the group was blunt that they failed. Someone who ran one long before FHIR described usage as dumbbell-shaped: the very healthy who track everything, the quite sick who live in the record, and a vast middle for which nobody could find a value proposition. Agents change the argument — loading your own records into an agent produces insights an order of magnitude past any portal, and the small frictions (moving a prescription to a cheaper pharmacy, digging out immunisation records for a school form) are exactly agent-shaped work.
• Alexander demoed a small FHIR-based PHR: upload a document, get a summary, extract FHIR resources, reconcile them against the existing history, apply the bundle, store provenance, then chat with an agent about it. His open question to the group was whether FHIR actually buys anything for agentic coding. His answer: with a large agent-written codebase, the more control you have the better the result, and FHIR hands you a pre-built data model, communication patterns and validation — so at minimum everything the agent created is a valid resource.
• The MCP-versus-skills argument, laid out plainly. An MCP server lives inside the agent and eats context whether or not it's used, and MCPs don't compose — to chain two of them the output has to pass back through the LLM. Skills and scripts load dynamically and compose in bash, which is what agents are already good at. The counterweight: a skill is literally a prompt injection, which is fine when you wrote it and a security problem when you didn't — hence almost nobody reuses other people's skills, and one participant runs every skill he downloads through a review pass before trusting it. A related design tension: keep SKILL.md tiny and let the agent pull in reference files, or accept that if it only reads files one and seven it will miss what was in two through six.
• Someone raised tamper evidence, and it landed. If the patient brings the documents rather than the provider sending them, how does the reviewing doctor know the PDF is the real one — when the patient's own agent can regenerate an exact-looking copy, logos and all, that says what they want it to say? The same attack works in reverse, with malicious files pushed at patients. Digital signatures are part of the answer but not all of it; the group's read was that data quality and integrity is essentially an unimplemented problem, with one participant relaying an auditor friend's name for the current state: audit theatre.