Agents (Early Access) · Use case
An agent that reads each new intake form the moment it lands, checks it's complete, looks the patient up without changing the record, and sends it to the right place — the clinical, scheduling, or billing queue — or holds it for a person when it can't safely tell who the patient is.
Beta note: This article covers the Keragon Agents early-access release. Behaviour, limits, and UI may change during the early access period; this page is updated on a rolling basis as we learn from early adopters.
| Who it's for | Front-desk and intake coordinators who sort new submissions by hand. |
| Apps it uses | An intake form (like Jotform), an EHR (like Healthie), and a secure-messaging / queue app (like Spruce Health). |
| What fires it | A new intake form submission. |
The scenario
Every new intake submission lands as the same by-hand loop for the front desk:
- Read the submission.
- Look the patient up in the EHR.
- Check consent and payment are filled in.
- Judge how urgent the reason for the visit is.
- Pick the right queue — clinical, scheduling, or billing.
- Tag the contact and pass it on.
Take a form from Darnell Okoye, who writes "chest pain for two days and getting worse." If that sits unread in the scheduling queue while someone books a routine slot, a time-sensitive symptom waits — and a returning patient can end up with a second chart because nobody checked first.
How it works
The agent runs once for each new submission and lands it in exactly one place. It only ever does one thing per submission — it never routes the same form to two queues.
Check it's complete first. Read consent and payment straight from the form. If either is missing, tag the contact and hold it for a person — no queue, no guessing.
Look the patient up, read-only. Search the EHR by last name and date of birth to tell new from returning. One clear match is a returning patient; no match is a new one. The agent never creates a record.
Decide where it goes. Read the reason for the visit, weigh how urgent it is, and pick one queue — clinical, scheduling, or billing. Anything urgent always goes to clinical.
Route to one queue. Apply the matching tag and post a short triage summary to that queue's conversation.
The adaptable agent
This is an example intake-routing agent — a ready-to-use starting point. Use it as-is to see how it works, then change the highlighted fields so it matches how your practice runs day to day.
It's made of two kinds of pieces:
- Fixed pieces hold the agent's judgement and the safety rules that keep it reliable. Leave these as they are.
-
Fillable pieces (shown in
[BRACKETS]) are the details you swap for your own intake form, EHR, queues, and tags.
Trigger
What starts the agent.
| Trigger | When it runs |
|---|---|
| New intake submission | Each time a patient submits the form. |
Instructions
Paste this into your agent. Change the highlighted [BRACKETED] fields to match your practice; leave the rest as it is.
Full instructions — paste into the agent
WHAT STARTS THIS AGENT
A patient submits the intake form in [INTAKE_FORM_APP]. The form gives you
the patient's first name, last name, date of birth, phone, email, reason for
visit, whether consent was signed (yes/no), whether payment is on file
(yes/no), and any free-text notes.
STEPS
1. Check it's complete first. Read the consent and payment fields from the
form. Treat the submission as incomplete if either one is missing, "no",
or blank. Decide this from the form fields alone.
2. Look the patient up in [EHR_APP] by last name and date of birth, to tell
new from returning — without creating any record. One clear match is a
returning patient. No match is a new patient (that's normal, not an error).
3. Now decide how to route it. Work out, in your own words:
• New or returning — use what the lookup found in step 2.
• Routine or urgent — mark it urgent when the reason mentions anything
time-sensitive (worsening, severe, pain, bleeding, shortness of breath,
chest, suicidal, or similar). Otherwise it's routine.
• Which queue — clinical, scheduling, or billing. Clinical when it's urgent
or about a symptom or care. Scheduling when the patient just needs an
appointment booked or moved. Billing when it's about payment, insurance,
or a balance.
• One short sentence saying why you chose that queue.
4. If the submission is incomplete, apply the [TAG_INCOMPLETE] contact tag and
post a note to [HOLD_CONVERSATION] saying exactly what's missing (consent,
payment, or both). Don't send it to clinical, scheduling, or billing. Stop
after this.
5. If the submission is complete, apply the contact tag for the queue you chose
([TAG_CLINICAL], [TAG_SCHEDULING], or [TAG_BILLING]) and post a short triage
summary to that queue's conversation: patient name, new or returning, how
urgent, and your one-sentence reason.
WHEN SOMETHING'S UNCLEAR
- More than one patient matches the lookup -> don't pick one and don't create
anything. Tag the contact [TAG_NEEDS_REVIEW] and post the submission plus
both possible matches to [HOLD_CONVERSATION] for a person, then stop. This
comes before urgency — never route a submission when you can't tell who the
patient is, even an urgent one.
- No patient matches -> treat them as new and carry on. Don't create a record.
- The reason for the visit is urgent -> always send it to the clinical queue,
whatever else is going on.
- The reason for the visit is blank -> treat it as routine and send it to
scheduling, and note in the summary that the reason was missing.
WHEN YOU'RE DONE
- The submission ended up in exactly one outcome: either held for review with a
note, or routed to one queue with a triage summary.
GUARDRAILS
- Try a failed step up to 3 times before stopping.
- Never create a patient record in any system.
- Never send the same submission to more than one queue.
- If you can't finish, post a short note to [HOLD_CONVERSATION] and stop.
- When you're finished, stop.Tools to select
Tools are the actions you let your agent take inside your apps.
| Role | What we used here | What it's for |
|---|---|---|
| Trigger | Intake form — New submission | Starts the agent each time a patient submits the form. |
| EHR / practice system | Healthie — Get patients | Looks the patient up by name and date of birth, read-only. |
| Secure messaging / queue | Spruce Health — Create contact tag, Create note, Send message | Applies the queue tag and posts the triage summary. |
Swap any of these for the equivalent tool your practice already uses.
The deciding step — new or returning, routine or urgent, which queue — is the agent's own thinking, not an app. Keragon agents have a built-in model, so there's nothing extra to connect for that.
What to fill in
These are the only things you change so the agent fits your practice. Everything else stays the same.
| Field | What to put | Example |
|---|---|---|
[INTAKE_FORM_APP] |
The intake form you use | Jotform |
[EHR_APP] |
The EHR or practice system you use | Healthie |
[TAG_CLINICAL] / [TAG_SCHEDULING] / [TAG_BILLING]
|
Your queue tag names | queue-clinical / queue-scheduling / queue-billing |
[TAG_INCOMPLETE] / [TAG_NEEDS_REVIEW]
|
Your hold tag names | intake-incomplete / intake-needs-review |
[HOLD_CONVERSATION] |
Where held submissions should land | intake-hold conversation |
What it produces
Every time it runs, the agent sorts each submission into one of three queues — clinical, scheduling, or billing — or holds it for a person, based on what's on the form and who the lookup finds:
| Outcome | What the form and lookup showed | What the agent did | Why |
|---|---|---|---|
| Sent to scheduling | Maria Delgado, "Annual physical, no issues"; consent and payment both yes; the lookup found one clear match, so she's a returning patient. | Tagged the contact queue-scheduling and posted a triage summary to the scheduling conversation. Created no record. |
A returning patient with a routine reason and no symptoms just needs an appointment, so it goes straight to scheduling. |
| Sent to clinical | Darnell Okoye, "Chest pain for two days and getting worse"; consent and payment both yes; the lookup found no match, so he's a new patient. | Tagged the contact queue-clinical and posted a triage summary to the clinical conversation. |
A worsening, time-sensitive symptom always goes to the clinical queue, whether the patient is new or returning. |
| Held for a person | "John Smith", severe migraine; the lookup returned two patients with the same name and date of birth. | Stopped, didn't route it anywhere, and posted the submission plus both possible matches to the hold conversation for a person to sort out. | Routing the wrong person could expose another patient's information, so the agent never guesses who someone is — even for an urgent reason — it asks a person. |
Scheduling summary (verbatim)
Triage summary (verbatim)
Maria Delgado — returning — routine — Returning patient requesting a routine annual physical with no symptoms reported.
Clinical summary (verbatim)
Triage summary (verbatim)
Darnell Okoye — new — urgent — Reason mentions worsening chest pain, a time-sensitive symptom, so this is routed to the clinical queue.
Try a variation
- "Add a records / referrals queue for submissions that aren't clinical, scheduling, or billing." (add a new queue value and a matching tag — keep it to one queue per submission)
- "When a submission is held as incomplete, also text the patient the consent and payment link." (add a message step to the incomplete branch)
- "Treat pediatric submissions as urgent by default so a clinician sees them first." (add a rule to the urgency step)
Make it yours
- Change the highlighted fields, not the rest. The completeness check, the read-only lookup, the one-queue routing, and the "ask a person when unsure" rule are what keep the agent safe — leave those as they are.
- Match your own apps. Swap Jotform, Healthie, and Spruce Health for the intake form, EHR, and secure-messaging app your practice already uses.
- Keep one destination per run. Never let a submission land in two queues. If you add a queue, add it as a new value and tag so exactly one still fires.
- Let it ask for help. When the agent can't tell who a patient is, it hands the submission to a person on purpose. Keep it that way — it reads and routes, it never diagnoses, and it never creates a patient record.
Helpful articles
- Create your first agent — the build flow from trigger to tools.
- Set up your agent's trigger — schedule vs event, and when to use each.
- Test your agent before publishing — how to read a run and confirm each step.
- Troubleshooting agents — what to do when a run loops, stalls, or a tool call fails.
- Inbound message & portal triage — the sibling use case: read an inbound message and route it to the right team.