AI agent workflows for Personal finance & document admin

Build spec

1 agent — 1 extraction agent, run once per document via the Loop node. The urgency SpEL rule, the reminder Output and the payment Approval are workflow nodes.

System prompt (paste-ready)

Extract the obligation details from ONE document belonging to the user. Return strict JSON {doc_type (POLICY|BILL|WARRANTY|AGREEMENT|SUBSCRIPTION|OTHER), provider, reference, amount, currency, issue_date, due_date, expiry_date, renewal_terms, notes}. Read ONLY what is printed on the document — if a value is not present, return null and set needs_review=true. Never estimate an amount, never infer a due date from a billing cycle, never guess a provider from a logo you are unsure of. Do NOT extract, echo, store or repeat any card number, bank account number, password, OTP or government identity number that appears on the document — mask them and note that a masked value was present. You are filing and dating the document, not interpreting it: give no advice about whether to renew, switch, buy or claim.

Agent roles & model tiers

• Document extractor (per document) — Economy tier — bounded structured extraction that runs once per document and across the whole imported backlog, so this is where the cost lives; configure a fallback model so one failure doesn't strand a document unfiled

  Extract printed obligation fields into schema-valid JSON. null + needs_review for anything not printed. Mask any card, account, OTP or ID number rather than extracting it. No advice, no interpretation.

Guardrails

• NOT FINANCIAL ADVICE, stated plainly: the agent organises, reminds, summarises and compares the user's OWN documents. It does not give personalised investment advice and does not recommend financial products, insurers, funds or lenders — 'your policy expires on the 14th, here is the document' is in scope; 'you should switch to a better policy' is not
• SECURITY: card numbers, bank account numbers, passwords, OTPs and government ID numbers are never stored, echoed or typed — they are masked on extraction, and the workflow never enters them anywhere
• No financial form is ever auto-submitted and no payment is ever automatic: an Approval node holds every payment, a Razorpay UPI link is generated, and the human completes it themselves
• Dates and amounts come only from the printed document — nothing is estimated or inferred from a billing cycle; a missing field is null and flagged for review, because a wrong due date is worse than a missing one
• Extraction is idempotent per document hash, so re-forwarding the same bill can't create a duplicate obligation or a second reminder

Cost strategy

Extraction is the only model work and it runs once per document — economy tier with a hard per-call cap, which matters most on the initial backlog import where hundreds of old PDFs go through at once. The daily sweep costs nothing at all: `renewal_alert` is deterministic SpEL, so banding every tracked obligation every morning is arithmetic, not inference. Run the backlog import in Parallel batches for wall-clock speed at unchanged per-item cost.

Output & delivery

The Loop extracts each document into strict JSON → it is filed in Knowledge with its fields and its source PDF → the daily sweep runs `renewal_alert` over everything tracked → an Output node sends the ACT_NOW and PLAN reminders on WhatsApp or SMS with the document attached → any payment waits at the Approval node and is completed by the person through a Razorpay UPI link.

Build spec

2 agents — 1 tagging agent (per document, year-round) + 1 assembly agent (once, pre-filing). The missing-category gate and the hand-off Approval are workflow nodes.

System prompt (paste-ready)

(Tagger) Identify ONE document belonging to the user. Return strict JSON {category (SALARY|INTEREST|RENT|DONATION|INSURANCE|INVESTMENT|CAPITAL_GAINS|OTHER), issuer, financial_year, period_from, period_to, amount, reference, needs_review}. Determine the financial year from dates printed on the document only — if the document spans or ambiguously straddles two years, set needs_review=true rather than choosing. Never compute, estimate or total anything; you are categorising and dating, not calculating. Do NOT extract, store or echo any bank account number, card number, password, OTP or government identity number — mask them. Give no opinion on deductions, exemptions, regimes or tax position: that is the user's or their accountant's judgement, not yours.

Agent roles & model tiers

• Document tagger (per document, all year) — Economy tier — one short structured pass per document, spread across the year; with a fallback model so a certificate that arrives once annually is never lost to a transient failure

  Categorise and date one document into schema-valid JSON from printed dates only. Ambiguous year → needs_review. No totals, no tax opinions, sensitive numbers masked.

• Pack assembler (once, pre-filing) — Standard tier — a single call that reasons over the whole year's collection

  Assemble the year's categorised pack index and, for each expected category, state whether it is present, partial or missing, naming the issuer to request the missing document from. List only what is actually in the collection — never assume a document exists, never fill a gap with an estimate, and produce no tax computation, no deduction advice and no filing recommendation.

Guardrails

• NOT FINANCIAL OR TAX ADVICE, plainly: the agent organises, reminds, summarises and compares the user's OWN documents. It does not compute a tax position, does not advise on deductions, exemptions or regimes, and does not recommend financial products — the pack goes to the person or their accountant, who decide
• SECURITY: no bank account, card, password, OTP or government ID number is stored, echoed or typed; the workflow never logs into a tax portal and never submits a return or any other financial form
• Nothing is totalled or estimated by the agent — it categorises and dates printed documents; a straddling or ambiguous financial year is flagged for review rather than assigned
• The missing-documents list names only genuinely absent categories against the user's own expected set — a gap is never filled with an assumed or reconstructed document
• Hand-off to an accountant passes the Approval node, because sending a year of personal financial documents to a third party is the person's decision to make explicitly

Cost strategy

Tagging is one economy-tier call per document amortised across a whole year — negligible per event, and worth a hard cap plus a fallback model because these documents often arrive exactly once. The assembly pass is a single standard-tier call per year. The completeness check itself is deterministic `pack_ready` SpEL, so the pack's status can be recomputed daily in the run-up to the deadline for nothing.

Output & delivery

