Healthcare & Clinical

Designing an AI Front Desk That Never Makes a Clinical Decision On Its Own

A proposed administrative assistant for a telehealth mental health practice, architected so the AI understands requests while policy, eligibility, and workflow engines - not the language model - decide what is allowed to happen.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client operates a 100% telehealth mental health practice and needed more than another chatbot bolted onto the front desk. The requirement was a reliable assistant that automates routine administrative work, protects patient safety, and knows precisely when to hand a situation to staff rather than attempt it.

Pfactorial Technologies proposed an AI Virtual Front Desk & Administrative Assistant available across phone, SMS, email, website, and patient portal, organized around a simple design principle: the AI understands requests, but it never makes a business or clinical decision on its own. Every request passes through safety, identity, and policy validation before any action is taken or any practice system is accessed.

The proposed architecture separates conversation, business logic, data, and human oversight into independent layers, built entirely on Google Cloud within a single project, region, and tenant to keep security and compliance boundaries simple. Thirteen workflows are scoped across three modes - automate, assist, and escalate - with eight of the thirteen still requiring a person, by design, rather than the system being presented as autonomous.

Why this engagement is representative This engagement demonstrates Pfactorial's approach to AI systems in regulated, safety-critical settings: designing the language model to understand and converse while dedicated policy, workflow, and eligibility engines - not the model's judgment - decide what is actually allowed to happen.

THE CHALLENGE

A telehealth mental health practice cannot treat a front-desk assistant as a generic chatbot, and four requirements shaped the proposed design.

1. Clinical and crisis situations cannot be handled by AI judgment

No AI system can reliably recognize every possible expression of distress or replace clinical judgment, so crisis situations and clinical questions need to be escalated to a qualified clinician immediately rather than answered.

2. Administrative volume still needs to be automated safely

Initial enquiries, intake, scheduling, telehealth support, and reminders are high-volume, repetitive work that a front desk needs automated - but only within approved business rules, not through open-ended model judgment.

3. Eligibility for a slot depends on several conditions holding at once

A scheduling slot is only valid if the clinician is licensed where the client is physically located, sees that age group, accepts that plan or an approved self-pay rate, offers the needed service, and the time is actually free - all five checked together, not offered and corrected after the fact.

4. Every action needs to be auditable, not just plausible

A response that sounds right is not sufficient in a regulated healthcare context; every decision and action taken by the assistant needs to be traceable to the specific rule and data that produced it.

The real brief Not "another chatbot" but "an assistant that automates routine work reliably, protects patient safety, and knows exactly when to hand off to a person."

THE SOLUTION

Pfactorial proposed separating conversation, business logic, data, and human oversight into independent layers, so that every request passes through safety, identity, and policy validation before any action is taken or any practice system is accessed.

Figure 1 - The proposed request pipeline: understanding, policy and eligibility validation, action, and the human oversight layer every path can terminate in.

Architectural principles

The AI understands; it does not decide - the language model is scoped to understanding requests and generating responses, while all business and clinical decisions are made by separate policy, workflow, and eligibility engines outside the model.
Policy is checked twice, on different questions - the Policy Engine is consulted once to scope what the assistant may even discuss, and again to approve the concrete action - a check on the action itself, not on how the conversation happened to unfold.
Eligibility filters before offering, rather than correcting after - the Eligibility Engine filters the available slots down to only those that satisfy licensing, age group, payer, service, and availability together, so the assistant can never offer an ineligible slot under conversational pressure.
Every write is idempotent and reversible-by-design - the Workflow Engine is the only component that changes anything in the practice's systems, with an idempotency key on every write so a retry after a network timeout cannot double-book an appointment or double-charge a card.

CAPABILITIES DELIVERED

The proposed assistant's capabilities span automated, assisted, and escalated workflows across every channel the practice already uses.

CAPABILITY	WHAT IT DOES
Automated Administrative Workflows	Handles initial enquiries, patient intake, appointment scheduling, telehealth support, and attendance reminders using approved business rules, without staff involvement for the clear cases.
Assisted Workflows With Staff Review	Prepares insurance and EAP verification, payment and billing information, records and forms, and discharge coordination for staff to review and approve before anything is finalized.
Immediate Escalation for Crisis and Clinical Questions	Transfers crisis and safety situations, and any clinical question, directly to a staff member without the assistant attempting a response.
Grounded, Citation-Based Answers	Draws only on approved organizational knowledge for policy, fee schedule, and procedural questions, so staff can update source content without rebuilding the assistant.
Minimal Data Exposure by Design	Communication channels do not permanently store sensitive information, and patient records remain in the practice's existing systems rather than a duplicated database.
Full Auditability	Every offered slot, decision, and action is logged against the specific rule version that produced it, supporting complete after-the-fact review.

