Superintelligent Agents for Telehealth: Intake and Follow-Up

AI agents for telehealth can take over administrative work around video and phone visits: collecting intake information, offering appointment options within rules the clinic sets, and sending follow-up reminders that match an approved plan. They should not triage symptoms, interpret results, change medications or decide who needs urgent care, because those decisions belong to licensed clinicians. The practical design question is where that boundary sits and how the system proves the agent stays on the administrative side of it.

Key takeaways

• Give the agent administrative work only: intake fields, scheduling rules, reminders and document requests.
• Write the clinical boundary into enforced permissions and approved templates, not only into a prompt.
• Route every symptom, urgency or medication question to a licensed person with the original message attached.
• Limit the agent's tools to the actions it needs, and review those permissions on a fixed schedule.
• Judge the agent by how often staff must correct it and how often boundary cases reach the right person.

Where administrative work ends and clinical judgment begins

Telehealth operations carry a heavy administrative load. Someone must collect history forms, match a patient to the right visit type, confirm a time with a clinician licensed for the patient's location, and remind people to join a call or finish a pre-visit questionnaire. Most of this work is repetitive, rule-based and easy to verify, which makes it a sensible first place for an agent. The difficulty is that a single conversation can drift from administration into medicine within one message. A patient who writes that a new medication made them dizzy has given the agent a clinical fact, and a fluent reply can sound like advice even when it is only a polite acknowledgment.

For that reason, draw the boundary by the type of decision, not by the topic of the conversation. Use this guide when you define the agent's scope:

• Facts the patient already knows, such as name, date of birth, insurer member number, preferred language or time zone, may be collected and checked against the expected format.
• Rule-based choices, such as booking a visit type a clinician has already approved within available calendar time, may be made by the agent.
• Anything that interprets symptoms, severity, urgency, side effects or results goes to a licensed clinician. The agent says a clinician will review the message and does not suggest an answer.
• Messages with possible emergency language stop the normal flow, show the emergency instructions the clinic has approved, and notify staff immediately.

Write these rules into the agent's operating instructions and into its tool permissions. Instructions guide the model, but the model can weigh them differently when wording is unusual. Permissions are limits the system enforces.

Intake: collect facts, flag everything else

Intake is where an agent earns its place. Before a visit, a clinic typically needs identity details, consent forms, the reason for the visit in the patient's own words, references to prior visits and any documents the clinician has requested. The agent can run that conversation in the patient's language, check for missing fields and produce a structured summary for the clinician to read before the call. The summary should quote the patient's words where possible, separate what the patient confirmed from what was inferred, and leave a visible gap where information is missing instead of filling it with a guess.

The agent should not rank the patient's problem, recommend a visit length based on symptoms or write a clinical impression. If the clinic uses an urgency field, a clinician or a written clinic rule should set it, such as a rule that a patient who selected a same-day option is flagged for same-day review.

Illustrative scenario: a clinic offers video follow-ups after medication changes. A patient writes that they started the new dose three days ago and feel unsteady when they stand. The agent does not explain the side effect or suggest waiting. It records the patient's words exactly, marks the message as clinical, tells the patient that a clinician will review it, shows the approved instruction to contact emergency services if they feel faint or cannot stay standing, and places the conversation at the top of the clinician's queue. The agent's job ends at that handoff.

Clinics that run in-person consultations face similar questions about what gets recorded and what stays with the practitioner, as described in how a medical spa structures consultations and aftercare.

Scheduling with explicit rules, not guesses

Scheduling looks simple until the rules collide. A visit may require a clinician licensed for the patient's physical location, a provider may have restricted hours, certain visit types may need longer slots, and cancellation windows may differ by service. An agent that reads availability directly from the calendar and creates holds with a confirmation step removes a large share of back-and-forth. An agent that improvises rules will eventually book a slot that breaks one of them.

Write the scheduling rules as conditions the agent can check, and record who owns each rule inside the clinic. Give the agent permission to create holds, confirm bookings and reschedule within a defined window. Do not give it permission to waive a cancellation fee, override a provider's hours or change a visit type after a clinician has set it. Those are exceptions, and exceptions belong to staff.

When a patient asks for a time outside the rules, the agent should offer the nearest allowed options, explain briefly that exceptions are handled by the clinic team, and create a request for staff with the patient's constraints attached. This keeps the conversation moving without implying authority the agent does not have.

Follow-up reminders that stay inside the approved plan

