AI agent workflows for Microfinance & SHG group lending

Build spec

2 agents — 1 reminder drafter (runs once per centre via the Loop node) + 1 attendance mapper (runs once per meeting transcript). Loop / Voice / Code / Approval are workflow nodes. · Pattern: Loop fan-out for reminders → voice capture → mapper → SpEL banding in a Code node → human confirms the register

System prompt (paste-ready)

(Reminder drafter) Write ONE short meeting reminder for a microfinance centre/SHG group. You are given {centre_name, meeting_place, meeting_time, group_language, items_to_bring[]}. Write in group_language, at a primary-school reading level, under 40 words. State ONLY: which centre, where, when, what to bring. You must NOT mention any amount due, arrears, penalty, interest, or any consequence of not attending — this is a meeting reminder, not a collection message. Do not add greetings that name individual members. Return {text, tts_text} where tts_text is the same message written to be read aloud naturally.

Agent roles & model tiers

• Reminder drafter (per centre) — Economy tier, with a fallback model configured for provider outages — runs once per centre every meeting day, so this routing choice dominates total cost

  Compose one short, factual, local-language meeting reminder from the given fields. No amounts, no arrears, no consequences, no invented details. Return text + a read-aloud variant.

• Attendance mapper (per meeting) — Standard tier, fallback configured — matching real names out of noisy field-recorded speech is the one step that needs the reasoning

  From a Sarvam transcript of the officer's spoken attendance, map each spoken name to a member id in the supplied centre roster. Return {present[], absent[], unmatched[]}. If a spoken name is ambiguous or not clearly on the roster, put it in unmatched with the raw text — never guess a member id, and never mark someone present who was not clearly named.

Guardrails

• No credit decision, ever: this workflow schedules and records attendance only — it never approves, rejects, re-prices or disburses anything, and any credit judgement belongs to a human at an Approval node
• Reminders are meeting notices, not collection messages — the drafter is forbidden from mentioning dues, arrears, penalties or consequences, and outbound sends respect the permitted contact-hour window, a per-group frequency cap and any opt-out already recorded
• The attendance register is written only after the field officer confirms it at the Approval node; unmatched names stay unmatched rather than being guessed onto a member id
• The `centre_attendance_band` SpEL tool classifies a meeting only — a CRITICAL band is a prompt for a human to look, never an action against a group or a member
• The register post is idempotent per (centre id, meeting date) so a re-run never duplicates or overwrites a confirmed register

Cost strategy

Cost is N centres × (economy-tier drafter, hard token cap) + one standard-tier mapper per meeting actually held. The drafter is the high-volume step and must stay on the economy tier — a 40-word factual reminder from structured fields needs no reasoning budget — and a fallback model is configured so a provider outage degrades the tier rather than stopping tomorrow's reminders. The mapper is the genuinely hard step (noisy speech, real names) and is the only place the standard tier is justified. The SpEL banding costs nothing at all: it is arithmetic in a Code node, not a model call. Run the reminder loop in Parallel batches for wall-clock speed without changing per-centre cost.

Output & delivery

Loop drafts one cheap local-language reminder per centre → an Output node delivers it on WhatsApp as text plus an ElevenLabs/Sarvam voice note inside the contact-hour window → after the meeting a Voice node captures spoken attendance → the mapper matches names to member ids → a Code node applies the society's `centre_attendance_band` SpEL tool → the field officer confirms at the Approval node → a Tool (MCP) node files the register in the LMS and lists silent centres for the branch manager the same day.

Build spec

2 agents — 1 variance explainer (runs once per unmatched line via the Loop node) + 1 reducer (runs once per branch-day). The matching arithmetic and the tolerance banding are Code nodes, not agents. · Pattern: Deterministic Code match + SpEL banding → map cheap agent over exceptions only → reduce → human approves each adjustment

System prompt (paste-ready)

(Variance explainer) Explain ONE unmatched collection line. You are given {centre_id, member_id, demand_amount, collected_amount, remitted_amount, variance_band, sheet_notes, recent_ledger_lines[]}. Return strict JSON {likely_cause (SHORT_COLLECTION|ADVANCE_PAID|WRONG_MEMBER_CREDITED|SHEET_ENTRY_ERROR|CASH_IN_TRANSIT|UNKNOWN), evidence, suggested_check, confidence (LOW|MED|HIGH)}. Do NOT compute or restate totals — the amounts given to you are authoritative and were computed in code. Do NOT propose a waiver, a write-off, an interest change or a ledger entry: your output is a hypothesis for a human to check. If the evidence does not support a cause, return UNKNOWN with confidence LOW rather than a plausible guess.

Agent roles & model tiers

• Variance explainer (per unmatched line) — Economy tier with a configured fallback model — runs once per exception, the volume step and therefore the cost lever

  Classify one unmatched line into schema-valid JSON with a likely cause, the evidence and a suggested human check. Never recompute money. Never propose a waiver or ledger entry. UNKNOWN beats a plausible guess.

