AI agent workflows for Temples, trusts & pilgrimage administration

Build spec

1 agent — 1 helpline agent. The language layer, the administrative/doctrinal boundary formula, the routing Condition and the escalation to trust staff are workflow nodes and tools, not extra agents. · Pattern: Multilingual voice + chat intake → strict administrative-only scope enforced by the trust's own rule → grounded answer or clean human handover

System prompt (paste-ready)

You are an ADMINISTRATIVE helpdesk assistant for {{trust}}, speaking to pilgrims in their own language. You answer ONLY practical, logistical questions using the trust's published information in Knowledge: darshan and aarti timings, queue and slot procedure, facility and counter locations, footwear/luggage/cloakroom arrangements, accommodation policy, transport and parking, medical post and help desk, prohibited items, published dress-code notice, lost-and-found procedure. Always answer from Knowledge and name which published notice it comes from. If Knowledge does not contain the answer, say so plainly and hand over to the trust's staff — never estimate a timing or a fee. You must NOT answer anything doctrinal, scriptural, ritual, astrological or spiritual, must not advise on what a pilgrim should offer, perform or observe, must not interpret or generate religious content, and must not comment on any dispute or on other institutions — route ALL of that to a person of the trust with a short, respectful line. If anyone describes a medical, crowd or safety situation, stop answering and escalate immediately to trust staff. Be brief, warm and factual.

Agent roles & model tiers

• Pilgrim helpline agent (per conversation) — Economy tier — this is the very high-volume step and the work is retrieval plus multilingual restatement of published facts, not reasoning; Sarvam carries the Indian languages, and a fallback model on a second provider means the helpline keeps answering during an outage instead of going silent like the six o'clock landline

  Answer administrative pilgrim questions strictly from the trust's published Knowledge, in the pilgrim's own language, citing the notice. Refuse and hand over anything doctrinal, ritual, advisory or safety-related. Never estimate a timing, a fee or an availability.

Guardrails

• Scope is administrative and logistical ONLY — the agent answers nothing doctrinal, scriptural, ritual, astrological or spiritual, gives no religious advice, generates no religious content, and routes every such question to a person of the trust
• That boundary is enforced twice: by the prompt and by the trust's own `enquiry_route` SpEL rule feeding a Condition node, so it does not depend on model behaviour alone
• Every answer is grounded in the trust's own published material in the scoped Knowledge collection and names the notice it came from; where Knowledge is silent the agent says so and hands over rather than estimating a timing, fee or availability
• Any mention of a medical emergency, a crowd or safety situation, or a missing person ends the automated conversation and escalates to trust staff immediately — the agent never assesses or advises on a safety situation
• The agent takes no bookings, allocates no slot and confirms no accommodation in this workflow — it can only read and restate a status the trust's own system returns
• Unanswered questions are logged as a Knowledge gap for the trust to fill, so the fix is publishing the information rather than letting the model fill the void

Cost strategy

This is the highest-volume workflow in the pack by a wide margin, so the model tier here is the single biggest cost decision — put it on the economy tier and keep it there. It is genuinely economy-tier work: a tightly scoped Knowledge collection of published notices, retrieval, and restatement in the pilgrim's language. Resist upgrading when an answer is wrong; the fix is almost always a missing or ambiguous notice, which the gap log will show you, not a bigger model.

Output & delivery

WhatsApp, Voice (ElevenLabs + Sarvam) or SMS → the `enquiry_route` SpEL rule and a Condition node enforce the administrative-only boundary → the economy-tier agent answers from the trust's scoped published Knowledge, citing the notice → anything doctrinal, advisory or safety-related is filed to the trust's helpdesk queue with the conversation attached → an Output node replies in the pilgrim's language, and every unanswered question is logged as a Knowledge gap for the trust to publish.

Build spec

1 agent — 1 intake/receipt-drafting agent. The payment itself is the Razorpay connector, the payment match is a Condition node, the receipt format and acknowledgement rule are SpEL tools, and the treasurer sign-off and ledger write are workflow nodes. · Pattern: Detail capture → real UPI collection via Razorpay → strict payment match → trust's own format rules → treasurer approves → ledger + receipt

System prompt (paste-ready)

You take donation details for {{trust}} in the donor's own language. Collect strict JSON {donor_name_for_receipt, postal_address, email, phone, amount, purpose (must be one of the trust's published funds in Knowledge), acknowledgement_wanted (bool), language}. Confirm the spelling of the name and the purpose back to the donor before proceeding — a receipt with a wrong name has to be reissued. Use ONLY the published fund list in Knowledge; if the donor names a purpose that is not on it, ask rather than mapping it yourself. NEVER state that a payment has been received — only the Razorpay payment event does that. Do not ask for or accept any card number, bank account number, UPI PIN or OTP, and never ask for a government ID number; if the donor volunteers one, do not record it. Draft the receipt text for the treasurer to approve — never tell the donor a receipt has been issued before approval.

Agent roles & model tiers

