AI agent workflows for Cooperative banks & credit societies

Build spec

2 agents — 1 intake structurer (runs once per grievance) + 1 response drafter (runs only for routine cases that reach drafting). SLA labelling, routing, acknowledgement and the officer's decision are workflow nodes. · Pattern: Multi-channel intake → structure → SpEL SLA label → route by severity → grounded draft → officer decides

System prompt (paste-ready)

(Intake structurer) Turn ONE member grievance into a structured case. You are given a transcript or message and any member context. Return strict JSON {category (DEPOSIT_WITHDRAWAL|LOAN_SERVICING|PASSBOOK_STATEMENT|STAFF_CONDUCT|CHARGES|OTHER), account_or_member_ref, summary (the member's own account, neutrally restated), requested_remedy, severity (ROUTINE|SERIOUS|SUSPECTED_FRAUD), language}. Restate only what the member said — do NOT decide whether the complaint is justified, do NOT assign blame to any named staff member, and do NOT promise any remedy, reversal, refund or timeline beyond the society's published acknowledgement turnaround. If details are missing, list them in missing[]; never fill them in.

Agent roles & model tiers

• Intake structurer (per grievance) — Economy tier with a configured fallback model — every call, message and forwarded counter complaint passes through it, so it is the volume step

  Structure one grievance into strict JSON: category, reference, neutral summary, requested remedy, severity, language. No validity judgement, no blame, no promises, no invented details.

• Response drafter (routine cases only) — Standard tier, fallback configured — must reason over bye-laws and the charges schedule and cite the exact clause, which is the one hard step here

  Draft a response for the grievance officer, grounded in the bye-laws, schedule of charges and redressal policy in Knowledge, citing the specific clause. Present it explicitly as a draft for approval; never state an outcome the policy does not support, and never commit the society to a remedy.

Guardrails

• No decision of any kind by the agent: it structures, evidences and drafts — every resolution, charge reversal, compensation or credit-related outcome (including anything touching a member's loan) is decided by the grievance officer at the Approval node, and no agent may approve, reject or re-price anything
• The intake agent never judges whether a complaint is justified and never blames a named employee; staff-conduct and suspected-fraud cases bypass automated drafting entirely and go straight to the officer
• The `grievance_sla_label` SpEL tool sets a routing label and a clock from the society's published policy — it does not decide the outcome, and it cannot shorten or waive a statutory turnaround
• The only thing sent without human review is the acknowledgement itself — reference number, category and the published turnaround; it promises no outcome
• Every draft response cites the bye-law or charges-schedule clause it relies on; an outcome not supported by documented policy is escalated rather than drafted
• Member contact stays within the permitted hour window and honours opt-out for anything other than the statutory acknowledgement and the case outcome; account and transaction details are pulled only for the member's own case

Cost strategy

Intake is the high-volume step and sits on the economy tier with a fallback model — structuring a transcript into a fixed schema is exactly the cheap-model case. The drafter is the hard step (bye-law reasoning, clause citation) and is the only standard-tier call, and it never runs for staff-conduct or fraud cases, which route straight to a human. The SLA labelling is free SpEL. On call intake, voice minutes rather than tokens dominate the bill — cap transcript length in a Code node before it reaches a model.

Output & delivery

A grievance arrives by Voice, WhatsApp, Email or web form → Sarvam transcribes it in the member's language → the cheap structurer produces a schema-valid case and severity → a Code node applies the society's `grievance_sla_label` SpEL tool → the Condition node routes serious and conduct cases straight to the grievance officer → an acknowledgement with case reference and turnaround goes out immediately as text and voice note → for routine cases the standard-tier drafter proposes a clause-cited response → the grievance officer decides and replies at the Approval node, and a Tool (MCP) node updates the case record.

Build spec

2 agents — 1 notice drafter (per member) + 1 document checker (per submitted image); both run inside Loop nodes. The due-date banding, the eligibility gate, the reminder cap and the officer's verification are workflow nodes. · Pattern: SpEL due-banding → eligibility gate → cheap per-member notice → cheap per-document check → capped follow-up → human verifies

System prompt (paste-ready)

(Notice drafter) Write ONE short KYC re-verification notice for a cooperative-society member. You are given {member_name, language, kyc_category, required_documents[], due_by, due_band, branch_name, whatsapp_number}. Write in the member's language, under 50 words, at a primary-school reading level. Say: that periodic KYC re-verification is due by {due_by}; the exact documents required (list them, no more and no fewer than required_documents); and the two ways to submit — photograph them to this WhatsApp number, or bring them to {branch_name}. Do NOT state or imply any consequence such as account freezing, blocking or closure. Do NOT ask the member to send an identity number as text, a password, an OTP or any banking credential. Return {text, tts_text}.

Agent roles & model tiers

• Notice drafter (per member) — Economy tier with a configured fallback model — one short templated notice per due member across a whole book, the dominant cost line

  Draft one short local-language KYC notice from supplied fields: what is due, exactly which documents, two ways to submit. No consequences, no credential requests, no invented requirements.

• Document checker (per image) — Economy tier with vision, fallback configured — runs once per submitted photo; images downscaled before the call

  Check one submitted image against the expected document type: right type, legible, unexpired, name matching the member record. Strict JSON, visible evidence only, at most the last 4 characters of any identity number, no identity-verification verdict.

Guardrails

• No decision by the agent: identity verification and the KYC status update are regulated human acts performed by the branch officer at the Approval node — the agent only reports that a document appears present, legible and unexpired, and it never approves, rejects, freezes or restricts an account, nor makes any credit judgement
• The `kyc_due_band` SpEL tool prioritises a worklist only — an OVERDUE label never restricts an account or triggers any action against the member
• The notice may never state or imply a consequence (freeze, block, closure) and may never ask for an identity number as text, an OTP, a password or any banking credential — credential-style requests are the exact shape of the fraud this sector suffers from
• Contact is capped: an eligibility gate excludes opted-out members and out-of-hours sends before drafting, and follow-ups stop at the policy-defined reminder count, after which the case becomes a named branch task rather than an automated chase
• Data minimisation: at most the last 4 characters of any identity number are extracted, images are retained under the tenant's policy, and member records are read only for the member being contacted
• The status write is idempotent per (member id, KYC cycle) and stamped with the approving officer, so a re-run cannot re-verify or duplicate a record

Cost strategy

Both agents are economy tier by design with fallback models configured, because both steps are high volume and low judgement — a templated notice and a present/legible/unexpired image check. That keeps a whole-book KYC cycle predictable: cost is (eligible members × one short draft) + (submitted images × one capped vision call), with the banding free in SpEL. No standard-tier call exists in the happy path; escalations go to a human, not to a bigger model.

Output & delivery

The due list arrives via Webhook → a Code node applies the society's `kyc_due_band` SpEL tool → the eligibility gate removes opted-out and out-of-window members → the Loop drafts one cheap local-language notice each → an Output node delivers it on WhatsApp with a voice note, falling back to SMS → returning photos are checked one by one by a cheap vision agent → the Condition node sends at most the policy-allowed follow-ups for outstanding items → the branch officer verifies identity and approves at the Approval node, and a Tool (MCP) node writes the KYC status back to core banking.

Build spec

2 agents — 1 notice renderer (runs once per member via the Loop node) + 1 RSVP/proxy recorder (runs per reply). The bye-law grounding, the entitlement-line formatting, both sign-offs and the delivery log are workflow nodes. · Pattern: Board-approved text → per-member language rendering + SpEL entitlement line → secretary approves the set → send + log → structured RSVP capture → secretary validates quorum

System prompt (paste-ready)

(Notice renderer) Render the board-approved AGM and dividend notice for ONE member. You are given {member_name, language, shares_held, dividend_amount, entitlement_line, meeting_datetime, venue, agenda_items[], approved_notice_text}. Reproduce every mandatory element of approved_notice_text — you may translate into the member's language and reformat for readability, but you may NOT add, remove, soften or reinterpret any statutory content, agenda item, date or venue. Insert entitlement_line EXACTLY as supplied; never compute, round, convert or estimate a figure. Do not add any statement about the society's performance, future dividends, or advice about what the member should do. Return {text, tts_text}.

Agent roles & model tiers

• Notice renderer (per member) — Economy tier with a configured fallback model — runs once for every member on the register, so it is the entire cost story; a bigger model here would only risk paraphrasing statutory language it must not touch

  Render the approved notice into one member's language with the supplied entitlement line inserted verbatim. No added or removed statutory content, no computed figures, no commentary or advice.

• RSVP / proxy recorder (per reply) — Economy tier, fallback configured — short structured extraction from a free-text or spoken reply

  Record one member reply as {attending (YES|NO|PROXY|UNCLEAR), proxy_name, notes}. Ask for the proxy's name if PROXY is declared without one. Never assess whether a proxy is eligible and never count or project quorum — that is the secretary's determination.

Guardrails

• No decision by the agent: the board declared the dividend and the secretary approves the notice text, the audience, the proxy validity and the quorum call at Approval nodes — the agent distributes and records only, makes no credit, financial or governance determination, and moves no money
• All figures — shareholding, dividend entitlement, dates, venue — are passed through verbatim from the register and the approved text; the model is forbidden from computing, rounding or restating any amount, and the `dividend_notice_line` SpEL tool only concatenates supplied fields, it performs no arithmetic on money
• Statutory content is preserved: the renderer may translate and reformat but may not add, drop or reinterpret a mandatory element, and the bye-law notice-period requirement is checked before distribution
• Per-member delivery (channel, timestamp, outcome) is logged for the statutory record, sends respect the permitted contact window, and the notice itself is a statutory communication — routine opt-outs apply to follow-ups, not to the notice
• Proxies are recorded as declared, never validated by the agent; eligibility under the bye-laws is determined by the secretary at the second Approval node

Cost strategy

This is a pure fan-out: one economy-tier render per member on the register, once a year, plus one cheap extraction per reply, with a fallback model so an outage cannot jeopardise a statutory notice window. Because the text is board-approved and the figures are inserted verbatim by a SpEL formatter, there is no reasoning step anywhere — a standard-tier model would add cost and add risk. Cache the translated boilerplate per language and vary only the member fields.

Output & delivery

The board's approved notice arrives via Webhook → the bye-law requirements are loaded from the scoped Knowledge collection → the Loop renders one per-member language version, with the `dividend_notice_line` SpEL tool formatting the register figures verbatim → the secretary approves the exact text and distribution list at the first Approval node → an Output node sends on WhatsApp, SMS or Email with a voice note and logs delivery per member → replies are recorded as structured RSVP/proxy data → the secretary validates proxy eligibility and calls quorum at the second Approval node.

Build spec

2 agents — 1 completeness/eligibility checker (per file) + 1 brief writer (per committee-ready file). The parallel gathering, the re-used document sub-workflow, the authority routing, the agenda gate and the committee decision are workflow nodes. · Pattern: Parallel read-only gather → re-used completeness sub-workflow → cheap eligibility check → SpEL authority routing → gate → neutral brief → committee decides

System prompt (paste-ready)

(Brief writer) Write a NEUTRAL one-page committee brief for a cooperative-society loan file. You are given the application, the completeness-check result, the member's standing and existing borrowings as read from the systems, the bureau summary, and the selected sanctioning authority. Structure it as: (1) what is applied for, verbatim; (2) member standing — membership date, share qualification, existing borrowings and repayment record, all quoted exactly as supplied; (3) documented eligibility position, citing the specific bye-law or product-policy clause from Knowledge; (4) open questions for the committee. You must NOT: recommend approval or rejection; state, score or imply creditworthiness; suggest an amount, tenor, interest rate, security or condition; compute a ratio or an amount not supplied to you; or characterise the member's character or intent. If a figure is missing, say it is missing.

Agent roles & model tiers

• Completeness + eligibility checker (per file) — Economy tier with a configured fallback model — a checklist comparison over structured inputs, run on every file including the ones that never get tabled

  Compare the gathered file against the product checklist and bye-law eligibility conditions in Knowledge. Return {present[], missing[], illegible[], eligibility_conditions_met[], eligibility_conditions_unmet[], bureau_report_age_days, clause_refs[]}. Report facts against documented rules only — no creditworthiness view, no recommendation, no waiver.

• Brief writer (per committee-ready file) — Standard tier, fallback configured — the one genuinely hard step: neutral synthesis with clause citation, and the only place a bigger model earns its cost

  Assemble the neutral one-page brief exactly as structured in the main prompt, quoting all figures verbatim and citing the bye-law clause. No recommendation, no score, no rate, no computed ratio, no character assessment.

Guardrails

• ABSOLUTE: no agent makes a credit decision. Nothing here approves, rejects, scores, rates, prices, sets a limit, security or tenor, or disburses — the brief explicitly carries no recommendation, and the sanctioning authority decides at the Approval node
• The `sanctioning_authority` SpEL tool routes a file to the correct decision-maker under the society's own authority matrix — it selects who decides, it never decides, and it can never lower the authority a board resolution requires
• Every figure — exposure, repayment record, share qualification, bureau data — is quoted verbatim from the source system; the model may not compute a ratio or an amount, and a missing figure is reported as missing rather than inferred
• The eligibility position is stated only against the bye-law or product-policy clause it cites; the model may not waive a condition, invent one, or characterise the member's intent or character
• All system access in the gathering step is read-only; the single write is the committee's recorded decision, keyed to the application id and stamped with the deciding authority, so the workflow can never sanction by side effect
• The member is informed of the committee's recorded outcome only — the message states a human decision and never explains it as the agent's, and it carries no advice, no rate and no commitment

Cost strategy

Only two model calls per file, and only one of them is standard tier: the completeness check is a checklist comparison and belongs on the economy tier, while the brief is the single hard step where neutral synthesis and clause citation justify the spend; both have fallback models so a provider outage cannot cost the committee a fortnight. Gathering runs in a Parallel node, which cuts wall-clock without adding tokens, and the authority routing is free SpEL. Files stopped by the completeness gate never reach the standard-tier brief at all, so incomplete files cost almost nothing.

Output & delivery

A Parallel node gathers the application, the member's standing and a current bureau summary read-only via Tool (MCP) nodes → a Sub-workflow node re-uses the document-completeness pre-check → the cheap checker verifies bye-law eligibility with clause references → a Code node applies the society's `sanctioning_authority` SpEL tool to route the file → the Condition node keeps incomplete files off the agenda and returns a specific gap list to the branch → the standard-tier writer produces a neutral, recommendation-free one-page brief → the named sanctioning authority decides at the Approval node → a Tool (MCP) node records the decision against the file and an Output node informs the member on WhatsApp in his own language.