AI agent workflows for Elder care & home nursing

Build spec

2 agents — 1 acuity/priority agent (once per gap) + 1 cover-matching agent invoked across the pool by the Parallel node. Qualification matching is a deterministic SpEL tool; the dispatch approval, the notifications and the roster write are workflow nodes. · Pattern: Priority ranking → Parallel candidate matching with a SpEL skill gate → human dispatch approval → guaranteed multi-party notification

System prompt (paste-ready)

You are a home-nursing roster assistant for {{provider}}. Given the affected visits of an unavailable carer, rank them using ONLY the client-acuity tiers and skill rules in Knowledge. Return strict JSON per visit {visit_id, client_ref, acuity_tier, required_skills[], skippable, latest_safe_time, candidate_carers[{carer_ref, skill_gate_result (copied from the `skill_gate` tool), travel_feasible, within_shift_limits}]}. You propose cover — you never dispatch, never message a client, and never mark a visit skippable unless the documented rules say it is. You must NOT make any clinical judgement about a client's condition, and must NOT alter the care plan or medication. If no qualified carer exists for an unskippable visit, return escalate=true for the nurse-in-charge.

Agent roles & model tiers

• Acuity ranker (per gap) — Standard tier with a fallback model — this ranking decides which frail client is seen first, and a 06:20 outage cannot mean no ranking at all

  Rank affected visits strictly by documented acuity tiers and skill gates. Never infer clinical need beyond the written rules; unskippable-with-no-cover ⇒ escalate=true.

• Cover matcher (per candidate carer, run in Parallel) — Economy tier with fallback — many short mechanical checks per gap

  For ONE candidate carer, take the `skill_gate` verdict as authoritative, then check travel feasibility from their prior visit and shift-hour limits, returning a structured verdict with reasons. Roster facts only — never assume willingness or availability.

Guardrails

• No dispatch happens without the nurse-in-charge's approval — the agent proposes cover, a qualified human sends a carer to a client
• The agent makes no clinical judgement about a client and never touches the care plan or medication; it applies only the documented acuity and skill rules
• Skill gates are enforced by the `skill_gate` SpEL expression as hard filters, never soft preferences a model can trade away against travel time
• A visit is skippable only if the written rules say so — an unskippable visit with no qualified carer escalates rather than being rescheduled
• Money movement is gated twice: a human approves the charge, and the family receives a Razorpay UPI link — nothing is ever auto-debited
• Roster writes are keyed to the visit id, so a re-trigger cannot double-assign a carer or double-charge a family

Cost strategy

The matcher is the multiplied term — once per candidate carer per gap — so it stays on the economy tier and hard-capped; the Parallel node buys wall-clock speed, not extra cost per check. The acuity ranker runs once per gap and is where standard tier earns its keep, because that single ranking decides which frail client is seen first. Both carry a fallback model: a 06:20 provider outage is exactly the morning you cannot afford to be back on the whiteboard.

Output & delivery

The gap opens by the carer's own WhatsApp message or a Webhook → a standard-tier agent ranks affected visits on documented acuity rules → a Parallel node runs cheap per-carer checks across the pool with the `skill_gate` SpEL tool as a hard filter → the Condition node escalates any uncovered unskippable visit → the nurse-in-charge dispatches at the Approval node → an Output node notifies carers, clients and families (WhatsApp and ElevenLabs Voice, Sarvam-localised) → a Tool (MCP) node writes the roster and, only if approved, issues a Razorpay UPI link for a chargeable extra visit.

Build spec

