AI agent workflows for Handicrafts & artisan MSME export

Build spec

2 agents — 1 allocation-proposal agent + 1 cheap reply-interpreter that runs once per cluster reply inside the Loop. Voice transcription, the headroom formula, the coverage branch and the approval are workflow nodes and tools. · Pattern: Proposal → tenant-authored headroom cap → in-language fan-out poll (Loop) → coverage gate → human commits allocation and date

System prompt (paste-ready)

(Allocator) Propose a split of a buyer PO across artisan clusters for {{exporter}}. Use ONLY the craft/skill mapping, historical monthly throughput and current open commitments in Knowledge, and respect the headroom returned by the capacity tool. Return strict JSON {allocations[{cluster_id, design, quantity, proposed_ready_date, reason, headroom_note}], unallocated_quantity, assumptions[]}. Never allocate a design to a cluster whose skill mapping does not cover that craft, and never propose a quantity above the tool's headroom — if the order exceeds total capacity, leave the remainder in unallocated_quantity rather than spreading it thin. Proposed dates are internal until a cluster lead confirms and the export manager approves.

Agent roles & model tiers

• Allocation proposer — Standard tier — runs once per PO

  PO → per-cluster allocation with a stated reason, bounded by documented skill mapping and the headroom formula. Remainder goes to unallocated_quantity; capacity is never invented to make the order fit.

• Cluster-reply interpreter (per reply) — Economy tier — one call per cluster reply, including voice-note transcripts

  Turn one cluster lead's in-language reply into {confirmed_quantity, confirmed_date, conditions[], unclear[]}. A partial yes, or a date with no quantity, is marked unclear and gets one short follow-up in their language — never round a hesitant 'ho jayega' up into a confirmation.

Guardrails

• No allocation reaches a cluster and no ship date reaches the buyer before the export manager's Approval — a commitment binds an artisan family's month
• Proposals are bounded by the `cluster_headroom` formula and the documented skill mapping; capacity is never invented to make an order fit
• A shortfall is surfaced as an explicit unallocated quantity with the exact gap — never silently spread across clusters
• A partial or hesitant cluster reply is marked unclear and followed up in the lead's own language, never rounded up into a confirmation
• Cluster leads are asked and answered entirely in their own language, by voice note if that is how they work — the English record exists for the office and the buyer, not for them

Cost strategy

One standard-tier proposal per PO, plus one economy-tier interpretation per cluster reply — reply volume scales with cluster count, not order value, which is exactly why the interpreter stays on the economy tier. The headroom formula is SpEL and costs nothing, which is also why the loading policy belongs there rather than in a prompt that would need re-testing every time it changed. Voice transcription is per note, and it is the price of the clusters participating at all.

Output & delivery

A grounded allocation proposal capped by the tenant's own headroom formula → every cluster lead polled on WhatsApp in-language with voice replies accepted → confirmations interpreted into structured capacity → the Condition node exposes any shortfall against the PO → the export manager commits the allocation and the ship date at the Approval node → clusters are confirmed in-language, the buyer on Email, and the allocation written against the PO in the export ERP.

Build spec

1 agent — 1 payment-status agent. Transcription, the net-payable formula, the dispute branch, the payout approval and the UPI disbursement are workflow nodes and tools. · Pattern: In-language intake → ledger-grounded answer with tenant-authored deduction maths → dispute branch → human-released UPI payout

System prompt (paste-ready)

You answer artisan payment questions for {{exporter}}. Resolve the artisan and the consignment they mean, then read the payment ledger via the ledger tool and answer ONLY from what it returns: {quantity_received, quantity_passed, rate, deduction_pct, amount_paid, on_hold_amount, hold_reason, next_scheduled_date}, using the net-payable tool for the arithmetic. If the ledger has no record, or the artisan disputes a quantity or a deduction, or they ask for money early or out of schedule, do NOT answer with a number — hand it to the accounts owner. Never promise a payment date the ledger does not state, never estimate an amount yourself, and never say a payment has been made unless the ledger shows it. You cannot initiate, approve or release any payment. Reply in the artisan's own language, in short plain sentences.

Agent roles & model tiers

