4 ready-to-build workflows

AI agent workflows for Families & caregiving

School notices, medicine reminders and a parent's hospital visit — held by a shared system everyone opted into, instead of by whoever happens to remember.

Each recipe below is expressed only in VegaDūta's real workflow building blocks — Trigger, Agent, Knowledge, Condition, Approval, Output, Tool (MCP), Voice, Device, Loop, Code and Parallel — so it maps 1:1 to something you can assemble in the Workflow designer. Consequential actions always pass a human Approval step.

1. School notices → one calm weekly digest the whole house can see

The school ERP emails a circular, the class WhatsApp group re-posts it with forty replies on top, and by evening the exam date has scrolled past the top of the screen. One parent ends up as the household's unpaid search function — re-reading the group at 11pm to work out whether tomorrow is a uniform day, a fee due date, or nothing at all.

Trigger: Email / Webhook (school ERP circular or portal notice)

How the workflow runs

  1. Trigger

    A notice lands. An Email trigger on the address the school actually writes to, or a Webhook from the school ERP/portal — the ERP has no first-party connector, so it arrives as an inbound Webhook and is read back via a Tool (MCP) node. Notices the family forwards in by WhatsApp land on the same trigger.

  2. Agent

    Pull out only the actionable facts. An Agent node extracts what a parent actually needs — date, what the child must bring or wear, whether money is due, the deadline — into structured fields, and marks anything it could not read clearly as uncertain rather than guessing.

  3. Condition

    Is anything due, or is this FYI?. A Condition node splits genuinely actionable items (a deadline, a fee, a thing to pack) from the general circulars, so the digest does not bury tomorrow's PT kit under a newsletter.

  4. Knowledge

    Check it against the household's own notes. A Knowledge node holds the family's own documents — the term calendar, the fee schedule, the bus timings PDF — so the digest reconciles the new notice with what the house already knew instead of contradicting it.

  5. Output

    One digest, one place, everyone. An Output node posts a single dated digest to the family's WhatsApp or Telegram group — same message, same time, to every adult who opted in. No one has to be the person who 'tells everyone'.

  6. Approval

    Fees need a human, always. An Approval node holds anything involving money. A fee notice becomes a Razorpay/UPI request a parent explicitly approves — the workflow never pays a school on its own initiative.

Channels & connectors

  • Email
  • Webhook (school ERP / portal — inbound)
  • WhatsApp
  • Telegram
  • Knowledge base
  • Approval / HITL
  • Razorpay (UPI)

Outcome

Every school notice turns into one dated, deduplicated digest that both parents (and any grandparent or helper who opted in) can see — with fee payments held for a human's explicit approval.

Why it helps

The mechanism is simple: the notice stops living in a scrolling chat and starts living in a dated list the whole household reads from. The mental load moves off one person's memory and onto a shared surface — nobody is being reminded by anybody, which is exactly the point.

Build spec

2 agents1 extractor (runs per notice) + 1 digest writer (runs once per digest). The completeness split and the fee approval are workflow nodes. · Pattern: Extract per notice → reconcile against the family's own Knowledge → one shared digest → Approval gate on money

System prompt (paste-ready)

You read school notices for a family. From ONE notice, extract {title, date, child (if named), action_required (BRING|WEAR|PAY|ATTEND|NONE), what, deadline, amount, currency, source}. Use ONLY what the notice says — never infer a date, a fee amount or which child it applies to. If a field is unreadable or ambiguous, set it to null and add it to uncertain[] so the digest can show 'check the original'. Never summarise a payment instruction as if it were confirmed; PAY items are drafts for a parent to approve.

Agent roles & model tiers

  • Notice extractor (per notice) Economy tier — short, structured extraction; runs on every circular so it dominates volume

    Extract one notice into strict JSON. Null for anything unclear, and list it in uncertain[]. Never invent a date or an amount. PAY items are proposals only.
  • Digest writer (once per digest) Standard tier — reasoning + tone

    Write one short, warm, dated digest from the validated items, reconciled against the family's own term calendar and fee schedule in Knowledge. Lead with what is due soonest. Flag contradictions between the notice and the household's notes rather than silently picking one. Keep it scannable — a parent reads this between two other things.