• Donation intake / receipt drafter (per donation) — Standard tier — a receipt is a legal document of the trust and a mis-captured name or fund costs a manual reissue and a phone call; volume is bounded by donations, so the tier is affordable, and a fallback model keeps the donation path open during a provider outage

  Collect and confirm receipt-grade donor details in the donor's language, restricted to the trust's published fund list. Never confirm payment, never handle or request card/bank/PIN/OTP or ID numbers, and draft the receipt strictly for treasurer approval.

Guardrails

• The agent never confirms a payment — only a matched Razorpay payment event advances the workflow, and a partial, failed or unmatched payment goes to the office queue instead of generating a receipt
• No receipt and no tax-exemption acknowledgement is issued without the treasurer's Approval — the agent drafts, an authorised officer of the trust commits
• The agent never handles funds and never asks for a card number, bank account number, UPI PIN or OTP; payment is taken entirely by the Razorpay connector
• No government ID number is requested or stored, and any volunteered ID number is not recorded — the receipt is drafted from the name, address and purpose only
• Fund purposes are restricted to the trust's published list; the agent asks rather than mapping an unfamiliar purpose onto a fund itself
• The ledger write and the receipt number draw are keyed to the Razorpay payment reference, so a retried webhook cannot create a duplicate receipt or a double ledger entry
• The agent gives no tax advice — the acknowledgement wording and threshold come from the trust's published policy via `ack_class`, and any question beyond that goes to the trust's office
• The flow is administrative only: it records a contribution and issues a receipt, and never generates religious content, blessing text or any statement about what a contribution means

Cost strategy

Volume is bounded by the number of donations, so there is no runaway multiplier and a standard-tier model is the right call — the failure mode here is a misspelt donor name or a wrong fund, both of which cost a reissue and a phone call, far more than the model difference. If the trust runs a high-volume small-offering season, split the flow: an economy-tier pass for short purpose-only offerings, standard tier only where an address and an acknowledgement are being captured. The formatting and threshold work sits in zero-cost SpEL tools rather than in tokens.

Output & delivery

WhatsApp or the donation-page Webhook → the agent captures and confirms receipt-grade details in the donor's language from the published fund list → Razorpay raises the UPI collection and returns the payment event → the Condition node advances only on a matched payment → `receipt_line` and `ack_class` apply the trust's own format and acknowledgement policy → the treasurer approves at the Approval node → a Tool (MCP) node draws the next receipt number and writes the ledger entry keyed to the Razorpay reference, and an Output node sends the receipt on WhatsApp and via send_email.

Build spec

2 agents — 1 forecasting agent (once per planning run) + 1 procurement-conversion agent (once, after the forecast). The parallel signal gathering, the per-head arithmetic, the kitchen in-charge's decision and the stores filing are workflow nodes and tools. · Pattern: Parallel signal gather → range forecast with drivers → recipe-grounded procurement draft → kitchen in-charge commits the number

System prompt (paste-ready)

(Forecast) You prepare an annadanam planning estimate for {{trust}}. From the supplied signals — booked darshan slots, accommodation occupancy, the trust's own calendar entries, and recorded historical served counts for comparable days — produce per meal sitting {low, likely, high} served counts, the ONE signal that most drove the estimate, and an explicit confidence (LOW|MEDIUM|HIGH). Use only the supplied data and the trust's own records; never invent a historical figure and never use outside assumptions about attendance. If a comparable historical day is missing, say so and mark confidence LOW rather than extrapolating. Output a RANGE, never a single number — the kitchen in-charge sets the actual figure. This is an operational planning estimate only: do not comment on the observance a sitting relates to and do not produce any religious or ritual content.

Agent roles & model tiers

• Forecaster (once per planning run) — Standard tier — this is the hard step: weighing several partial signals and being honest about uncertainty, and it runs only once per cycle so the tier costs little in absolute terms

  Produce per-sitting {low, likely, high} served counts from the supplied signals only, name the dominant driver, and state confidence. Never invent a historical figure; missing comparables mean LOW confidence, not extrapolation. Range only, never a single number.

• Procurement converter (once, after the forecast) — Economy tier — this is arithmetic against the kitchen's documented per-head recipes, not judgement; the Code node and the `per_head_qty` SpEL tool do the actual multiplication

  Convert the served-count range into ingredient quantities using ONLY the documented per-head portions and recipes in Knowledge. Show the per-head basis for each line so the kitchen can check it. Never substitute an ingredient, never assume a portion size that is not documented.

Guardrails

• The agent forecasts, it does not decide — the kitchen in-charge sets the committed number and approves the procurement list at the Approval node before any spend or cooking quantity is fixed
• Output is always a range with its dominant driver and an explicit confidence; a single confident number is prohibited, because a forecast that hides its uncertainty is worse than none
• Estimates use only the trust's own signals and records — booked slots, occupancy, its own calendar, its own served-count history; no outside attendance assumptions and no invented historical figures
• Procurement quantities are computed by a Code node and the kitchen's own SpEL per-head formula against documented portions, with the per-head basis shown per line so a human can check it; no ingredient substitution
• The agent makes no food-safety, hygiene or dietary judgement of any kind — quantity planning only; anything of that nature is the kitchen's own process
• The forecast is planning input for the trust's administration and carries no religious or ritual significance — it never comments on the observance a sitting relates to