• Payment-status agent — Economy tier — high message volume, and the answer is a grounded lookup plus a formula, not a reasoning problem. Configure a fallback model so an outage does not leave artisans unanswered overnight

  Resolve artisan + consignment, read the ledger, compute net payable with the tool, answer only from those fields, in the artisan's language. Disputes, missing records and early-money requests go straight to the accounts owner. Never states a date the ledger does not state; never moves money.

Guardrails

• The agent reports status only — every disbursement, advance and deduction reversal passes the Approval node before any Razorpay UPI payout executes
• Answers are strictly ledger-backed and the arithmetic comes from the `net_payable` formula: no estimated amounts, no promised dates the ledger does not state, no 'it has been paid' without a ledger record
• Disputes over quantity or quality deductions, and any request for early money, route straight to the accounts owner — the agent does not negotiate on the exporter's behalf
• Identity is resolved from the registered number before any figure is disclosed, so one artisan's payables are never read out to another
• Every reply is in the artisan's own language, including the reason for a hold; the English audit record is for the office side

Cost strategy

This is the highest-volume workflow in the set — many short, repeated questions — so the answering agent belongs on the economy tier and nowhere else; the accuracy comes from the ledger tool and the SpEL formula, not from model size. Transcription is per voice note. The only expensive path is escalation, and that is a human's time spent on genuine disputes, which is exactly where it should go.

Output & delivery

An artisan's WhatsApp message or voice note in any supported Indian language → Sarvam transcription → identity and consignment resolved → net payable computed by the exporter's own formula → a ledger-backed status answered in their own language, or a dispute routed to accounts → any actual payout waits at the Approval node → on release, a Razorpay UPI disbursement executes and is confirmed to the artisan in-language with its reference, with the same trail visible to the accounts owner.

Build spec

2 agents — 1 per-document checker (once per required document via the Loop) + 1 reducer that writes the readiness report. The cross-document arithmetic is a Code node and the tolerance band is a SpEL tool — deliberately, neither is an agent. · Pattern: Map over the document set → deterministic Code-node cross-checks → tenant-authored tolerance band → reduce → human releases the shipment

System prompt (paste-ready)

(Checker) Verify ONE required export document for shipment {{shipment_ref}} to {{destination}} on incoterm {{incoterm}}. Return strict JSON {doc_type, status (PRESENT_COMPLETE|PRESENT_INCOMPLETE|MISSING|UNSIGNED|UNREADABLE), missing_fields[], extracted{invoice_total, currency, carton_count, gross_weight, net_weight, hs_codes[]}, owner}. Extract values EXACTLY as printed — do not convert currencies, do not convert weight units, do not reformat an HS code. If a field is absent, return null and list it in missing_fields[]. You do not compare documents against each other; the workflow's Code node does that arithmetic. You never declare a shipment ready.

Agent roles & model tiers

• Document checker (per document) — Economy tier — runs once per required document on every consignment, so it sets the cost of the run

  One document → presence, completeness, signature status and verbatim extracted fields as strict JSON. No unit or currency conversion, no reformatting, null for absent fields. No cross-document comparison, no release judgement.

• Readiness reducer — Standard tier — reasoning. Economy fallback model so a provider outage still yields a usable, flagged report before the cut-off

  Combine the per-document verdicts with the Code node's cross-check results and the tolerance bands into one release-readiness report. State every mismatch as the two conflicting values with their source documents named. Name the owner and the single next action for each open item. Report only what the verdicts and checks contain — never assert a document is fine because nobody flagged it.

Guardrails

• The consignment is released only at the Approval node — the workflow never hands over to the forwarder, never pushes filing data and never signs a declaration on its own judgement
• Cross-document arithmetic (line-item totals, carton counts, gross/net weights, HS-code consistency) is done deterministically in a Code node — a language model is never the arbiter of whether two numbers match
• The tolerance band is the export desk's own SpEL expression, so what counts as a rounding artefact is an auditable business setting rather than a model's discretion
• Extraction is verbatim: no currency conversion, no unit conversion, no HS-code reformatting; an absent field is null and gets chased, never inferred
• The required-document list is resolved per destination, incoterm and product category — one generic checklist is never applied to every lane
• Mismatches are always reported as both conflicting values with their source documents named, so the human resolves a fact rather than adjudicating a summary

Cost strategy

Per consignment: N documents × economy-tier checker + one deterministic Code node (effectively free) + one SpEL banding call (free) + one standard-tier reduce. Moving the cross-checks into code is a cost decision as much as a correctness one — arithmetic in code costs nothing and never hallucinates, which lets the per-document checker stay narrow and cheap. Parallel batches compress wall-clock time without changing per-document cost.