Follow-up is where clinics lose value to inconsistency: a lab reminder that goes out late, a pre-visit questionnaire nobody chases, or a post-visit message that quietly changes the instructions. Reminders are useful because they are repetitive, but they become risky when the wording drifts. The safest pattern fixes the content in advance and lets the agent handle timing, delivery and tracking.

A workable sequence looks like this:

• Step 1: A clinician or clinic lead approves one message template for each visit type and each follow-up step, with fixed wording and fixed timing.
• Step 2: The agent sends only approved templates, filling in the patient's name, appointment time, portal link and required preparation items.
• Step 3: Any reply that mentions symptoms, side effects, worsening, medication questions or results moves to a clinician queue with the original text attached.
• Step 4: Unanswered reminders are retried a limited number of times, then logged and listed for staff review the same working day.
• Step 5: Every outgoing message records the template version, send time and delivery status, so a reviewer can see exactly what the patient received.

The last step matters most when something goes wrong. If a template contains an error, you need to know which patients received it, not only that a complaint arrived. In practice, this is observability for an agent: a readable record of what it did, when, and under which approved rule.

A reminder that cannot be traced to an approved template should not leave the system.

Permissions, records and untrusted input

An intake agent handles sensitive personal information, so its tools should be scoped to the job. It may need to read availability, create a hold, write an intake summary and send an approved message. It should not browse the full clinical record, export patient lists or edit prescriptions. Authorization should be checked on every action against the role the agent is acting under, not only when a session begins. The OWASP authorization guidance is a useful reference for the questions to ask: who is acting, on which resource, and under which rule.

Patient messages also need careful handling. A patient may paste text that looks like an instruction, such as a request to ignore clinic rules or to reveal internal notes. The agent should treat that text as content to be summarized, never as a command. The OWASP prompt injection prevention cheat sheet describes this class of risk, and your technical team should read it before the agent receives live traffic. Wording alone will not solve prompt injection, which is why enforced limits in tool permissions matter more than instructions.

How Be Human approaches telehealth intake and follow-up

Be Human designs these agents as managed infrastructure rather than as a chat widget. A first engagement defines one useful role, such as intake and scheduling for a single service line, and specifies the memory the agent may use, the tools it may call, the approval boundaries and a success criterion that staff can observe. Clinical content, templates and escalation rules are written and approved by the clinic's own clinicians and administrators. Ongoing operations can include monitoring, recurring evaluations against a fixed set of sample messages, integration maintenance, permission reviews and incident response when a template or tool behaves unexpectedly. The service is remote and available in English and Portuguese. Be Human does not supply clinical judgment, and privacy and licensing duties depend on where the clinic and its patients are located, so those questions belong with the clinic's own advisers.

Measuring whether the agent is working

Choose measures a clinic manager can read without technical training. Count how often staff correct an intake summary, how many scheduling requests end in a staff handoff, how many clinical-sounding messages reach a clinician queue within the agreed window, and how many reminders went out from a template that was not the approved version. Each figure shows where the boundary is leaking or where the rules are too tight. The NIST AI Risk Management Framework offers a shared vocabulary for mapping these risks and tracking them over time.

Run the same set of sample messages after every change to the agent, its templates or the underlying model. Include ordinary requests, ambiguous wording, messages with emergency language and attempts to push the agent beyond its scope. Recurring evaluations like this catch regressions before patients do. If you are not yet sure which of these tasks should go to an agent first, the free Be Human AI diagnostic can help you find the first task worth handing over.

Frequently asked questions

Can an AI agent answer patient questions about symptoms in a telehealth clinic? It should not interpret symptoms or recommend a course of action. A well-designed agent records the patient's description accurately, tells the patient that a clinician will review it, and shows the emergency instructions the clinic has approved when the language suggests urgency. The clinical answer always comes from a licensed person.

Do intake forms and reminder templates need clinician approval before they go live? Yes, and the approval should be recorded with a version. Clinicians or clinic leads should own the wording, timing and conditions for each template, and the agent should send only those approved versions. Any change creates a new version that goes through the same review.

What should happen when a patient writes something urgent in a message? The agent should stop the normal flow, display the emergency guidance the clinic has approved, and notify staff through the channel the clinic defines. The original message should be preserved so the responsible person can see exactly what was said. The agent should not continue a booking or reminder conversation until a person has reviewed the case.

Does an AI agent replace our scheduling software or electronic records? No. The agent works through the systems you already use, with permissions limited to the tasks it performs, such as reading availability and creating holds. It should not hold broad access to the full clinical record, and its actions should be logged so staff can review them.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.