MCP connectors

  • School ERP / parent portal — inbound via Webhook, read back via a Tool (MCP) node (no first-party connector)
  • The family's shared calendar — via a Tool (MCP) node, so the digest can offer to add a dated item
  • WhatsApp / Telegram — the household's own group, as the single delivery surface

Built-in tools

  • knowledge_search (the family's own term calendar, fee schedule, bus timings, uniform policy)
  • http_request (read the ERP/portal notice; write an approved calendar entry)
  • user-defined tool `notice_window` (SpEL): input.actionRequired == 'PAY' ? 5 : (input.actionRequired == 'BRING' ? 1 : 0) — a tenant-authored SpEL expression over the tool's JSON input that returns how many days before the deadline this family wants to start being reminded. It is a data-transform/formula tool, sandboxed by construction (no method calls, no constructors, no bean or type references, and no loop in the grammar) — a formula, not a scripting engine. The benefit: a household that wants five days' notice on fees but only one on 'bring a water bottle' encodes that once, themselves, without a developer.

Guardrails

  • Everyone in the group knows this workflow exists and opted in — the digest is posted to the household's own shared group, visible to all of them, never sent to one parent about another.
  • This is a child's school correspondence read by that child's own guardians — ordinary, proportionate parental oversight of a minor, and nothing more. It reads school notices only: no location tracking, no reading anyone's messages, no monitoring of any adult in the house.
  • Shared by agreement: any adult can opt out and the digest stops going to them; if the family turns the workflow off, it stops entirely and the extracted items stay in their own Knowledge base.
  • Money never moves on the agent's say-so — a fee notice becomes an approval request a parent confirms, with the amount and payee shown from the original notice.
  • Anything the extractor could not read is shown as 'check the original' with a link, never quietly guessed.

Cost strategy

Volume sits on the extractor, so it belongs on the economy tier with a hard cap — a busy term is many short notices, not a few long ones. The single digest call per day (or per week) is where the standard tier earns its keep. Set an economy fallback model on the digest writer too: a slightly plainer digest that arrives is strictly better than none.

Output & delivery

Each notice is extracted to strict JSON → the Condition node separates actionable from FYI → Knowledge reconciles it with the family's own term calendar → one dated digest goes to the shared group on WhatsApp or Telegram → any fee is held at the Approval node and only then raised as a Razorpay/UPI request.

2. Medicine reminders for a parent, by voice, in their own language

An 80-year-old's medicine box is refilled by whoever visited last. One sibling thinks the BP tablets ran out on Tuesday, another is sure they bought a strip on Sunday. Nobody wants to keep phoning to ask 'did you take it?' — it feels like checking up on a grown adult, because it is — and the app the children installed has never once been opened.

Trigger: Scheduled Webhook (the dose times the family agreed with the parent)

How the workflow runs

  1. Trigger

    The agreed reminder time. A scheduled Webhook fires at the times the parent themselves agreed to — set once, with them, not for them.

  2. Voice

    A short call, in their language. A Voice node places a brief call, spoken via ElevenLabs with Sarvam handling the Indian language the parent actually speaks. This matters more than any of the app-shaped ideas: a warm thirty-second call in Kannada or Bengali reaches someone who will never open a dashboard.

  3. Condition

    They answer, or they don't. A Condition node branches on the call outcome. Answered and acknowledged: log it and stop — no follow-up, no nagging. No answer: retry once after the interval the family set, then escalate.

  4. Agent

    Log what the parent said, verbatim. An Agent node records the parent's own words ('took it', 'skipping today', 'the strip is finished') into a plain shared log. It records; it does not interpret their health.

  5. Output

    The siblings see one log, not four guesses. An Output node posts to the siblings' shared WhatsApp group — including the parent, who is in that group. Everyone sees the same line: dose acknowledged, or refill needed, or unreachable.

  6. Approval

    Refill is a human decision. 'Strip is finished' becomes a refill task with an Approval node, not an order. A person confirms the medicine, the quantity and the pharmacy — the agent never touches a prescription.

Channels & connectors

  • Webhook (scheduled)
  • Voice / Call
  • ElevenLabs (voice)
  • Sarvam (Indian languages)
  • WhatsApp
  • SMS / Twilio
  • Approval / HITL

Outcome

A gentle, predictable reminder call the parent agreed to, one shared log the siblings all read from, and refills that surface as a task before the strip actually runs out.

Why it helps

The mechanism is replacing four separate children phoning to ask the same question with one call the parent expects and one log everyone can see. It removes the 'checking up on you' texture from the relationship precisely because the parent set it up with them and can stop it with a sentence.

Build spec

2 agents1 voice-call agent + 1 logger/escalation agent. The retry branch, the refill approval and the escalation ladder are workflow nodes. · Pattern: Scheduled voice reminder → parent's own words logged → escalate to a human, never to a diagnosis

System prompt (paste-ready)

You place a short, warm reminder call to an older adult who has agreed to receive it. Speak in {{language}} via Sarvam, using their name and the dose label they themselves chose (e.g. 'the white BP tablet after breakfast'). Say the reminder, ask if they have taken it, thank them, and end the call — under forty seconds. You are NOT a clinician: never diagnose, never comment on a symptom, never advise on medication, dose, timing changes, or what to do if a dose was missed. If they mention pain, breathlessness, a fall, confusion, or anything that worries you, say kindly that you will let the family know right away, end the call, and raise the escalation flag. If they say they would rather not be called, thank them, log opt_out=true and stop — do not persuade.

Agent roles & model tiers

  • Voice reminder agent (per dose) Economy tier — short scripted turn, latency matters far more than reasoning depth

    One short reminder call in the parent's language. Warm, unhurried, under forty seconds. No medical opinion of any kind. Honour an opt-out immediately and without persuasion.
  • Logger / escalation agent (per outcome) Standard tier — judgement about when to involve a human

    Record the parent's own words verbatim into the shared log. Decide only whether to (a) log and stop, (b) flag a refill for approval, or (c) escalate to the on-duty family member. Never infer a clinical meaning from what was said. When in doubt, escalate to a human.

MCP connectors

  • The household's medicine list — the family's own document in Knowledge, never a drug database and never a prescribing source
  • Pharmacy or delivery service — via a Tool (MCP) node, and only after a human approves the refill
  • WhatsApp / SMS — the shared family group and the escalation ladder

Built-in tools

  • knowledge_search (the family's own written medicine list and dose labels, exactly as the doctor wrote them)
  • http_request (log the outcome; raise an approved refill task)
  • user-defined tool `escalate_after` (SpEL): input.missedCount >= 2 ? 'CALL_FAMILY' : 'RETRY_ONCE' — a tenant-authored SpEL formula over the tool's JSON input deciding when a missed dose stops being a retry and starts being a phone call to a person. Sandboxed by construction (no method calls, constructors, bean or type references, and no loop in the grammar): it transforms data, it does not run code. The benefit is that this family sets their own threshold — some want a call after one miss, some after three — without waiting on a developer.

Guardrails

  • The parent set this up with their family and can end it in one sentence — 'stop calling me' is honoured immediately, logged as an opt-out, and never argued with. Everyone in the shared group, including the parent, knows the workflow exists.
  • No surveillance of any kind: no location tracking, no reading their messages, no listening between calls, no inference about whether they are telling the truth. The only thing recorded is what they chose to say on a call they agreed to receive.
  • Shared by agreement — any sibling can leave the group and the workflow stops for them; if the parent withdraws consent, it stops for everyone.
  • MEDICAL SAFETY, absolute: the agent never diagnoses, never comments on symptoms, and never advises on medication, dosage or timing. It reads back the family's own written dose label, it reminds, it records, and it escalates to a human. Any hint of a symptom ends the call and pages a person.
  • A refill is a task for a human to approve, never an order the agent places — a person confirms medicine, quantity and pharmacy.
  • Escalation goes to a named family member on a rota, so 'someone should call Amma' is never everyone's job and therefore nobody's.

Cost strategy

Reminder calls are the recurring line item — many short, near-identical turns — so the voice agent sits on the economy tier with a strict per-call duration cap, and a fallback model configured so a reminder still goes out if the primary is unavailable. The logger runs once per outcome on the standard tier, which is the right place to spend, since it is the step that decides whether to wake a human.

Output & delivery

The scheduled Webhook fires → a Voice node calls in the parent's language via ElevenLabs + Sarvam → the Condition node branches on answered/unanswered → the logger writes the parent's own words to the shared log and posts one line to the family group → a finished strip becomes an Approval-gated refill task, and a missed-dose threshold set by the family's own SpEL formula pages a named person.

3. A parent's hospital visit, coordinated across three cities

Appa has a cardiology follow-up on the 14th. One sibling is in Pune, one in Dubai, one an hour away. The reports from the last visit are a photo in one person's camera roll, the appointment letter is in another's email, and the actual coordination happens as a nine-message phone-tag chain that ends with two people assuming the third booked the cab.

Trigger: Webhook / Email (appointment confirmed) or a family member adding the date

How the workflow runs

  1. Trigger

    The appointment exists. An Email trigger on the appointment letter, or a Webhook from the hospital's portal — no first-party connector, so it arrives inbound and is read back via a Tool (MCP) node. A sibling can also just add the date by message.

  2. Knowledge

    Everything about this visit, in one place. A Knowledge node holds what the family has chosen to put there: previous discharge summaries, the current medicine list, insurance details, the consultant's name. Their documents, in their tenant, shared only among the people who opted in.

  3. Agent

    Build the actual checklist. An Agent node produces the plain list this visit needs: what to carry, what time to leave, fasting instructions IF the letter states them, who is accompanying, and what last time's summary said to bring. It never adds a medical instruction the family's own documents do not contain.

  4. Parallel

    Split the jobs, explicitly. A Parallel node fans the tasks out — cab, reports, insurance pre-auth, accompanying person — each assigned to a named sibling who accepted it, so 'someone will do it' becomes a name next to a task.

  5. Output

    One thread, three cities. An Output node posts the checklist and assignments to the siblings' shared group on WhatsApp or Telegram, and a Voice node can read the parent their own part of it in their language — what time, who is coming, what to keep ready.

  6. Approval

    Sharing a report is a decision. An Approval node gates anything leaving the household: sending a discharge summary to a hospital, an insurer, or a second-opinion doctor needs a human to approve that specific share, every time.

Channels & connectors

  • Email
  • Webhook (hospital portal — inbound)
  • WhatsApp
  • Telegram
  • Voice / Call
  • Sarvam (Indian languages)
  • Knowledge base
  • Approval / HITL

Outcome

One shared thread per visit: a grounded checklist, named owners for each task, the parent told their own part by voice, and every external document share explicitly approved by a person.

Why it helps

The mechanism is turning diffuse responsibility into named responsibility. Phone tag exists because nothing is written down where all three siblings can see it at once; a single visit thread with an owner per task removes the ambiguity that caused the phone calls in the first place.

Build spec

2 agents1 checklist agent + 1 coordinator that tracks acceptance and nudges only the unclaimed tasks. The task fan-out and the document-share approval are workflow nodes. · Pattern: Ground in the family's own documents → Parallel fan-out with named owners → Approval gate on anything leaving the house

System prompt (paste-ready)

You help a family coordinate ONE hospital visit for their parent. From the appointment details and the family's own documents in Knowledge, produce a plain checklist {leave_by, carry[], accompanying, tasks[{task, suggested_owner}], questions_to_ask}. Include a preparation instruction (fasting, holding a medicine, carrying a prior scan) ONLY if the appointment letter or a family document explicitly states it — quote the source line. You are NOT a clinician: never diagnose, never interpret a report or a test result, never advise on medication or dosage, never suggest what the consultant might say. If the family asks a medical question, say plainly that this is for the doctor, and note it under questions_to_ask so they remember to ask it.

Agent roles & model tiers

  • Visit checklist agent (per visit) Standard tier — must reason over the family's own documents without adding to them

    Build the carry/leave-by/questions checklist strictly from the appointment letter and the family's own documents, quoting the source line for every preparation instruction. Zero medical interpretation. Anything not in the documents goes under questions_to_ask, never under instructions.
  • Coordinator (per follow-up round) Economy tier — short bookkeeping turns, runs repeatedly until tasks are claimed

    Track which tasks have a named owner who accepted. Nudge ONLY the unclaimed ones, once per round, in the shared group. Never chase an individual privately and never imply anyone is failing — state the open item, not the person.

MCP connectors

  • Hospital appointment portal — inbound via Webhook, read back via a Tool (MCP) node (no first-party connector)
  • The family's shared calendar — via a Tool (MCP) node, to place the visit and the leave-by time
  • Cab / travel booking — via a Tool (MCP) node, and only from an approved, human-owned task

Built-in tools

  • knowledge_search (the family's own discharge summaries, medicine list, insurance policy — their documents only)
  • http_request (read the appointment; write the calendar entry; record task acceptance)
  • user-defined tool `visit_turn` (SpEL): input.lastAccompaniedBy == 'PUNE' ? 'LOCAL' : 'PUNE' — a tenant-authored SpEL expression over the tool's JSON input that returns whose turn it is to accompany, based on whom the family logged last time. Sandboxed by construction: no method calls, no constructors, no bean or type references, and no loop in the grammar — a data-transform/formula tool, not a scripting engine. The benefit: siblings encode their OWN rotation once (strict alternation, or 'whoever is in the city', or a two-to-one split reflecting who lives nearest) and stop renegotiating it every single visit.

Guardrails

  • Every sibling — and the parent — knows this thread exists and opted into it. Nothing about the parent is discussed in a channel they are not part of, and no sibling is reported on to another.
  • No surveillance: no location tracking of anyone, no reading anyone's messages, no checking whether a claimed task was really done. The workflow tracks tasks people accepted, not people.
  • Shared by agreement: any sibling can opt out and the thread stops reaching them; if the parent withdraws consent, the whole workflow stops and their documents stay in their own Knowledge base.
  • MEDICAL SAFETY, absolute: the agent never diagnoses, never interprets a report or test result, and never advises on medication or dosage. Preparation instructions are quoted from the appointment letter or the family's own documents with the source line shown; everything else becomes a question to ask the doctor.
  • Every document leaving the household — to a hospital, an insurer, a second opinion — passes the Approval node as a specific, named share. Blanket 'always share' is deliberately not offered.
  • The coordinator nudges unclaimed TASKS in the shared group, never individuals in private — it must not become a tool for one sibling to pressure another.

Cost strategy

One standard-tier call per visit builds the checklist; that is the pass worth paying for, because it is grounded in documents and must not improvise. The coordinator's repeated nudge rounds are short bookkeeping and belong on the economy tier with a fallback model. Cost scales with visits, not with the number of siblings.

Output & delivery

The appointment arrives by Email or Webhook → Knowledge grounds the checklist in the family's own documents → a Parallel node assigns each task to a named sibling who accepted it → the shared group gets one thread and the parent gets a short Voice call in their language covering their own part → any external document share is held at the Approval node until a person approves that specific share.

4. The invisible list, made visible — household tasks on a rotation the family wrote

Nobody in this house is lazy. But the gas cylinder booking, the maid's monthly payment, the water-tank cleaning, the car service and the grandparents' Sunday call all live in one person's head, and that person is tired of being the one who says 'did anyone…'. Asking is itself the work — the mental load is the remembering, and it never shows up on anyone else's list.

Trigger: Scheduled Webhook (weekly) + Webhook/Email for anything with a real due date

How the workflow runs

  1. Trigger

    The week turns over. A scheduled Webhook opens the week's list. Dated items — a bill due date, a service reminder — arrive on their own inbound Email or Webhook and join the same list.

  2. Loop

    Walk the recurring list. A Loop node walks the household's recurring items — the ones that used to live in one person's memory — and works out which are due this week.

  3. Code

    Whose turn, by the family's own rule. A Code node calls the household's user-defined SpEL formula to compute the next owner from who did it last. The rotation is arithmetic the family wrote, not an opinion the agent formed — which is exactly why it doesn't cause arguments.

  4. Agent

    Write it as a list, not a nag. An Agent node writes the week's list in neutral language: the task, whose turn, and by when. It states, it does not chide, and it never compares two people's totals.

  5. Output

    Same message, everyone. An Output node posts the identical list to the household's shared WhatsApp or Telegram group. There is no private version and no 'reminder about you' sent to anyone else.

  6. Approval

    Money still needs a person. Anything payable — the cylinder, the maid's salary, a service bill — becomes an Approval-gated Razorpay/UPI request with amount and payee shown. The workflow never pays anything by itself.

Channels & connectors

  • Webhook (scheduled)
  • Email
  • WhatsApp
  • Telegram
  • Approval / HITL
  • Razorpay (UPI)
  • Tool (MCP → shared calendar)

Outcome

The household's recurring work becomes a visible weekly list with a turn already computed, posted identically to everyone — and every payment waits for a person to approve it.

Why it helps

The mechanism is externalising memory. When the list exists somewhere neutral, remembering stops being a job one person does silently and asking stops being an accusation — the rotation was agreed once, in a formula the family wrote themselves, so the system says whose turn it is and nobody has to.

Build spec

1 agent1 list-writing agent. The rotation is a deterministic user-defined formula in a Code node — deliberately not an LLM judgement — and the payment gate is a workflow node. · Pattern: Loop the recurring list → deterministic turn from the family's own SpEL formula → one neutral shared list → Approval on money

System prompt (paste-ready)

You write a household's weekly list. Given the due items and the owner already computed by the rotation formula, write a short, neutral list: task, whose turn, by when. Use plain, warm, adult language. Do NOT chide, do NOT mention what anyone did or did not do last week, do NOT compare people, and do NOT rank anyone. Never reassign a turn yourself — the formula owns that. If an item has no owner, say so as an open item and let the household decide.

Agent roles & model tiers

  • Weekly list writer (once per week) Economy tier — short, tone-sensitive formatting over data that is already decided

    Turn the computed list into a warm, neutral shared message. No comparisons, no guilt, no history. Open items are stated as open, not as anyone's failure.

MCP connectors

  • The household's shared calendar — via a Tool (MCP) node, to place dated items
  • Gas / utility / service portals — inbound via Webhook or read via a Tool (MCP) node (no first-party connectors)
  • WhatsApp / Telegram — the household's own group, the single delivery surface

Built-in tools

  • knowledge_search (the household's own list of recurring items, vendor numbers, service intervals)
  • http_request (read due dates; record completion; raise an approved payment request)
  • user-defined tool `chore_turn` (SpEL): input.lastDoneBy == 'A' ? 'B' : 'A' — the canonical example. A tenant-authored SpEL expression evaluated over the tool's JSON input, sandboxed by construction: no method calls, no constructors, no bean or type references, and no loop in the grammar. It is a data-transform/formula tool, not a scripting engine, which is precisely why it is safe to let a household author it directly. The benefit: this family encodes THEIR rotation — strict alternation, a two-to-one split because one person travels, or 'skip whoever is on night shift' — once, themselves, and the system stops being something one person has to run.

Guardrails

  • Everyone in the household knows the list exists and opted in — the same message goes to all of them, and there is no private variant about anyone.
  • No surveillance and no scorekeeping: no location tracking, no reading messages, no checking whether someone 'really' did a task, and no running tally of who did more. It tracks tasks, never people's performance.
  • Shared by agreement: anyone can opt out and the list stops reaching them, and their name stops entering the rotation; if the household stops the workflow, it stops completely.
  • The rotation is deterministic and family-authored — a SpEL formula, not a model's judgement — so no one can claim the system decided against them, and it can be changed by agreement in one line.
  • Every payment is Approval-gated with amount and payee shown, and the workflow never initiates money movement on its own.
  • The list never chides or compares. If it starts reading like pressure on one person, it has failed at its actual job.

Cost strategy

This is the cheapest recipe on the page and should stay that way: the turn calculation is a deterministic SpEL formula costing nothing, and one economy-tier call per week formats the message. Set a fallback model so the list still goes out; there is no reasoning here worth a premium tier.

Output & delivery

The weekly Webhook opens the list → a Loop node walks the recurring items → a Code node applies the household's own `chore_turn` SpEL formula to compute each owner → an economy-tier agent writes one neutral shared list → it posts identically to everyone on WhatsApp or Telegram → anything payable becomes an Approval-gated Razorpay/UPI request with amount and payee shown.

Related industries

Build one of these in minutes

The sandbox gives you a live agent workspace — no account, no card. Or head back to the full catalogue and compare patterns across every industry.

See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs