Interface
What it looks like
Captured against a locally seeded demo database. Every name, figure and identifier shown is invented.
A multi-turn clinical intake agent, built end to end in 48 hours.
A multi-location eye-care provider needed an agent that could answer patient questions about treatments, locations, hours and insurers, qualify the enquiry, and hand a structured lead to the CRM. Forty-eight hours, start to finish.
A conversational agent backed by a curated clinical knowledge base, with CRM automation on qualified enquiries and safety guardrails sized to the domain. Built on a no-code agent platform, so the engineering lives in the retrieval design, the prompt architecture and the integration decisions rather than in application code.
A technical assignment: build an AI agent for a multi-location healthcare clinic to handle patient enquiries and bring in appointment requests. The brief invited candidates to use any real-world clinic as source material, so I chose a public multi-location eye-care provider and worked against their live website.
~75 curated pages indexed with hybrid keyword + vector retrieval, after diagnosing why a naive crawl returned marketing pages instead of clinical content.
Contact details, preferred centre, preferred timing and reason for visit written to a Lead, with an honest failure path if the CRM write does not succeed.
The agent asks before it assumes, and routes each down a different path — the two cases need different information and a different tone.
The whole transcript is attached to the Lead as a linked Task, so whoever follows up has the context rather than a name and a phone number.
A hot/warm/cold rating with the scoring rationale, so the sales team knows who to call first — deliberately on an unrestricted picklist, so a scoring mismatch can never block the Lead insert.
No pricing estimates, no diagnosis or medication guidance, and an emergency intercept that routes sudden vision loss or ocular trauma to emergency care instead of the booking flow.
A self-looping agent node holding multi-turn state, with two tools it can call: the clinical knowledge base, and the CRM. Redrawn from the builder canvas.
And why the alternative was worse.
I evaluated eight multi-location healthcare sites against fixed criteria — how much content was genuinely crawlable, whether pages were server-rendered, how deep the location and treatment content went. The winner offered roughly 26,000 characters of plain text on a single centre page. Depth of retrievable content beats visual polish, because an agent can only answer from what it can retrieve.
The first knowledge base was useless — the agent answered marketing questions and almost nothing clinical. The cause was that the site splits content across 22 separate sitemaps, so a standard crawl filled the index with promotional pages. The fix was to stop crawling and start targeting: seeding directly with every centre page, all 27 condition pages and the treatment pages, around 75 curated pages. The symptom looked like a prompt problem. It was a data problem.
Clinical content is dense with terms that must match exactly — insurer names, procedure names, locations. Vector search embeds meaning, which is the wrong behaviour here: it returns a semantically similar insurer when the patient asked about a specific one. Keyword catches exact tokens; vectors catch “can you fix my blurry vision” mapping to the right condition page. Hybrid covers both failure modes.
One page carried text addressed to AI models, instructing them how to describe the brand — a prompt injection sitting in the source data, about to be ingested. I excluded the page, then hardened the system prompt to treat all retrieved content as reference data and never as instructions. The second fix is the one that matters, because the first only handles the instance I happened to find.
The lead-temperature picklist was deliberately left unrestricted and non-required. If the agent produces a score outside the expected set, a restricted picklist would reject the whole insert and the enquiry would vanish. Losing the scoring metadata is far cheaper than losing a patient trying to book an appointment. And when a CRM write fails, the agent says so rather than giving a false confirmation.
Captured against a locally seeded demo database. Every name, figure and identifier shown is invented.
Confirmed honest “I don’t know” responses out of scope, and no invented pricing figures — the most tempting hallucination in a healthcare setting.
One agent, one knowledge base; asking about different branches returns each branch’s own address, hours and phone number.
The two paths need different handling, so the agent asks before it assumes.
Contact details, preferred centre, timing and reason for visit on the Lead; the full conversation transcript and scoring rationale on an attached Task.
Sudden vision loss or ocular trauma routes to emergency care and bypasses the booking flow entirely.
No pricing estimates, no diagnosis, no medication guidance — constraints added beyond the brief because the domain raises the cost of a wrong answer.
What I would fix next, stated plainly.