How it works, from the case study to a running estate

The five steps

1. Case study. Read what happened at Winstanley & Son, the practice this was built inside, with real numbers rather than projections.
2. Free audit. A recall and response audit of your own practice: one prioritised finding, the cost of the problem quantified. Book one here.
3. Live demo. Your stack, your data where possible, one working fix shown rather than described.
4. Priced build. A scoped first install, quoted on the call once your systems and workflow are understood. See pricing.
5. Run. The estate goes live under monitoring, and stays there.

What a build involves

A build is not a template dropped onto your practice. It starts with a config pass specific to your practice: your IDs, pipelines, channels, staff and the facts your team already knows. The install itself follows a fixed runbook: preflight checks, importing every component inactive first, probing every credential live before anything touches a patient, running fixture tests against dummy records, then staged activation, one piece at a time, with monitoring live from day one rather than added afterwards.

At Winstanley & Son the estate runs on Make.com for orchestration, GoHighLevel for the CRM and patient messaging, Slack as the surface staff talk to it through, and Notion as the source of truth for the build itself, alongside the practice's own VisionPMS. Whatever practice management software you already run stays exactly where it is. The audit is where we confirm how your data reaches the operational layer without your clinical records ever being part of that route.

What "run" means

An agent that goes live and is then left alone is a liability, not a product. Every scenario in the Winstanley estate runs under a standing watchdog, a 30-minute automated read-only review of the channel, the scenario queues and known failure signatures. It reports problems. It does not touch anything itself.

The rule underneath the monitoring is fail-loud, never fail-quiet: every model-fed write carries a handler, a bad message quarantines rather than disappears, and there is no error budget one incident is allowed to spend silently. When something does go wrong, the system says so in plain terms rather than guessing. In the Winstanley build this discipline came from real incidents: an unhandled write error once took reception down for two and a half hours before handlers were added to every model-fed write; a 30-minute period where the system reported healthy while it was actually not receiving messages led directly to the watchdog being built. Both are now standing rules, not one-off fixes, and both travel into every new install.

The data boundary, stated plainly

Clients keep their existing practice management software. Clinical records, prescriptions, sight-test data, medical notes, stay inside it and never leave. Crewley runs the operational layer only: messages, bookings, orders, recalls and reporting. This is not a marketing line, it is how the Winstanley build itself is engineered, and it is described in full on the Honest AI page.

What travels between installs

Every fault the Winstanley estate has produced falls into one of a small number of classes, and only two of them would ever reach a customer's build: platform behaviour that gets encoded once into a standing rule, and missing guardrails that become standard equipment, handlers, the watchdog, quarantine, evidence-gated confirmations, on every install from the first day. The rest, hand-building mistakes, per-practice data quirks and process gaps, are solved by the audit and the runbook, not carried forward. Read what was actually found and fixed in the case study.