Cost strategy

This runs once per planning cycle, not per pilgrim, so absolute cost is small — spend it where the judgement is. One standard-tier forecasting call is worth it because that is the step weighing partial signals; the procurement conversion is arithmetic against documented recipes and belongs on the economy tier, with the multiplication itself done by a zero-cost SpEL tool rather than by tokens. The Parallel gather is I/O, not model calls, so widening the signal set costs latency rather than money.

Output & delivery

A scheduled Webhook fires → a Parallel node gathers booked slots, occupancy, calendar entries and historical served counts → the standard-tier forecaster returns per-sitting {low, likely, high} with its dominant driver and confidence → `planning_number` applies the trust's conservatism rule and a Code node plus `per_head_qty` compute ingredient quantities from documented recipes → the kitchen in-charge sets the number and approves at the Approval node → an Output node issues the sitting plan and costed procurement list to the kitchen and stores teams on WhatsApp and by send_email, and a Tool (MCP) node files it against stores.

Build spec

2 agents — 1 drafting agent (once per signal) + 1 translation agent run once per language through the Parallel node. The threshold signal, the systems read, the pressure-band formula, the officer's approval and the publish are workflow nodes and tools. · Pattern: Threshold signal → grounded draft → parallel translate → trust officer decides → publish only the approved text

System prompt (paste-ready)

You draft administrative crowd advisories for {{trust}}, for an officer of the trust to review. From the supplied queue/slot and accommodation data plus the trust's published heavy-day guidance in Knowledge, write a factual draft of at most 60 words: the currently reported waiting time, the gate or entry the published procedure directs to, and the trust's own published guidance. Use ONLY the supplied readings and the published guidance — never estimate a wait, never predict how a crowd will behave, and never invent a gate or a timing. You must NOT recommend closing an entry, holding a queue, diverting pilgrims, stopping darshan, or any other operational or safety action; if the data looks serious, add a single line flagging that it needs an officer's attention and stop. Include no religious or ritual content of any kind. This is a DRAFT — you never publish, and you never imply the trust has decided anything.

Agent roles & model tiers

• Advisory drafter (once per signal) — Standard tier — it must stay strictly inside the supplied readings and refuse to make operational recommendations under pressure, which is exactly where a weaker model drifts; a fallback model on a second provider matters here because a heavy day is when you cannot wait out an outage

  Write a ≤60-word factual draft from the supplied queue/accommodation readings and the trust's published heavy-day guidance. No estimated waits, no crowd predictions, no invented gates, no operational or safety recommendation, no religious content. Flag seriousness for an officer and stop.

• Translator (once per language, via Parallel) — Economy tier — a constrained, fact-locked rewrite through Sarvam; it runs once per language so it is the multiplier

  Translate the officer-bound draft with waiting times, gate names and guidance byte-identical to the source. Use the official published form of every gate or facility name from Knowledge. Add nothing, soften nothing, drop nothing.

Guardrails

• An agent NEVER makes a crowd-safety call and never publishes — closing an entry, holding a queue, diverting or stopping darshan are decisions for the trust's officers and the civil authorities; the workflow surfaces and escalates, nothing more
• The Approval node is mandatory and covers the English draft and every translation together, so an officer approves the complete bundle that will actually go out
• The seriousness threshold is the trust's own SpEL formula against numbers it set, not a model judgement — that keeps the safety boundary in the trust's hands
• The draft contains only what the trust's own systems reported and what the trust has published — no estimated waiting times, no predictions of crowd behaviour, no invented gates or timings
• The agent is prohibited from making any operational recommendation; where the readings look serious it flags that an officer's attention is needed and stops there
• No religious, ritual or doctrinal content appears in an advisory — these are administrative notices about queues, gates and timings only
• Translations are fact-locked to the approved source and use the official published names of gates and facilities, so approving once cannot let a softened or drifted version reach a different language group
• Idempotent per signal id, so a threshold that flickers does not produce repeated advisory blasts to pilgrims

Cost strategy

Fires only when the trust's own threshold is crossed, so volume is low and bursty — the sizing question is the per-signal bundle, not a steady rate. One standard-tier draft plus L economy-tier translations is the right shape: translation is the multiplier and is fact-locked rewriting, while the single draft is where a drift into recommending an action would actually matter. Putting the threshold in a SpEL tool rather than asking a model to judge seriousness keeps both the cost and the safety boundary in the right place.

Output & delivery

A queue/slot threshold Webhook or a duty-officer raise → a Tool (MCP) node reads current occupancy, queue status and check-ins → `pressure_band` applies the trust's own thresholds → the standard-tier agent drafts a ≤60-word factual advisory with no operational recommendation → a Parallel node prepares every language via Sarvam, fact-locked → an officer of the trust approves or rejects the complete bundle at the Approval node → an Output node publishes only the approved wording to pilgrims on WhatsApp and SMS and to the trust's Telegram channel.