AI agent workflows for Couples & shared life admin

Build spec

1 agent — 1 bill-reading agent. The already-paid dedupe and the payment approval are workflow nodes — deliberately not agent decisions. · Pattern: Extract → dedupe against the shared ledger → one shared message → Approval gate on every rupee

System prompt (paste-ready)

You read household bills for two people who share them. From ONE bill or biller notification, extract {biller, account_ref, amount, currency, due_date, period, source}. Use ONLY what the document states — never infer an amount, a due date or an account. If anything is unreadable, set it null, flag needs_original=true, and link the source. You never pay, never schedule a payment, and never describe a bill as settled: payment happens only after a person approves it. If this billing period already shows as paid in the ledger, return duplicate=true and stop.

Agent roles & model tiers

• Bill reader (per bill) — Economy tier — short structured extraction, runs on every biller mail

  Extract one bill into strict JSON with nulls for anything unclear and needs_original=true. Never infer an amount or a due date. Never treat a bill as paid, and stop immediately if the period is already settled in the ledger.

Guardrails

• Both partners know this workflow exists and opted into it. The same message goes to both, in a thread both are in — there is no version of this that reports to one person about the other.
• No surveillance whatsoever: it reads bills that were forwarded into the workflow on purpose. No bank-login scraping of a partner's personal accounts, no location tracking, no reading anyone's messages, no inference about anyone's spending habits or whereabouts.
• Shared by agreement — either partner can opt out and the workflow stops for them; if either stops it, shared bill reading ends, and neither is left with continued access to the other's forwarded mail.
• Money never moves without an explicit human approval showing payee, amount and due date. Autopay-by-agent is deliberately not offered.
• Idempotent per biller + billing period, so a resent notice or a forwarded duplicate can never trigger a second payment.
• Amounts are never inferred — an unreadable bill says 'check the original' and links it.

Cost strategy

Bills are frequent and short, so the reader belongs on the economy tier with a hard cap; there is no synthesis step to pay for. Configure a fallback model — a bill that still gets surfaced on a plainer model beats a missed due date. The expensive resource here is human attention, and the dedupe branch is what protects it.

Output & delivery

The bill arrives by Email or Webhook → an economy-tier agent extracts one ledger line → the Condition node stops it dead if the period is already paid → one identical message goes to the shared thread with whose turn it is → a Razorpay/UPI request is held at the Approval node until a person approves payee and amount → the ledger line closes for the period and both of you see the confirmation.

Build spec

1 agent — 1 normalising agent. The split is a deterministic user-defined SpEL formula in a Code node — deliberately not an LLM judgement — and settlement is a workflow approval. · Pattern: Normalise → deterministic user-authored split → Loop to net the period → Approval on settlement

System prompt (paste-ready)

You log shared expenses for two people. From a short message or a receipt, extract {payer, amount, currency, category, date, note}. If the amount, the payer or the category is unclear, ask ONE short question rather than guessing — never invent a figure. You do NOT compute the split: the couple's own formula does that. You do not comment on what was bought, whether it was worth it, or on anyone's spending. Log it and move on.

Agent roles & model tiers

• Expense normaliser (per entry) — Economy tier — very short extraction, highest-frequency step by a wide margin

  Turn one message or receipt into a strict JSON expense line. One clarifying question if unclear, never a guessed amount. No commentary of any kind about the purchase or the person.

Guardrails

• Both partners know the ledger exists, both write to it, and both see the same statement. There is no one-sided view and no report about one partner sent to the other.
• Only what a partner deliberately logs or forwards enters the ledger. No bank or card account is connected to read one person's spending, no location tracking, no reading messages, and no inference about where anyone was or what they bought beyond the line they typed.
• Shared by agreement: either partner can opt out and the workflow stops for them — logging ends, the statement stops, and neither retains a live feed of the other's spending.
• The split is deterministic and authored by the couple, so the system never appears to take a side. Changing it takes one line and requires both of them to agree, not a support ticket.
• No settlement without an explicit approval showing the exact net amount and direction. The workflow never transfers money between two people by itself.
• The agent never comments on what was bought or on anyone's spending habits. A ledger that editorialises becomes a weapon; this one records.

Cost strategy

Every logged expense is one very short economy-tier call, which is the whole recurring cost — the split itself is a SpEL formula and costs nothing, and the period roll-up is a Loop over data, not a reasoning pass. Set a fallback model so logging never fails silently; a dropped entry is what makes people abandon a shared ledger.

Output & delivery

Either partner logs a spend on WhatsApp, Telegram or by forwarded receipt → an economy-tier agent normalises it → a Code node applies the couple's own `split_share` SpEL formula → a Loop nets the period to a single number and direction → the same short statement posts to the shared thread → settling up is a Razorpay/UPI request held at the Approval node until a person approves the exact amount.

Build spec

2 agents — 1 collision-detection agent + 1 digest writer. The parallel calendar reads, the real-conflict gate and the write approval are workflow nodes. · Pattern: Parallel read of two consented calendars → detect real collisions only → one shared digest → Approval on any write

System prompt (paste-ready)

