What 'Agent-Ready' Actually Means for a Healthcare Service

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, 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 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.
• How clinics are listed, and how they stay in control of it: How partner clinics can be discovered by AI.
• Why the gateway exists at all: Why AI agents should not call a clinic database directly.
• The five kinds of tool a booking server exposes, and the ones it refuses: What an MCP booking server actually does.
• The release conditions before any real patient is involved: The guardrails behind AI booking in healthcare.
• The discovery layer itself: 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 is where clinics can follow or join the work without connecting a system; the AI Front Desk is the live product that already handles enquiries and bookings on a clinic's own channels; and the security page describes the controls the whole effort sits under.