Status: DRAFT v6 — 2026-08-21 — configuration pass complete & verified
(engine works: ingestion, retrieval, Sources, memory). Product principles
recorded (§7) and anchored to the canonical standard
AI Features — Justification.
Feature build pending the engineering ticket (Phase 0+1, diary flags).
Rename under consideration (suggested: "Attendance Risk Flags").
Next job: replicate the patient PWA for dental — research in progress,
new session.Data rule: dummy/synthetic data only in any testing or demo of this plan.
No patient-identifiable information. No secrets on this page.
The first everyday, front-desk use of the practice's own AI agent. The app
studies how patients have actually attended in the past and, quietly, every
night, works out which upcoming appointments are most at risk of being missed —
so the team can do something about it before it happens.
It comes from the "Automated Scheduling" idea in the
Hermes AI research page:
Smart appointment books analyze past attendance patterns to optimize the
schedule and predict no-shows.
The practice already records whether patients attend ("Did Not Attend" status
on every appointment) — so no-shows can be studied without any new data
entry, and without any patient-identifiable information leaving the
practice's own system.
The routine:
Who does what:
| Role | What they see / do |
|---|---|
| Reception | Flags in the diary + the confirm-call list. Makes the calls. No extra typing. |
| Practice manager | Controls everything from the Control Centre: switches the feature on, writes the instructions in the practice's own words, uploads the DNA/cancellation policy so the agent can answer policy questions too. |
| The agent | Proposes, never decides. Flags and advises — it never books, moves or cancels anything by itself. |
Now (the first step):
Later (advisory only — not planned for build yet):
This is the first real use of the sovereign agent engine delivered in
August 2026 — the Control Centre, per-practice knowledge base, memory and chat
that each practice already has inside its own isolated system. No new
infrastructure: the analysis uses data the app already records (attendance
status, appointment type, booking time).
Everything below runs on the live engine already deployed to each practice —
no code changes needed. The scheduling feature itself (risk flags,
smart_scheduling skill) will plug into this configuration once built; the
build is tracked separately with the engineering agent.
Before you start: log in to dental.veripath.co.uk (SSO). You need a
manager/admin role (DENTAL_ADMIN, DENTAL_PRACTICE_MANAGER, ADMIN or
SYSTEM_ADMIN) — other roles get 403 on the Control Centre. Open the Control
Centre from the Hermes AI nav link (or go straight to
/integrations/agents/control-centre/).
On the Model & Engine tab, click Test Connection. Expect a success
message next to the button (the practice's agent is already provisioned).
On the Core Instructions tab, paste the practice directive below and save:
You are the front-desk assistant for Hillside Dental Practice (dummy practice).
Your job is to help reception and the practice manager with everyday
administrative questions about appointments, attendance and cancellations.
Guidelines:
- Answer in plain, friendly English. Keep answers short and practical.
- Ground every answer in this practice's own documents (policies, pricing,
SOPs). When asked about attendance or cancellations, follow the DNA &
Cancellation Policy document.
- Never invent patient details, statistics or scores. If the answer is not in
the practice's documents, say so and suggest what the team could check.
- For scheduling and patient-contact decisions, always recommend that a staff
member confirms with the patient before anything is changed. You never book,
move or cancel appointments yourself.
- If asked about treatment or clinical matters, politely hand back to the
clinical team — you only handle administrative questions.
On the Knowledge Base tab, upload three documents. For each: pick the
category, choose the file, upload, then wait for the status to flip
Processing… → Ready.
DNA & Cancellation Policy content (copy into dna-cancellation-policy.md):
# DNA & Cancellation Policy (Dummy Practice — Hillside Dental)
> Dummy policy document for configuration testing. No real patient data.
## 1. Missed appointments (Did Not Attend — DNA)
- A patient who does not attend an appointment and does not cancel in advance
is recorded as DNA on their record.
- One DNA in the last 12 months: no action beyond the record.
- Two DNAs in the last 12 months: the patient is added to the confirmation-call
list before their next appointment.
- Three DNAs in the last 12 months: review with the practice manager; routine
appointments may require a deposit before booking.
## 2. Cancellations
- Patients should give at least 24 hours' notice to cancel or rebook.
- Cancellations with less than 24 hours' notice are recorded as late
cancellations.
- Emergency appointments: patients should call as soon as possible so the slot
can be offered to another patient.
## 3. What staff do
- Reception calls patients on the confirmation-call list to confirm or rebook.
- Confirmation calls are recorded in the patient record (dummy data only).
- If a patient cannot be reached, the appointment stays booked and is flagged
for a follow-up call the next working day.
## 4. Notes
- This policy applies to all appointment types.
- Private and NHS appointments follow the same rules.
- All figures in this document are dummy data for configuration testing.
On the Memory tab, switch Remember interactions ON. Leave Answering
Style at Balanced (the default).
Open the chat page (/integrations/agents/chat/), pick the practice's agent,
and ask "How much is a scale and polish?" → expect £45 from the pricing
document, with a Sources block under the answer.
This step exists only to verify the grounding pipeline works (retrieval +
Sources). Asking the agent trivia in a chat window is not how staff
should use the feature — see §7 for why this pattern is an anti-pattern for
everyday use. The real front-desk surface is the diary flags (§2), not chat.
Skills tab note: the existing skills (FP17 audit, X-ray matcher, emergency
triage, supply reorder) can be toggled in the Control Centre, but today they
only affect the surgery dictation path — no visible change in chat. The
smart_scheduling skill will appear here once the feature is built.
Tidy-up after testing: either keep the three documents as the practice's
working knowledge base (recommended) and clear memory, or delete the documents
and clear memory to return the tenant to a clean state. Whatever you choose,
tell the team which one so the tenant stays in a known state.
These principles apply the canonical standard:
AI Features — Justification.
Recorded 2026-08-21 after walking the configuration steps on the test tenant.
During the walkthrough (Step 5 above), the agent was asked in the chat UI
"How much is a scale and polish?" — it answered £45 from the pricing
document, with Sources. Technically the engine worked. Practically, this is
exactly the kind of thing we should not build:
Drafted 2026-08-21. Status DRAFT — configuration pass complete (engine
verified working); product principles recorded (§7 — chat is not an agent
surface; agents embed in the subject-task UI); implementation still pending
the engineering ticket.