Output & delivery

Each required document is checked once by a cheap agent → a Code node runs the cross-document arithmetic deterministically → each difference is banded by the desk's own tolerance expression → a reducer writes the release-readiness report with every mismatch quoted value-against-value → the export head releases at the Approval node → a Tool (MCP) node pushes the pack to the forwarder/CHA and the shipping-bill data set to the filing agent, while open items go back to their owners on Email or in-language WhatsApp.

Build spec

3 agents — 1 economy-tier reply interpreter (per cluster reply, inside the Loop) + 1 capacity-model agent + 1 pipeline-fit agent. Voice transcription, the weekly-capacity formula and the plan approval are workflow nodes and tools. · Pattern: In-language capacity poll (Loop) → tenant-authored weekly capacity formula → capacity model → pipeline fit → human approves the plan and the dates

System prompt (paste-ready)

(Capacity model) Build a week-by-week capacity view for the season window {{window}} per cluster and craft. Inputs: each cluster lead's confirmed available artisan count and stated absences, last comparable season's ACTUAL output from Knowledge, and the local festival/harvest calendar. Use the weekly-capacity tool for every indicative figure. Return strict JSON {weeks[{week, cluster_id, craft, available_days, indicative_units, basis}]}. Never use nominal or theoretical capacity, and never take a cluster's optimistic self-estimate alone as the basis. Net out every calendar absence. Where last season has no comparable actual, set basis='no_baseline' and leave indicative_units null rather than guessing.

Agent roles & model tiers

• Cluster-reply interpreter (per reply) — Economy tier — one call per cluster reply, including transcribed voice notes

  One cluster lead's in-language reply → {available_artisans, absence_periods[], crafts_available[], unclear[]}. One short in-language follow-up on anything unclear; never convert a vague answer into a firm number.

• Capacity-model agent — Standard tier — runs once per planning cycle

  Confirmed availability + last season's actuals + festival/harvest calendar → week-by-week indicative capacity per cluster and craft, every figure from the weekly-capacity tool, with the basis stated per row. Null where there is no baseline; every calendar absence netted out.

• Pipeline-fit agent — Premium tier — the hard step, and its output is what dates get promised from. Economy fallback model configured, with any degraded run flagged in the plan header

  Lay the open enquiry and order pipeline over the capacity view. Mark each enquiry SERVABLE | SERVABLE_LATER (with the earliest defensible date and its basis) | NOT_SERVABLE, and name the binding constraint for every non-clean case — cluster, craft, week or material. Flag every enquiry that depends on a null/no-baseline capacity row. These are proposals for the manager, never commitments.

Guardrails

• No buyer-facing festival-season date leaves the workflow — every date in the plan is a proposal until the export manager approves it at the Approval node
• Capacity is derived from last comparable season's ACTUAL output through the `week_capacity` formula, never from nominal capacity or a cluster's optimistic self-estimate alone
• Where no comparable baseline exists, capacity is null with basis='no_baseline' and every enquiry depending on it is flagged — the plan never fills a gap with a guess
• Festival and harvest absences are netted out of available days before any indicative number is produced
• Every non-servable or later-date verdict names its binding constraint, so the manager can act on the constraint rather than argue with a conclusion
• Clusters receive an indicative load, explicitly labelled as such, in their own language — an indicative plan is never sent as a confirmed work order

Cost strategy

A planning cycle costs: one economy-tier interpretation per cluster reply + one standard-tier capacity model + one premium-tier pipeline fit. The premium tier is justified exactly once, on the step whose output becomes promised dates; polling and modelling stay cheap, and the weekly-capacity arithmetic is a free SpEL evaluation. Because the cycle runs a few times a season rather than per order, total spend is small — what is being protected is the season's credibility with buyers, not a per-transaction margin.

Output & delivery

Every cluster lead polled in-language with voice replies accepted → a week-by-week capacity view computed by the planner's own formula from last season's actuals and netted of the festival/harvest calendar → each open enquiry marked servable, servable-later or not servable with its binding constraint named → the export manager approves the plan and any buyer-facing dates at the Approval node → clusters receive their indicative weekly load in-language and the sales desk receives the approved position, with the plan attached to the season record in the ERP.