An agent that books into your official schedule and touches billing needs a way into your systems. It also needs a written limit on what it may do alone — tool by tool, with every run on the record.
Bookings go into the official schedule through the API — never into a parallel calendar. The agent gives no clinical advice and does not write to the patient chart.
There is no robot typing into your screens. The agent calls an endpoint, reads the response and decides what to do with it. What changes from hospital to hospital is which door is already open — and that is what the first technical call has to find out.
This is the preferred path, and the fastest to stand up. You register the endpoint, the authentication header and a plain-language description of what it does. That becomes a tool the agent owns, with a name of its own: api_get_schedule_availability, api_post_appointment.
Claim form, batch, remittance statement and receipt protocol follow TISS — the claims exchange standard mandated by ANS, Brazil's regulator for private health plans. The agent builds and reads what the standard defines, and the hospital keeps transmitting through the channel it already uses with each payer.
If the hospital already runs an integration bus, we use it as it is: HL7 v2 messages for admission and movement, FHIR resources for schedule, slots and demographics. We never ask you to replace your bus in order to take us on.
Some legacy systems expose nothing at all. Then a read replica comes in, with curated, parameterized queries: the agent picks from ready-made queries and fills in the parameters. It does not write the query, and writes never travel this path.
Tools published by an MCP server are enabled per agent, one at a time. Whatever the server offers and the manager did not switch on stays out of that agent's reach.
Automation that clicks around your screens, a spreadsheet exported by hand, a screenshot. If the information does not come out through a programmable path, it does not enter the conversation — and the agent tells the patient it doesn't know, instead of guessing.
That separation answers the question IT always asks first: “so you keep our data?”. The agent has two places to draw an answer from, and they do not mix.
Every tool handed to the agent carries the method and the path in its own name. Anyone reading a run log knows exactly which endpoint was called.
The agent does not invent endpoints. A tool the manager did not switch on does not exist in its universe.
Every tool arrives with a declared scope. Booking an appointment is a direct write — the patient is waiting for the slot, and asking someone for authorization makes no sense. Filing a denial appeal — a recurso de glosa — can require human approval. Changing a payer contract is enabled for nobody, not even on request.
Checking free slots, demographics, claim status, the content of a remittance statement. It changes nothing in your systems, and it is where every rollout starts — the agent spends days only reading before any write.
Book, reschedule, cancel and confirm in the official schedule. It happens inside the conversation, with the patient on the other side. If the call fails, no booking happened — and the patient hears that right away.
The agent audits the bill against the patient chart, assembles the document with the item, the missing evidence and the probable cause, and leaves it in the queue of whoever signs. Denial appeals and batch transmission usually sit here. Whoever approves has a name and a timestamp in the log.
Scope matrix — 24 tools enabled on this agent
| What the agent does | Call | Scope | Who approves | Tools |
|---|---|---|---|---|
| Check slots, demographics and claims | api_get_schedule_availability | Read | nobody — nothing changes | 14 |
| Book an appointment | api_post_appointment | Direct write | the agent itself, in the conversation | 3 |
| Reschedule and cancel | api_put_appointment · api_del_appointment | Direct write | the agent, inside each specialty's rule | 3 |
| File a denial appeal | api_post_denial_appeal | Write with approval | billing analyst | 2 |
| Transmit a batch to the payer | api_post_tiss_batch | Write with approval | billing coordination | 2 |
| Write to the patient chart | — | Not handed over | no path exists | 0 |
| Change a contract or price table | — | Not handed over | no path exists | 0 |
| Tools enabled — 14 read + 6 direct write + 4 write with approval | 24 | |||
A tool that is switched off is not blocked after the attempt: it does not exist in the agent's universe.
Integrations go down. Maintenance windows exist, certificates expire, the HIS hangs on Monday morning. What makes an agent trustworthy is not a perfect integration — it is how it behaves in the minute the call fails.
The platform treats an API failure as an explicit error, never as an empty answer. A response that does not confirm the write never becomes “all set, I booked it for you”. The agent knows the difference between I found no slot and I could not ask, and it says which one happened.
A queue of cards with a stated reason, a per-run log carrying the endpoint and the return code, and a patient who was told — instead of finding out at the unit door that the appointment never existed.
It is the same logic the platform applies to a document published by a Squad: an incomplete piece is refused by the server, never quietly “fixed”.
Three questions from the DPO, in the order they usually come: what travels, what is stored, and what shows up on a dashboard half a dozen people receive by email every morning.
| Data | What for | Where it lives | On the daily dashboard? |
|---|---|---|---|
| Name and phone number | identify who is speaking on the channel | the conversation and the CRM record in the platform | No |
| Health plan and member ID | check eligibility and assemble the claim | the hospital system — the agent reads it live and keeps no copy | No |
| Specialty and time slot | book, reschedule and confirm in the official schedule | the hospital HIS, written through the API | Aggregated, no names |
| Exam prep and required documents | answer the patient's administrative question | Knowledge Vault — content published by the hospital | Not applicable |
| Diagnosis, clinical notes and test results | not a purpose of the agent | does not travel in the standard setup | No |
| The aggregated daily dashboard adds up bookings, reschedules and cancellations — 10,400 scheduling operations in the example month — without a single line that identifies a patient. | |||
The hospital is the controller of its patients' data; Hal-AI acts as processor, handling what is needed to run the contracted service. Purpose, legal basis, access scope, subprocessing and responsibilities are agreed before any connection — not after the first conversation.
Health data is sensitive personal data under LGPD, Brazil's data protection law. That is why the standard agent setup reaches no patient chart, no clinical history and no test result: widening that scope is a specific project, written down, with a stated purpose.
The retention period for conversations and run logs is set with the hospital and applies across every channel. A request for access, correction or deletion reaches the hospital and is carried out by the platform within what the contract defines.
The number is activated through Meta's own authorization flow and runs on the official WhatsApp Business Cloud API — Hal-AI is a Meta Business Partner. The rules that come with it apply to everyone, and there is no shortcut:
The aggregated dashboard the board receives counts how many confirmations went out by template. It does not say to whom.
The daily dashboard identifies no patient. Whoever needs the name opens the conversation, and that access is logged.
Three questions have to be answerable months later, without depending on anyone's memory: what the agent queried, what it decided and what it wrote. Add to that who took the chat over, and when.
Every call with its timestamp, tool name, parameters and return code. That is what separates “the system was down” from “the agent never asked”.
The reasoning of the run stays in the log: how many cases were read, which ones made it into the action, which were left out and why. A decision with no written reason is not auditable.
Every write shows up by name: which endpoint, with which payload, with which confirmation. Whatever was refused for lack of permission shows up too — discarded, not hidden.
| # | Source | Queried | Wrote | Taken over by | Calls |
|---|---|---|---|---|---|
| 2841 | conversation · reschedule | api_get_schedule_availability | nothing — HIS down | Front desk · 07:14 | 2 |
| 2842 | conversation · booking | api_get_schedule_availability | api_post_appointment | — | 3 |
| 2843 | Squad · reconciliation | api_get_payer_statement | appeal in the approval queue | Billing · 09:02 | 9 |
| 2844 | conversation · question | knowledge_vault | nothing to write | — | 1 |
| 2845 | conversation · clinical topic | knowledge_vault | refused — out of scope | Nursing · 10:26 | 1 |
| Calls logged across these five runs — 2 + 3 + 9 + 1 + 1 | 16 | ||||
Run 2845 — the agent stopped where it should
When someone from the front desk, billing or nursing takes a card, the agent pauses in that chat — the two never speak at once. Who took it, when, and when they handed it back are stored alongside the conversation.
Curated queries instead of open database access, tools declared one by one, a closed recipient list checked twice before any email leaves, and refusal of an incomplete document. None of this was invented for healthcare — it is the product's default behavior.
The slow part of a project like this is rarely the AI. It is getting staging credentials, finding out who owns the scheduling rule for each specialty, and verifying the number with Meta. Start there.
The order of the rollout exists so the hospital watches the agent read before letting it write.
Query tools go in first, against the staging environment. The agent answers questions and checks slots without writing anything. This is when the gaps between what the documentation says and what the API actually returns come out.
Write tools are switched on with simulation active: the agent decides and logs what it would have done, and nothing reaches the system. Coordination reads the runs and fixes the scheduling rule nobody had written down.
The official number goes into production handling questions, exam prep, health plan coverage and directions. Booking requests go to the front desk. The hospital gets the service gain before taking on any write risk.
Real booking is released for a small set of specialties with simple rules and high volume. The rest stay read-only. This is where an honest before-and-after comparison comes from.
With service stable, in come statement reconciliation, denial appeals with approval, and the Squad that publishes the morning dashboard. The 28 specialties and the 14 payers arrive in waves, not all at once.
This list is worth more than any promise on the page above. It is what the technical team needs to be able to show the committee, in writing, before signing.
It does not assess symptoms, suggest a diagnosis, recommend treatment, comment on medication or interpret a test result. Clinical topics are handed to the human team with the history attached, and the takeover is logged.
That tool is never handed to the agent. It writes to the schedule and, when authorized, to billing — and only through the calls named in the scope matrix. Anything outside the matrix has no path.
It does not appeal without attached evidence, does not classify a root cause without recording which remittance statement it came from, and sends nothing to a payer without approval from whoever answers for billing.
There is no internal waiting list, no walk-in spreadsheet, no “bot queue”. Every scheduling operation is a call into the hospital's official system. If the call does not confirm, the operation did not happen — and that is what the patient hears.
Once 24 hours have passed since the patient's last message, only Meta-approved templates go out, and never to someone who registered an opt-out. The platform does not route around channel policy and does not fall back to an unofficial number.
This page names no security certification, because Hal-AI has none to show — and an invented badge on an IT page is the worst possible way to start a relationship. What exists is described here: scope declared per tool, curated queries instead of open database access, human approval where the write is sensitive, a trail per run and a logged takeover.
We are a Meta Business Partner and an AWS Partner, and we hold a patent filed with the USPTO for the memory and context framework — those are partnerships and intellectual property, not a security audit, and we will not present them as one. The technical detail of controls, responsibilities and retention periods goes into the contract, where it can be enforced.
No. When the path is a database, it is a read-only replica with curated, parameterized queries: the agent picks from ready-made queries and fills in the parameters only. It does not compose the query, does not create its own, and there is no write route along that path. Writes happen exclusively through an API call named in the scope matrix.
No. The order of preference is the REST API your HIS or ERP already exposes; HL7 v2 and FHIR come in when the hospital already maintains an integration bus, because reusing what exists is cheaper; and the read-only replica stays as the last resort, for legacy systems that publish nothing. No project starts by asking you to change your bus.
The failure is treated as an explicit error. The agent retries a fixed number of times; once they run out, it tells the patient the system is unavailable, announces the handoff, opens a card for the front desk with the history and writes the failure to the run trail, with timestamp, endpoint and return code. Under no circumstances does it confirm a booking the system did not confirm, or park the request on a list outside the HIS.
Not in the standard setup. The agent works with the schedule, basic demographics, health plan data and the administrative content published in the Knowledge Vault. Patient charts, clinical notes and test results are sensitive personal data under LGPD and do not travel. Widening that scope is a specific project, with purpose, legal basis, access scope and responsibilities defined in the contract before the first connection.
None that we can display, and we would rather say so than imply otherwise. Being a Meta Business Partner and an AWS Partner is a commercial and technical partnership; the patent filed with the USPTO is intellectual property covering the memory framework. None of that is a security audit. What we offer is verifiable in the product itself — scope per tool, curated queries, human approval on sensitive writes, a trail per run and a logged takeover — and can be detailed in the contract, with the hospital as data controller.
Through two independent paths, and the hospital controls both. On your side, by revoking the technical credential, which has its own scope and does not take other systems down. On the platform side, by switching the tool off in the agent's panel: on the next run it stops existing for the agent, with no need to rewrite its personality. There is also simulation mode, which suspends every write while keeping the record of what would have been done, and a button to stop a run in progress.
Tell us which HIS the hospital runs, what it exposes today and which specialties you would release first. We come back with the design: which tools go in, at what scope, what stays behind human approval and what does not go in at all.