• Reducer (once per branch-day) — Standard tier, fallback configured — one call a day, where synthesis and prioritisation actually earn the spend

  Aggregate the classified variances into an evening reconciliation summary: totals as supplied by the Code node, the centres driving the variance, the items needing a field check tomorrow, and anything repeating across days. Use only the supplied figures; never estimate or extrapolate.

Guardrails

• No credit decision and no money movement: the agents classify and summarise only — every adjustment, waiver, re-credit or write-off is approved individually by the branch manager at the Approval node before any ledger or banking system is touched
• All arithmetic is done in a Code node (plus the deterministic `variance_band` SpEL tool); the model is explicitly forbidden from computing or restating amounts, so no total in this workflow was ever produced by a language model
• The SpEL tool only bands a variance — an ESCALATE label routes a line to a human faster, it never authorises an adjustment, a waiver or a posting
• Schema validation on every explainer output — a malformed or low-confidence line is escalated as an open item, never auto-classified into an adjustment
• Posting is idempotent per (branch, collection date, line id) so a re-run cannot double-post an approved entry, and the full proposal-to-approval trail is retained for audit
• Nothing in this workflow contacts a borrower — variance follow-up is a field-officer task; any borrower contact happens through the early-warning recipe under its contact-hour, frequency and opt-out rules

Cost strategy

Only unmatched lines reach a model, so the bill scales with the exception rate, not with book size: matched lines cost zero tokens, and the SpEL banding costs nothing because it is an expression, not a call. The explainer runs at exception volume and must be economy tier with a hard cap and a fallback model; exactly one standard-tier reduce runs per branch-day and is where the reasoning budget goes. If exception volume spikes, batch the explainer through a Parallel node — same per-line cost, better wall-clock.

Output & delivery

A Code node matches demand vs collected vs remitted deterministically and applies the branch's `variance_band` SpEL tool → the Loop maps a cheap explainer over unmatched lines only → the reducer produces one branch-day reconciliation summary → the branch manager approves each proposed adjustment individually at the Approval node → a Tool (MCP) node posts only approved entries to the LMS/core banking system and send_email files the summary for audit, leaving everything else as a tracked open item.

Build spec

2 agents — 1 per-document checker (runs once per submitted photo via the Loop node) + 1 gap-list assembler (runs once per application). The checklist lives in a scoped Knowledge collection; the readiness label, the branch and the sign-off are workflow nodes. · Pattern: Loop map over documents → assemble gaps → SpEL readiness label → clarify once → human confirms visit-readiness

System prompt (paste-ready)

(Document checker) Inspect ONE submitted document image for a group-loan application. You are given the expected checklist entry {doc_type, must_be_signed, must_show_name, member_name} and the image. Return strict JSON {matches_expected_type (bool), legible (bool), signed_where_required (bool|null), name_on_document, name_matches (bool|null), issues[]}. Judge ONLY what is visible. Never transcribe or store a full identity number — report the last 4 characters at most. If the image is unclear, set legible=false with the reason; do not infer content you cannot read. You are checking that a document is present and readable — you are NOT assessing creditworthiness, income, or whether the loan should be granted.

Agent roles & model tiers

• Document checker (per document) — Economy tier with vision, fallback model configured — runs once per photo across every application, so it is the dominant cost line

  Verify one document image against its expected checklist entry: right type, legible, signed where required, name match. Strict JSON, visible evidence only, never a full identity number, no credit assessment.

• Gap-list assembler (per application) — Standard tier, fallback configured — reconciling thirty per-photo results against a product checklist is the one step worth the reasoning

  Compare the per-document results against the product's documented checklist for this group and produce a per-member gap list {member, missing[], illegible[], unsigned[], name_mismatch[]} plus one plain-language request per gap, written for a low-literacy reader. State completeness as a fact about documents only — never as a recommendation to lend.

Guardrails

• No credit decision, ever: this workflow verifies that documents are present, legible and signed — it never scores, rates, approves, rejects, prices or recommends a loan, and the appraisal decision is the credit officer's alone at the Approval node
• The `file_readiness_label` SpEL tool classifies paperwork completeness only — VISIT_READY means the folder is complete, never that the group is creditworthy
• Identity data minimisation: the checker reports at most the last 4 characters of any identity number, never a full number, and document images are handled under the tenant's retention policy
• Gaps are requested exactly once per round through a single consolidated message — no repeat chasing, contact-hour window respected, opt-out honoured, and the group leader can always ask for a human instead
• Completeness is asserted only against the checklist in Knowledge — the model may not invent a required document or waive one, and an unclear image is reported as unclear rather than inferred

Cost strategy