Figure 2 - Four checks, four outcomes: how a request moves from automated resolution to a fully staffed handoff.

Design note The proposal is explicit about what the system does not claim: it does not assert HIPAA compliance in itself (compliance attaches to how the client operates it under agreements and procedures), does not claim to catch every expression of crisis, and is not autonomous - eight of the thirteen scoped workflows require a person by design, not as a current limitation to be engineered away.

ENGINEERING FOR SCALE AND RELIABILITY

Several architectural decisions in the proposal are aimed specifically at keeping a language-model-driven assistant safe in a regulated healthcare setting.

Single-project, single-region, single-tenant on Google Cloud

the entire solution is proposed within one Google Cloud project, region, and tenant, keeping security, identity, logging, and compliance inside a single boundary rather than spanning multiple clouds or tenants.

Grounded retrieval instead of fine-tuning for knowledge

policy and fee-schedule content is served through a managed search and retrieval layer with citations, so a price change or policy update means editing source content rather than retraining a model with no way to check where an answer came from.

Workflow execution kept separate from conversation

a dedicated compute and workflow layer executes business logic, policy enforcement, and system integrations, so tool calls are validated before execution rather than the conversational model calling tools directly.

Every integration follows one common pattern

practice-system integrations use a shared architecture of documented APIs, secure authentication, automatic retries, and graceful fallback to staff-assisted processing - with screen scraping intentionally excluded for long-term reliability.

Model versions are pinned and regression-tested

language model versions are proposed to be pinned and validated through automated regression and safety testing before any deployment, rather than tracking the latest model version automatically.

A staged rollout with a go/no-go gate at every phase

the six-phase delivery plan is structured so each phase has defined exit criteria and a formal go/no-go decision, including a pilot with daily clinical review before wider production rollout.

DELIVERY APPROACH

The proposed implementation follows a structured six-phase delivery approach, with defined objectives, deliverables, and a go/no-go decision at every milestone.

1. Discovery (1-2 weeks, 90 hrs) - inventory every system and its API, map current-state workflows with the staff who run them, capture policies and escalation trees, and confirm a firm price for the remaining phases.

2. Solution Design (1-2 weeks, 130 hrs) - agree architecture, data flows, and the permission matrix; design conversation paths and refusal wording; build the 250+ scenario safety corpus with the client's clinicians; and write the test plan.

3. Build & Integration (3-6 weeks, 585 hrs) - configure the safety layer, policy, workflow, and eligibility engines, the knowledge library, channels, task queue, console, and reporting, with fortnightly demonstrations.

4. Testing & Validation (1-2 weeks, 165 hrs) - execute the full test program, log and remediate defects, and produce a signed acceptance report before any client-facing use.

5. Pilot Deployment (2-4 weeks, 140 hrs) - run a limited live cohort under close clinical review, tune thresholds, rehearse the manual fallback and data export, and run a disaster-recovery tabletop exercise.

6. Production Launch (100 hrs) - roll out channel by channel, deliver live and recorded staff training, hand over documentation and a configuration export, with 30 days of heightened support.

RESULTS AND IMPACT

Figure - Key outcomes from this engagement.

The proposed engagement gives the client a concrete, six-phase implementation plan totaling roughly 1,210 fixed-price, milestone-based hours, with a firm price for phases 2 through 6 confirmed only after Discovery validates real integration and workflow assumptions - rather than a single upfront estimate presented as certain.

The design's explicit assumptions section states plainly what the proposal does and does not claim: it does not assert its own HIPAA compliance, does not claim complete crisis detection, and is not autonomous by design, with eight of the thirteen scoped workflows requiring a person - giving the client an honest basis for evaluating risk before committing to build.

What it enabled commercially

If built as proposed, automating routine administrative work - answering common questions, completing intake, verifying insurance eligibility, and sending reminders - is intended to free the client's staff to spend more time supporting patients directly, while keeping every clinical decision and high-risk action under human control.

WHY PFACTORIAL

This engagement draws on Pfactorial's applied research and compliance capability: designing AI systems for regulated healthcare settings where the language model's role is bounded by explicit policy, eligibility, and workflow logic, rather than trusted to make the decision itself.

Figure - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with healthcare and telehealth practices evaluating whether an AI front-desk assistant can be built safely around clinical and regulatory constraints. If you are scoping a project where patient safety and auditability matter as much as automation, we are happy to give you an honest read on scope, cost, and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.