Topics discussed:

• Nikolai showed a consensus runner: several agents attack the same problem, a summariser reports what each produced, then a second round hands every agent the others' answers and asks them to adopt the best ideas or explain why they're rejecting them. Authorship stays hidden until the end, and the final report is a table of which idea came from where and who picked it up. The honest caveat he gave himself: agreement may not mean correctness, since majority can simply win — the papers support this for cutting hallucinations, which are often accidental, more than for picking the best design. Someone offered the poor man's version for people stuck with one vendor: tell your agent to orchestrate sub-agents solving it four distinct ways, and a single model gives you real variation.
• John Grimes demoed a SMART app that reads a clinical note and proposes structured changes to a patient's problem list — coded against a terminology server, with clinical and verification status, onset and abatement dates, human-in-the-loop toggles, and AI transparency IG extensions marking which data was AI-asserted. The suggestion service is deliberately FHIR-agnostic and returns plain structured JSON, so it can be tested on its own, away from the app that wraps it. That was really the setup for the question that matters: how do you know it's any good?
• The eval suite pairs hard code-based scorers (is the output valid, did the things it claims changed actually change, is the coding valid against the intended binding, how long did it take) with LLM-judged rubrics — including coding accuracy and coding specificity scored separately, so it can catch a correct code that should have been more specific. Recall runs against 40 synthetic GP notes reviewed by a clinician and hand-annotated with the ideal modifications. A small grading app lets a human score the same samples, so the LLM judge is checked for human agreement before it's trusted to do the bulk of the work, and each sample runs three times so revisions can be compared for statistical significance rather than vibes. The conclusion worth keeping: the implementation is nearly throwaway — the spec and the evaluation data are the valuable part. They also deliberately made it slower to make it better.
• Josh Mandel showed two skills for getting patient data into an agent. The first uses SMART on FHIR to aggregate records, with a factory mode that bakes data into a downloadable zip and a connect mode where the agent generates a link, holds the private key, and pulls an end-to-end encrypted payload the transit server can't read. It includes the clinical notes, not just FHIR JSON — and that's the point: asked whether he needs to worry about nut allergies, the model checks the AllergyIntolerance resources, finds the answer isn't in them, and reads the allergist's note instead. The second skill files a full EHI request: identify the health system's EHR, look up its export capability, find and fill the provider's PDF form (or rebuild it in markdown when the form is too badly annotated to fill programmatically), collect a signature through a hosted web page, attach an appendix explaining to a records department what EHI export even is, and fax it. About 20 hours of work in total.
• Alexander demoed Web MCP: a page exposes JavaScript functions as tools the agent discovers on the fly, so instead of screenshotting the layout and guessing element IDs it gets a set of handlers — navigate, click, run. He had Claude Code drive a FHIR server console, install US Core and build a ViewDefinition in the visual builder, column by column. He was upfront that it's slower than just calling the REST API, and only really earns its place for ad-hoc visual debugging; the cost raised in discussion is that someone still has to decide what API to expose and write it. Brian showed a pipeline for FHIRPath spec coverage: categorise about a thousand tests by which feature each actually exercises, precompute indexes so the model never re-parses the 2,000-line XML, then run a Ralph loop that picks a gap at random (randomness so it doesn't get stuck retrying the same hard one), writes a test, re-checks coverage and updates the readme. AI-written tests are prefixed so a human can find and review them before commit.