You look at the week ahead for two people who have each connected their own calendar and agreed to share it with the other. Identify ONLY genuine collisions: both unavailable when one of them needs to be present, one shared resource (a car, a room) committed twice, a joint commitment neither has prepared for, or a week with no shared time at all. Report what is on the calendars — never speculate about what an event means, who someone is meeting, or why. Do not flag a busy week as a problem. If nothing collides, say exactly that in one line.

Agent roles & model tiers

• Collision detector (once per week) — Standard tier — genuine reasoning over two schedules

  Compare the two shared schedules and return only real collisions with the reason each is a collision. Report entries as written; never infer the purpose of an event or who anyone is with. An uneventful week returns an empty list, and that is a valid, good answer.

• Digest writer (once per week) — Economy tier — short, warm formatting of an already-decided list

  Write a short shared digest: the collisions, the joint commitments, and anything needing a decision from both. Neutral and warm. Never characterise either person's week as too full or too empty, and never suggest what anyone should cancel.

Guardrails

• Both partners connected their own calendar themselves and both know the digest exists. Neither has access to the other's calendar through this workflow beyond what they each chose to share.
• No surveillance: free/busy and shared events only. No location tracking, no reading messages, no attendee-level snooping, and no inference about who anyone is meeting or why. The agent reports entries as written and speculates about nothing.
• Shared by agreement — either partner can disconnect their calendar at any time and the digest stops for both, immediately. There is no residual read.
• No calendar is written to and no message is sent on anyone's behalf without that person's own approval — declining an invitation is theirs to do, not their partner's and not the agent's.
• The digest is identical for both and posted to a shared thread — no private variant, no 'here is what your partner is doing this week' report.
• A quiet week returns nothing to flag, deliberately. A weekly message that manufactures a problem is a message you both stop reading.

Cost strategy

One standard-tier reasoning pass per week over two schedules, plus one economy-tier formatting call — a weekly cadence, so total cost is small and flat. Put the digest writer on an economy model with a fallback: the reasoning is where the value is, the wording is not.

Output & delivery

The Sunday Webhook opens the week → a Parallel node reads both consented calendars via Tool (MCP) nodes → a standard-tier agent finds only real collisions → the Condition node lets an uneventful week pass with one line → an economy-tier writer posts the same short digest to both partners → any calendar write or on-behalf message waits at the Approval node for the person whose commitment it is.

Build spec

2 agents — 1 per-item agent inside the Loop + 1 list writer. The payment gate and the document-share gate are separate workflow approvals, on purpose. · Pattern: Loop the tracked items → ground each in the couple's own documents → one shared list → two distinct Approval gates (money, and documents leaving the house)

System prompt (paste-ready)

You track renewals for a couple. For ONE item {type, provider, expires_on, last_amount, documents_needed}, state plainly what renewing requires: documents to gather, the expected amount, and the deadline. Ground every figure in the couple's own document in Knowledge and quote the source line — if the amount is not written down, say 'last known' or 'unknown', never estimate. You are not an adviser: never recommend a policy, an insurer, or a financial product, and never say whether cover is adequate. You surface the deadline and what it takes; the decision is theirs.

Agent roles & model tiers

• Renewal item agent (per item, inside the Loop) — Economy tier — short grounded extraction, runs once per tracked item per month

  One renewal, one short grounded summary. Quote the source line for every figure. 'Unknown' is a valid answer and is always better than an estimate. No product recommendations, ever.

• List writer (once per run) — Standard tier — ordering and clarity across items

  Order the due items by real urgency, group anything sharing a document, and write one short shared list with a clear owner per item. Neutral tone; never imply anyone let something slip.

Guardrails

• Both partners know the tracker exists, both can see every item, and both receive the same list. There is no version that reports one partner's paperwork to the other.
• No surveillance: only documents the couple deliberately added and portals they deliberately connected. No location tracking, no reading anyone's messages, no scraping of a partner's personal accounts.
• Shared by agreement — either partner can opt out and the tracker stops for them; items that are solely theirs leave the shared list, and the workflow stops entirely if either ends it.
• Two separate approval gates, deliberately not merged: money out (premium or fee, with payee and amount shown) and documents out (a specific, named share to a specific recipient, every time). Blanket 'always share my ID' is not offered.
• Figures are quoted from the couple's own documents with the source line; 'unknown' is an acceptable output and an estimate is not.
• The agent never recommends a policy, an insurer or any financial product, and never opines on whether cover is adequate — it surfaces the deadline and what renewing takes, and the decision stays with them.

Cost strategy

The per-item agent runs once per tracked item per run, so it sits on the economy tier with a hard cap — a household tracks perhaps a couple of dozen items, and the monthly cadence keeps the total flat. The one standard-tier list-writing call per run is where ordering and clarity are worth paying for. A fallback model on both keeps the look-ahead running, since a missed run is the one failure that costs real money.

Output & delivery

The monthly Webhook opens the look-ahead → a Loop walks each tracked item with the couple's own `renewal_lead_days` SpEL runway → an economy-tier agent grounds each in their own documents in Knowledge, quoting source lines → a standard-tier writer posts one ordered shared list with an owner per item → any premium is held at the payment Approval node, and any document leaving the household is held at a separate, per-share Approval node.