--- title: "What 'Agent-Ready' Actually Means for a Healthcare Service" description: "What API catalogs, Markdown endpoints, OAuth metadata, MCP, and agent skills do today, and what they do not yet do automatically." image: "https://www.vascue.io/images/blog/what-agent-ready-means-for-healthcare.png" canonical: "https://www.vascue.io/blog/what-agent-ready-means-for-healthcare" --- [All articles](/blog)Healthcare AI # What 'Agent-Ready' Actually Means for a Healthcare Service Vascue TeamAugust 15, 2026Updated August 21, 20265 min read ![What 'Agent-Ready' Actually Means for a Healthcare Service](/images/blog/what-agent-ready-means-for-healthcare.png) I spent this week making Vascue more "agent-ready." Not by adding a chatbot. By teaching other AI systems how to discover our services, understand our interfaces, and, eventually, book partner clinics on behalf of users. The most important lesson: this is groundwork, not magic interoperability. ## What We Added We published machine-readable research and discovery information such as: - [`/llms.txt`](/llms.txt), a plain-text summary of what Vascue is, who it serves, and where to start reading. - Link headers, so agents get pointers to useful resources when visiting the site. - Markdown versions of pages, so an agent can request clean content rather than parse a complex HTML layout. - A `.well-known` discovery file and MCP server card for public knowledge search over the website, which is live and contains public content only. - An Agent Skills index with `SKILL.md` files that explain how an agent should navigate the site and evaluate the claims product. - A description of the public, read-only endpoints, and of how protected access is intended to work once the booking service is deployed. These files are public, but the booking API and booking MCP service they anticipate are not currently deployed for production use. [Building for browsers, search engines, and agents](/blog/building-for-browsers-search-engines-and-agents) walks through each file. ## Who Actually Uses This Today? Primarily developer-built agents, integration platforms, crawlers, and agent frameworks that have explicitly implemented these conventions. They can use the metadata to find and integrate with a service more reliably. Consumer assistants such as ChatGPT, Claude, and Gemini do **not** automatically discover a website's agent-skills file and begin booking appointments merely because it exists. An agent normally needs an explicit integration: an API connector, an MCP connection, OAuth authorization, or a purpose-built workflow. These standards are best understood as machine-readable signage, not a complete agent product. ## The Practical Path The workflow should look like this: > Discovery metadata → public API documentation → OAuth consent → narrowly scoped booking tools → user-approved appointment For Vascue, that distinction matters. We want an assistant to help someone find an appropriate partner clinic and manage a booking, but never by exposing our database directly, bypassing consent, or making clinical decisions. An agent should receive only the tools it needs to: - Search eligible clinics. - View availability. - Create or modify a booking with the user's approval. - Do nothing beyond that scope. ## What "Agent-Ready" Does Not Mean It does not mean an assistant can see a clinic's calendar. It does not mean a patient's request bypasses verification. It does not mean the website has become an API for arbitrary software. And it does not mean a compliance box has been ticked. Each of those is a separate piece of work with its own controls, and the posts below take them one at a time. ## Where Each Piece Is Explained This post is the overview; the series covers the parts: - The patient's experience, step by step: [From "find me a physio" to a confirmed appointment](/blog/from-find-me-a-physio-to-confirmed-appointment). - How clinics are listed, and how they stay in control of it: [How partner clinics can be discovered by AI](/blog/how-partner-clinics-can-be-discovered-by-ai). - Why the gateway exists at all: [Why AI agents should not call a clinic database directly](/blog/why-ai-agents-should-not-call-clinic-databases). - The five kinds of tool a booking server exposes, and the ones it refuses: [What an MCP booking server actually does](/blog/what-an-mcp-booking-server-does). - The release conditions before any real patient is involved: [The guardrails behind AI booking in healthcare](/blog/the-guardrails-behind-ai-booking-in-healthcare). - The discovery layer itself: [Building for browsers, search engines, and agents](/blog/building-for-browsers-search-engines-and-agents). ## A Short Checklist for Any Healthcare Service For a clinic, a practice-management vendor, or a health-tech team wondering what agent-ready would mean for them, the sequence that has held up for us: 1. Publish what you already say publicly in a form software can read: an `llms.txt`, clean Markdown, stable URLs. 2. Separate description from access. Discovery files say what exists; they must never be the thing that grants it. 3. Put every action behind a gateway with a handful of narrow tools, and keep system credentials inside it. 4. Make the patient, not the assistant, the one who confirms anything that changes a record. 5. Treat approval of agent clients as deny-by-default, and rate-limit everything. 6. Test with synthetic data first, and let privacy, security, and provider review decide when real patients are involved. ## An Ecosystem Still Taking Shape Some of these conventions are established standards, while others are emerging specifications or proposals. For example, the Agent Skills discovery index is a Cloudflare draft; the `SKILL.md` format is an open ecosystem convention popularised by agent-development tooling. The direction, however, is clear: websites will increasingly need to be understandable not only to browsers and search engines, but also to software agents acting for people. We are building that foundation now. The [research pilot page](/ai-agents) is where clinics can follow or join the work without connecting a system; the [AI Front Desk](/ai-front-desk) is the live product that already handles enquiries and bookings on a clinic's own channels; and the [security page](/security) describes the controls the whole effort sits under. This article is part of the [Agent-ready healthcare (research)](/ai-agents) cluster. Start with the pillar page for the product overview, then come back for the detail. Related reading ## Keep reading - ![](/images/blog/building-for-browsers-search-engines-and-agents.png) Healthcare AI ### Building for Browsers, Search Engines, and Now Agents Why websites increasingly need machine-readable discovery, clean content, and controlled APIs alongside their normal user interface. 4 min read [Learn more](/blog/building-for-browsers-search-engines-and-agents) - ![](/images/blog/from-find-me-a-physio-to-confirmed-appointment.png) Healthcare AI ### From 'Find Me a Physio' to a Confirmed Appointment A safe, patient-led example of how an AI assistant could discover and book a clinic through Vascue. 4 min read [Learn more](/blog/from-find-me-a-physio-to-confirmed-appointment) - ![](/images/blog/how-partner-clinics-can-be-discovered-by-ai.png) Healthcare AI ### How Partner Clinics Can Be Discovered by AI, Without Becoming a Marketplace Free-for-All AI discovery should make clinic information more accurate and usable, while keeping clinics in control of what agents can see and book. 4 min read [Learn more](/blog/how-partner-clinics-can-be-discovered-by-ai) Part of the [Agent-ready healthcare (research)](/ai-agents) cluster[All articles →](/blog)