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
- 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.
- 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.
- 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.
- 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.
- 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'.
- 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
- Webhook (school ERP / portal — inbound)
- 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 agents — 1 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.