Each document is tagged and filed into the year's Knowledge pack as it arrives → the pre-filing Sub-workflow assembles the categorised index and runs `pack_ready` → the Condition node surfaces the missing categories → an Output node emails the pack plus the chase-list and sends WhatsApp reminders for outstanding items → the Approval node governs any hand-off to an accountant.

Build spec

1 agent — 1 statement-analysis agent, run per statement with a Loop over the lines. The three-way branch and the cancellation Approval are workflow nodes.

System prompt (paste-ready)

Analyse the user's OWN statement lines. Group them into recurring charges: return strict JSON {merchant, cadence (MONTHLY|QUARTERLY|ANNUAL|IRREGULAR), amount, currency, first_seen, last_seen, occurrences, matched_receipt (from Knowledge or null), status (RECOGNISED|OVERLAPPING|UNRECOGNISED)}. Use ONLY what is printed on the statement and what is in the user's own filed receipts — never guess what an unfamiliar merchant descriptor is, mark it UNRECOGNISED and let the user say. Never state or imply that a charge is fraudulent, wasteful or should be cancelled; present unrecognised and overlapping charges as questions for the user. Do NOT extract, store or echo any card number, bank account number, CVV, password or OTP — mask them. Give no advice about which services to keep, switch to or buy.

Agent roles & model tiers

• Statement analyser (per statement) — Economy tier — line-level grouping over a bounded document, once a month; a fallback model keeps a month from being skipped entirely on a transient failure

  Group the user's own statement lines into recurring charges with schema-valid JSON. UNRECOGNISED for anything not matched to a filed receipt. No judgements, no advice, sensitive numbers masked.

Guardrails

• NOT FINANCIAL ADVICE, plainly: the agent organises, reminds, summarises and compares the user's OWN statements and receipts. It never recommends which services to keep, cancel, switch to or buy, and it gives no personalised investment or product advice
• SECURITY: card numbers, account numbers, CVVs, passwords and OTPs are masked and never stored, echoed or typed; the workflow never logs into a provider or a bank and never auto-submits a cancellation or payment form
• An unfamiliar merchant descriptor is reported as UNRECOGNISED, not guessed and not labelled fraudulent — the person identifies it
• Cancellation emails are drafts held at the Approval node; the person sends them and cancels with the provider themselves
• Analysis is idempotent per statement, so re-forwarding a month can't double-count a subscription's occurrence history

Cost strategy

One economy-tier pass per statement per month, hard-capped — this is a low-volume, high-tedium job, which is exactly the profile where a cheap model earns its place. The three-way triage runs on deterministic `sub_flag` SpEL rather than a second model call, so month-over-month comparability costs nothing.

Output & delivery

The Loop walks every statement line → the agent groups them into named recurring charges matched against the person's own receipts → `sub_flag` bands each one deterministically → an Output node sends one plain monthly list on WhatsApp or Email → any cancellation draft waits at the Approval node for the person to send and action themselves.

Build spec

1 agent — 1 reader/explainer agent handling both the extraction and the spoken reply. Voice, the action branch, the family notification and the payment Approval are workflow nodes.

System prompt (paste-ready)

You are helping an elderly person understand ONE letter or bill they have received, speaking in their own language. Say what the document actually states: who sent it, what it concerns, the amount if any, the date if any, and what is being asked for. Use plain, unhurried language and offer to repeat. Read ONLY what is printed — if something is unclear or missing, say so rather than filling it in. NEVER give financial, insurance, medical, legal or tax advice, never suggest buying, switching, claiming or cancelling anything, and never say whether a charge is fair. NEVER ask for — and never repeat back, store or type — a card number, bank account number, password, OTP or government identity number; if the person starts to read one out, stop them and explain that it is not needed and should not be shared. You do not pay anything and you do not fill in any form: a family member reviews and completes anything that involves money.

Agent roles & model tiers

• Reader / explainer (per document) — Standard tier — the spoken turns need to be responsive, and the extraction is short; keep a fallback model configured, because the person on the other end is on the phone and a failed call has a real cost

  Extract and explain one letter in plain language in the person's own tongue. Printed facts only. No advice of any kind. Never solicit or repeat card numbers, passwords, OTPs or ID numbers; stop the caller if they begin to.

Guardrails

• NOT FINANCIAL ADVICE, plainly and out loud: the agent organises, reminds, summarises and compares the family's OWN documents. It gives no personalised investment advice, recommends no financial product, and offers no opinion on whether to renew, claim, switch or pay
• SECURITY, spoken as well as stored: the agent never asks for, repeats, stores or types a card number, bank account number, password, OTP or government ID number, and it actively interrupts and warns if the caller starts to read one out — elderly callers are a targeted group and this is the guardrail that matters most here
• No financial form is auto-submitted and no payment is automatic: an Approval node holds anything involving money, a Razorpay UPI link is generated, and a named family member completes it deliberately
• The summary states only what is printed on the document; anything unclear is reported as unclear rather than inferred, because a confidently wrong deadline is the specific harm this recipe exists to prevent
• The family notification carries the original photograph alongside the summary, so the person acting can always check the source document themselves

Cost strategy

One standard-tier agent per letter, with the Voice channel's minutes — not tokens — being the meaningful cost; cap the call length rather than downgrading the model, since comprehension for an elderly caller is the entire product. Sarvam handles the language layer, so no premium-tier model is needed to reach a non-English speaker, which is what makes running this for a parent affordable at all.

Output & delivery

The photographed letter is read into printed facts → a Voice node replies in the parent's own language through Sarvam and ElevenLabs, repeating on request → the Condition node escalates only letters with a date and an action → an Output node forwards the summary, deadline and photograph to the family member the same day → anything involving money waits at the Approval node and is completed by a person through a Razorpay UPI link.