Trust the boundaries, not the model.
Fatou Health uses AI for conversation and interpretation, but the model is not the source of authority. Tenant binding, server-side policy, explicit confirmation, integration rules, execution records, and human handoff define what can actually happen.
This page separates controls that are implemented in the platform from capabilities that still depend on a specific customer deployment. It is not a compliance certification.
What is enforced today
These are platform controls we can point to in the current code. Whether a particular integration or workflow is active still depends on the tenant's approved configuration.
Tenant-bound integrations
A scheduling configuration is bound to an approved tenant. The agent does not get a fallback calendar or permission to operate another practice's integration.
ImplementedServer-side policy gate
Consequential tools are evaluated against policy outside the language model. The model cannot grant itself authority by producing persuasive text.
ImplementedExplicit booking confirmation
A current server-stored appointment proposal must be explicitly confirmed before the booking action can run. Stale or changed proposals are not treated as confirmed.
ImplementedDuplicate protection
Booking execution uses a deterministic identity and atomic execution claim so repeated confirmation or retries do not blindly create another appointment.
ImplementedFail-closed uncertain booking
If the scheduling provider returns an uncertain result, Fatou Health does not automatically retry and risk a duplicate or tell the visitor the appointment succeeded without confirmation.
ImplementedExecution and event records
Consequential tool execution is persisted with structured records so outcomes and failures can be inspected rather than inferred from a chat transcript alone.
ImplementedPractice-specific Customer Brain
Tenant-scoped services and knowledge can be marked active or held for review. Unapproved pricing, insurance, eligibility, or clinical claims do not need to become agent facts.
ImplementedHuman escalation path
The agent can produce an escalation action for clinical, ambiguous, denied, or unsupported requests. The actual delivery destination and notification channel must be configured and tested for the deployment.
Deployment-specificScheduling provider connection
Scheduling is enabled only after the tenant, credentials, calendar, appointment type, timezone, and live availability mapping are verified for that practice.
Deployment-specificVoice, SMS, EHR, intake, referrals, follow-up
These are not universal switches in the current pilot. They are separate workflows or integrations that must be scoped, built, authorized, and tested before Fatou Health presents them as live.
Scoped separatelyHIPAA / PHI posture
Fatou Health does not make a blanket public HIPAA-compliant claim. Any production use involving protected health information requires the applicable technical, vendor, contractual, and BAA requirements to be established for that deployment first.
Deployment reviewRetention, export, and deletion
Customer-specific retention, export, termination, and deletion commitments belong in the applicable written agreement. They are not implied here as universal timeframes.
Contractual
Evidence, not assurances
Most AI receptionists ask you to trust them.
An agent that can book appointments can also book the wrong one. The useful question is not whether that ever happens — it is whether you can find out what happened, and show someone else.
Fatou Health records consequential tool execution separately from the conversation, including the policy and confirmation context used by the workflow.
Default deny
Anything with a real-world consequence is refused unless a rule explicitly permits it. There is no implicit allow to fall back on.
No booking without confirmation
The appointment cannot be written until the patient has confirmed the specific slot. The confirmation is part of the record, not an assumption.
Structured execution history
Consequential tool execution and related events are recorded with timestamps so outcomes and failures can be inspected without relying on the chat transcript alone.
Dry-run and replay support
The platform includes test and replay paths for evaluating decisions without intentionally performing the external side effect. Deployment-specific coverage still has to be tested.
- intent
- patient requested consult
- tool
- scheduler.createAppointment
- policy
- allow · priority 10
- confirmation
- received from caller
- executed
- Tue 09:00 · 15 min
- result
- booking created
Illustrative fields from the execution model; exact records depend on the deployed workflow.
Illustrative record — not a real patient or booking.
Configured Boundaries
Where the agent stops.
The agent is scoped, not just prompted. Consequential actions are constrained by server-side policy. Unsupported requests produce a handoff or escalation action; the actual notification destination must be configured and tested for the deployment.
Handles
- Scheduling appointments
- Provider availability lookup
- Appointment confirmation
- Questions answered from the practice knowledge base
- Configured human handoff
Escalates
- Clinical advice or diagnosis
- Symptom assessment
- Medication questions
- Ambiguous or borderline requests
- Actions outside configured rules
- Anything the policy engine does not explicitly permit
Press “Step through” to begin.
What the workflow should do when certainty disappears
Failure handling is part of the product. The safe behavior is to stop asserting success when the system cannot verify it.
Calendar or availability lookup fails
Do not invent a slot
A provider outage is different from an empty calendar. The receptionist should say it cannot verify availability and use the configured handoff path rather than fabricate a time.
Policy cannot authorize the action
Do not execute it
The default is not to infer permission from the conversation. If the required authority cannot be established, the consequential tool call stays blocked.
Booking request has an uncertain result
Do not blindly retry
A timeout after submission may mean the provider created the appointment even though Fatou Health did not receive a clean response. The execution stays claimed for reconciliation instead of automatically creating a second appointment.
The model is unsure or out of scope
Say so and hand off
Clinical advice, unsupported practice facts, and ambiguous requests should move to the configured human path. The model is not allowed to turn uncertainty into authority.
The questions practices actually ask
The objections worth taking seriously.
What happens when it does not know the answer?
It should say the information is not confirmed and use the configured handoff path rather than inventing a practice fact or clinical answer. The Customer Brain can also keep uncertain material in review instead of making it active knowledge.
Can it book something it should not have?
The booking path is constrained by tenant-bound configuration, server-side policy, a current verified appointment proposal, and explicit confirmation. Those controls reduce the chance that model language alone can authorize a booking; the workflow still has to be tested for each deployment.
What does it do with patient information?
Data handling depends on the deployed workflow. Tenant isolation and sensitive-data controls exist in the platform, but Fatou Health does not make a blanket public compliance claim. Protected health information should only be processed after the required technical, vendor, contractual, and BAA safeguards are established for that deployment.
Does it replace our front desk?
No. The current offer starts with one administrative workflow, such as website inquiries and scheduling. Staff remain responsible for clinical judgment, unsupported exceptions, and any work that has not been explicitly delegated to Fatou Health.
What if the scheduling system goes down?
Fatou Health should not turn an integration failure into fake availability or a fake booking. If availability cannot be verified, it does not invent a time. If a booking submission has an uncertain result, the system avoids blind automatic retries that could create duplicates.
What does it plug into?
Only the systems required for the approved workflow. For the current receptionist pilot, scheduling is the primary integration. Voice, SMS, EHR, intake, referral, and follow-up integrations are separate scope rather than assumed capabilities.
You stay in control
Default deny. You set the rules.
These switches are an illustrative policy model, not live account controls. In a real deployment, Fatou Health configures and tests the allowed actions with the practice before launch.
Can it book appointments?
May use the configured scheduling tool after required confirmation.
Can it use a connected system?
May use only the explicitly configured integration for this workflow.
Can it collect intake data?
May collect only the administrative fields approved for this workflow.
Can it follow up automatically?
May run the separately approved follow-up workflow.
Can it escalate to staff?
Creates the configured escalation or handoff action.
Proof before autonomy.
Fatou Health expands a workflow only after the practice can inspect the behavior, test the failure cases, approve the authority, and see evidence of the resulting actions. A polished conversation is not enough.