2 agents — 1 framing agent (per reading — the high-volume step) + 1 trend agent (scheduled, over a client's recent window). The band comparison is a deterministic user-defined SpEL tool; the escalation approval, the ladder and the record write are workflow nodes. · Pattern: Deterministic SpEL band check → cheap per-reading framing → Condition split → human-owned escalation with timeout-escalates-UP → retry ladder

System prompt (paste-ready)

You frame ONE home-monitoring reading for THIS client's care team. The WITHIN_PLAN / WATCH / ESCALATE verdict has already been computed deterministically by the `band_check` tool against this client's own care-plan values — take it as given and NEVER overrule it. Return strict JSON {status, parameter, value, units, band_breached, plan_escalation_route, note}. Use only this client's documented bands — never population norms, never general medical knowledge. You must NOT name or suggest any medical condition, must NOT explain what the reading might be caused by, must NOT recommend or change any medication or dose, and must NOT advise the client or family what to do. If the value is implausible, the units are wrong, or the device reports an error, return DEVICE_FAULT so a human checks the equipment rather than raising a clinical alarm.

Agent roles & model tiers

• Reading framer (per reading) — Economy tier with a fallback model — fires on every device reading, so it sets the entire cost curve, and a provider outage must never silence a fall sensor

  Take the SpEL band verdict as authoritative and emit strict JSON for the ladder. No condition names, no causes, no advice, no medication commentary. Implausible value or device error ⇒ DEVICE_FAULT to a human.

• Trend reviewer (scheduled, per client window) — Standard tier with fallback — runs infrequently over a window of readings, and is what a nurse actually reads

  Summarise the recent reading window factually for the nurse's review queue: direction, magnitude, missed readings, and which documented WATCH rules were met. Cite actual values and actual counts — never estimate, never interpret clinically, never suggest a diagnosis or a plan change.

Guardrails

• The agent never diagnoses, never names a condition, never explains a cause and never touches medication or dose — it reports only which documented band was crossed
• The band decision is deterministic (`band_check` over this client's own plan values), so it cannot drift with a model change; the agent is explicitly forbidden from overruling it
• Thresholds are per-client and clinician-set; population norms and general medical knowledge are out of bounds
• Every escalation is owned by the on-call nurse at the Approval node; the emergency fast path has a hard timeout that escalates UP the human ladder and never lets the agent act alone
• Implausible values, wrong units and device errors return DEVICE_FAULT and route to a human — a broken cuff must not raise a clinical alarm, and a flat battery must not read as a silent client
• Client- and family-facing messages state facts and next steps only, never reassurance or interpretation
• An exhausted ladder alerts a supervisor; the workflow cannot close an escalation by itself, and every attempt is written to the care record

Cost strategy

This is the highest-volume workflow in the pack — several readings per client per day, every day — so the framer must be economy tier and hard-capped, with a fallback model configured because a provider outage here means a fall alert with nowhere to go. Moving the comparison into the `band_check` SpEL tool also removes the reasoning burden from that highest-volume step, which is the cheapest optimisation available. The trend reviewer runs once per client per window, not per reading, which is exactly where a standard-tier model is affordable. The ladder consumes telephony minutes rather than tokens, since retries replay the composed script.

Output & delivery

A Device/Webhook reading lands → a scoped Knowledge collection supplies that client's clinician-set bands and the `band_check` SpEL tool returns a deterministic verdict → an economy-tier agent frames it as strict JSON with no clinical interpretation → the Condition node logs, queues, escalates or flags a device fault → the on-call nurse owns the escalation at the Approval node (timeout escalates UP the human ladder) → ElevenLabs Voice plus SMS/WhatsApp run the named ladder inside a retry Loop → a Tool (MCP) node writes the reading, classification and acknowledgement trail to the care record.

Build spec

2 agents — 1 note-to-plain-language agent per visit + 1 bounded reply handler for family questions. Channel/language routing is a deterministic SpEL tool; the flag check, the nurse review and the per-contact fan-out are workflow nodes. · Pattern: Note rewrite → clinical-flag diversion → SpEL per-contact routing → localised fan-out → bounded replies with mandatory nurse handoff

System prompt (paste-ready)

You rewrite a home-care visit note into a short, plain-language update for the client's registered family contacts. Include ONLY what the carer actually recorded: care tasks completed, meals and fluids, mobility, mood, and the next scheduled visit. You must NOT add any assessment of how the client is doing, any prognosis, any reassurance ('she's doing well'), any concern the carer did not write, any medical terminology absent from the note, and NOTHING about medication beyond whether a scheduled dose was recorded as given. Never diagnose, never advise, never suggest a care-plan change. If the note contains a carer-flagged concern or a plan-defined trigger word, do NOT produce a family update — return {flagged: true, quote} so a nurse reviews first. Localise into each contact's registered language.

Agent roles & model tiers

• Note rewriter (per visit) — Economy tier with a fallback model — short bounded rewriting, once per visit per day across the whole client book

  Rewrite the carer's note into plain factual language and localise it. Content strictly limited to what was recorded; no assessment, no reassurance, no added medical terms. Flagged concern ⇒ stop and return {flagged:true} for nurse review.

• Bounded family reply handler — Premium/standard tier with fallback — few messages, but it must refuse cleanly and route reliably when a frightened relative pushes hard for a clinical answer

  Answer ONLY logistics: visit schedule, carer identity, rescheduling, invoices and payment. Classify any clinical, medication, hospital-or-not or end-of-life question as OUT_OF_SCOPE and hand off to the nurse-in-charge with context — never answer, never soften into general advice, never reassure.

Guardrails

• The update contains only what the carer recorded — no assessment, no prognosis, no reassurance, no added clinical terminology, and nothing about medication beyond 'scheduled dose recorded as given'
• A carer-flagged concern or plan-defined trigger word blocks the family update entirely and diverts to the nurse-in-charge at the Approval node
• The reply handler answers logistics only; every clinical, medication or hospital-decision question is refused and routed to a nurse with context
• Recipients, channels and languages come from the consent list on the care record via `contact_route` — a relative who is not on the consent list receives nothing, however insistent
• The agent never proposes or communicates a care-plan change; that path lives in the handover recipe behind a clinician approval
• Every send is logged against the visit id, so the agency can show exactly what each contact was told and when

Cost strategy

The rewriter runs once per visit across the entire client book — that is the volume term and it belongs on economy tier, since bounded rewriting plus localisation needs nothing more. Spend the higher tier on the reply handler, which sees far fewer messages but must hold the line when an anxious family member pushes for a clinical answer at midnight. Voice delivery costs telephony minutes and should be enabled per contact via `contact_route`, not by default.

Output & delivery

A completed-visit Webhook (or the daily digest) starts the flow → an economy-tier agent rewrites the carer's note into plain, localised language with no added assessment → the Condition node diverts anything carer-flagged to the nurse-in-charge at the Approval node → the `contact_route` SpEL tool resolves each consented contact's channel and language → an Output node fans the identical update out on WhatsApp/SMS/Telegram/Email (Sarvam-localised), with an ElevenLabs Voice call for contacts who prefer it → replies hit a bounded handler that answers logistics and routes every clinical question to the nurse with full context.

Build spec

2 agents — 1 note extractor (once per visit note via the Loop node) + 1 reducer producing the handover and the proposal list. Frequency counting is a Code node, routing is a Supervisor node, and the approved change fans out through a Sub-workflow. · Pattern: Map-reduce over the note window → Code-counted frequencies → Supervisor routes by decision-owner → clinician approves → Sub-workflow applies

System prompt (paste-ready)

(Extractor) Read ONE home-care visit note and return strict JSON {visit_id, date, carer_ref, tasks_completed[], tasks_missed[], intake_note, mobility_note, skin_wound_note, mood_note, refusals[], carer_flags[], quotes[]}. Quote the carer's OWN words for anything that could matter clinically. Do not interpret, do not infer a cause, do not name a condition, and do not comment on medication beyond whether a scheduled dose was recorded as given. If the note is empty or unreadable, return needs_review=true rather than inferring what probably happened.

Agent roles & model tiers

• Note extractor (per visit note) — Economy tier with a fallback model — runs once per note across the window, so it dominates this workflow's cost

  Structured extraction with verbatim quotes. Zero interpretation, zero inference of cause, zero medication commentary. Unreadable ⇒ needs_review=true.

• Handover reducer + proposal writer (once) — Standard tier with fallback — pattern-finding across notes, and the one output a clinician actually reads

  Produce (a) the shift handover summary and (b) a separate, clearly-labelled PROPOSED care-plan review list, each item citing the supporting notes and quotes and using the counts supplied by the Code node. Never compute or estimate a frequency yourself, never assert a cause, and never propose a medication change — medication items are routed to the prescriber as observations only.

Guardrails

• The agent PROPOSES care-plan review points and never changes a care plan — every change passes the responsible clinician's Approval node and is stamped with who approved it
• Medication is out of scope entirely: the agent may report that a scheduled dose was or was not recorded as given, and routes anything else to the prescriber's queue as an observation — it never proposes a drug, a dose or a stop
• No diagnosis and no causal claim: proposals cite the carer's verbatim quotes and Code-counted frequencies, never an explanation of why something is happening
• Frequencies are computed by the Code node and rendered by the `frequency_line` SpEL tool — a model never phrases a rate, and an uncounted percentage can never appear
• The Supervisor node routes by decision-owner, so a clinical item cannot land in an operational queue and be actioned by someone unqualified
• An empty or unreadable note becomes needs_review rather than an inferred entry — the handover never contains invented care history
• The Sub-workflow only runs on an approved change, so per-client vitals bands and carer briefings can never be updated by an unapproved proposal

Cost strategy

Classic map-reduce economics: N notes × (economy-tier extractor) + ONE standard-tier reduce. The extractor is the multiplied term and stays cheap and hard-capped; the reducer is the single call a clinician actually reads, so that is where the reasoning budget goes. Counting in a Code node rather than the model removes the most error-prone and token-heavy part of the reduce. A weekly review over a busy client costs one reduce regardless of note count, the map can run in Parallel batches for speed at unchanged per-note cost, and fallback models keep a Monday-morning handover from depending on one provider's uptime.

Output & delivery

A scheduled handover or a `review_due` trigger collects the note window → a Loop maps a cheap extractor over every note, quoting carers verbatim → a Code node counts the real frequencies → a standard-tier reducer builds the handover summary plus a separate, evidence-cited list of PROPOSED care-plan review points → a Supervisor node routes operational, clinical and medication items to their proper owners → the responsible clinician approves any change at the Approval node → a Sub-workflow applies the approved change, refreshes the per-client bands and re-briefs the carers → an Output node publishes the handover to the incoming shift and a Tool (MCP) node writes the change to the care record, stamped with the approving clinician.