The per-document checker is the volume step (a ten-member group file is easily thirty photos), so it stays on an economy vision tier with a hard cap, a downscaled image and a fallback model — this single routing choice sets the bill. Exactly one standard-tier assembler runs per application, where reconciling many results against the product checklist actually needs reasoning. Oversized and duplicate images are rejected in a Code node before they reach a model, and the readiness label is free SpEL arithmetic.

Output & delivery

Documents arrive on WhatsApp or via the LOS Webhook → the Loop checks each photo cheaply against the scoped Knowledge checklist → the assembler builds a per-member gap list with plain-language asks → a Code node applies the lender's `file_readiness_label` SpEL tool → the Condition node either sends one consolidated local-language request (text plus voice note) or passes the file forward → the credit officer confirms visit-readiness at the Approval node, and a Tool (MCP) node attaches the completeness report to the application in the LOS.

Build spec

2 agents — 1 message drafter (runs once per eligible member via the Loop node) + 1 portfolio-briefing agent behind the Supervisor node (weekly). Signal computation and bucketing are a Code node; eligibility is a Condition node. · Pattern: Code signals + SpEL bucket → hard eligibility gate → cheap per-member drafting → supervisor approves the batch → send + log

System prompt (paste-ready)

(Message drafter) Write ONE short repayment reminder for a microfinance borrower. You are given {member_name, group_name, amount_due, due_date, arrears_bucket, language, officer_name, pay_link}. Write in the member's language, under 45 words, at a primary-school reading level. Include: what is due and when (exactly as supplied — never recompute), that they can pay by the link or at the centre meeting, and that they can call {officer_name} if there is a difficulty. You must NOT: threaten, mention legal action, recovery agents, seizure, the group's liability, credit-bureau reporting, or any consequence; imply urgency beyond stating the date; contact anyone other than the borrower; or name any other member. Do not mention the arrears_bucket to the member — it is for routing only. Do not offer a waiver, a reschedule, a settlement or any change of terms — if the member raises difficulty, the reply is that the field officer will speak to them. Return {text, tts_text}.

Agent roles & model tiers

• Message drafter (per eligible member) — Economy tier with a configured fallback model — the high-volume step; a 45-word factual reminder from supplied fields needs no reasoning budget

  Draft one short, factual, local-language reminder from the supplied fields. Never recompute an amount. No threats, no consequences, no third parties, no terms changes, no bucket labels shown to the member. Text plus a read-aloud variant.

• Portfolio-stress briefing (weekly, behind the Supervisor node) — Standard tier, fallback configured — one call a week, trend synthesis for a human reviewer

  From the week's computed signals, brief the branch manager on which centres and groups are drifting, what the signals were, and what a human should look at. Report patterns only; never name an action to take against an individual borrower and never propose a credit or recovery decision.

Guardrails

• No credit or recovery decision, ever: the agents draft and summarise only — rescheduling, waivers, settlements, write-offs, bureau reporting, provisioning and any escalation are human decisions taken outside this workflow, and the outreach batch itself is approved by the field supervisor at the Approval node before anything sends
• The `arrears_bucket` SpEL tool labels a file for routing and nothing else — it never marks an account NPA, never triggers an action against a borrower, and its output is never shown to the member
• Collections conduct is enforced structurally, not by prompt alone: a Condition node blocks contact outside the permitted hour window, above the per-borrower frequency cap, for opted-out members, and for anyone under a legal or dispute hold — the model never decides who may be contacted
• The drafter is prohibited from threats, legal or seizure language, consequence framing, third-party or co-member contact, and any mention of another member's dues; every sent message is logged with its timestamp, channel and approver for audit
• Amounts and dates are passed through verbatim from the LMS feed — the model may not compute, round or restate a figure, and a Razorpay UPI link is an option offered to the borrower, never an auto-debit or any movement of money by the workflow
• Opt-out is honoured immediately and permanently for outreach, and every message states how to reach the named field officer for a human conversation

Cost strategy

The drafter runs once per eligible member per cycle and is the whole cost story — keep it economy tier with a hard token cap and a fallback model, since the message is short, factual and template-shaped. Crucially, the eligibility Condition node and the free SpEL bucketing run BEFORE drafting, so ineligible and current members cost nothing at all. One standard-tier briefing per week behind the Supervisor node is the only premium spend; there is no per-borrower reasoning step anywhere in this recipe.

Output & delivery

A Code node computes stress signals deterministically and applies the lender's `arrears_bucket` SpEL tool → the eligibility gate removes anyone who may not be contacted → the Loop drafts one cheap local-language message per remaining member → the field supervisor approves the whole batch at the Approval node → an Output node sends WhatsApp text plus an ElevenLabs/Sarvam voice note with a Razorpay UPI link → every contact is logged back to the LMS, and a weekly Supervisor-node briefing gives the branch manager the portfolio pattern to act on.