Turn landings into traceable export lots, catch a document gap or a rejection risk before the container closes, and talk to fishers by voice in their own language — with every price, shipment date and payout human-approved.
Each recipe below is expressed only in VegaDūta's real workflow building blocks — Trigger, Agent, Knowledge, Condition, Approval, Output, Tool (MCP), Voice, Device, Loop, Code and Parallel — so it maps 1:1 to something you can assemble in the Workflow designer. Consequential actions always pass a human Approval step.
1. Catch landing → export-lot traceability record
Today: at the landing centre the weighing clerk calls out species and grade, someone writes the weight on a carbon-copy paper slip, and the agent sends a photo of the slip to the plant's WhatsApp group. Vessel registration, fishing area and gear are 'known' because everyone knows the boat. Days later, when an export lot has to declare catch origin, vessel, area, gear and landing date, the traceability officer reassembles it from a folder of slips and the WhatsApp scroll — and the fields nobody wrote down are gone, because the boat has sailed again.
Trigger: WhatsApp / Webhook (landing declared at the landing centre or peeling shed)
How the workflow runs
Trigger
A landing is declared.A WhatsApp message, voice note or slip photo from the harbour agent, or a Webhook from the landing-and-procurement system (no first-party connector), starts the record: vessel, trip, species, grades, weights, ice status.
Agent
Structure the landing.An Agent node turns the free-text, voice note or photographed slip into structured fields — vessel and registration, trip dates, fishing area, gear, species with grade and weight, landing time — and flags every field it could not read rather than filling it in.
Condition
Traceability fields complete?.A Condition node checks the fields an export lot will eventually need. An incomplete landing branches to a single, specific question back to the harbour agent — asked now, at the quay, while the crew is still standing there and the answer is still knowable.
Loop
Roll landings into lots.A Loop node walks the day's landings and assigns each to the export lot it feeds, building the lot's catch composition as a real many-to-one record instead of a summary typed from a folder a week later.
Approval
Lot composition confirmed.An Approval node holds the lot's composition for the plant's traceability officer — this record is what the export certificate will rest on, so a human confirms it rather than inheriting whatever was parsed from a slip photo.
Output
Write the traceability record.A Tool (MCP) node writes the confirmed landing-to-lot record into the plant's traceability system, keyed to the lot id, and an Output node confirms back to the harbour agent on WhatsApp.
Channels & connectors
WhatsApp
Webhook
Sarvam (Indian languages)
Tool (MCP → landing / traceability system)
Approval / HITL
Outcome
Each landing is captured as a structured, gap-checked record at the quay and rolled into its export lot's catch composition, confirmed by the traceability officer — instead of being reconstructed from a folder of carbon slips after the boat has sailed.
Why it helps
The mechanism is capture-at-source with a completeness gate: the traceability fields are hardest to recover days later and trivially easy to obtain in the moment. Asking the one missing question while the vessel is still alongside is the whole value; the human confirmation keeps the certificate's foundation trustworthy.
Build spec
1 agent — 1 landing-structuring agent (runs per landing, including inside the Loop that rolls landings into lots). The completeness gate, the officer's Approval and the traceability write are workflow nodes.
System prompt (paste-ready)
You are a landing-record assistant for {{plant}}. From a free-text message, voice note or photographed landing slip, extract {vessel_name, vessel_reg, trip_start, landing_datetime, fishing_area, gear_type, species[{name, grade, weight_kg}], ice_status, harbour_agent}. Extract ONLY what is present — set any field you cannot read to null and list it in missing[]; never infer a fishing area from the harbour, never infer gear from the vessel name, never round a weight to a tidier number, and never carry a value over from a previous landing by the same boat. Messages may be in a local Indian language; understand them as sent. Return {fields, missing[], confidence}. You do not assign a lot id and you do not confirm a lot's composition — the workflow and the traceability officer do that.
Agent roles & model tiers
Landing structurer (per landing) — Economy tier — short slips, photos and voice notes at high daily volume across every landing; accuracy comes from the strict schema and the missing[] discipline, not from model size. A fallback model keeps the quay working when a provider is down and the boat will not wait.
Extract landing fields into strict JSON with explicit nulls and a missing[] list. Local-language input is normal. No inference of area or gear, no rounded weights, no carry-over from a previous landing.
MCP connectors
Landing / procurement system — via Tool (MCP): validate the vessel registration against the register and resolve the boat's owner and home port
Plant traceability system — via Tool (MCP): create or update the landing record and append it to the export lot's catch composition, keyed to the landing id
WhatsApp — the harbour agent's channel for the slip, the one clarification question and the confirmation
Built-in tools
knowledge_search (scoped Knowledge collection: mandatory traceability fields, species and grade nomenclature, area and gear codes)
http_request (validate the vessel registration; write the landing-to-lot record)
user-defined tool `landing_ref` (SpEL, sandboxed formula — no API calls, no code): input.harbourCode + '/' + input.landingDate + '/' + (input.vesselReg ?: 'UNREG') — the plant's own landing reference format, built the same way every time; the elvis keeps an unregistered boat visible as UNREG instead of silently blank
user-defined tool `trace_completeness` (SpEL): input.missingCount == 0 ? 'COMPLETE' : (input.missingCount <= input.softGapAllowance ? 'CLARIFY_AT_QUAY' : 'BLOCK_LOT_ASSIGNMENT') — the plant encodes how strict it wants to be, and changes it when a market tightens, without a developer or a redeploy
Guardrails
Unreadable fields are null and listed in missing[] — the agent never infers a fishing area, gear type or weight, because a guessed traceability field is worse than a blank one and will fail an audit later
The completeness gate asks the harbour agent one specific question at the quay rather than accepting a partial record that becomes unrecoverable once the boat sails
`trace_completeness` is a routing classifier over the plant's own tolerance; 'COMPLETE' means the fields are present, never that the catch is compliant — the export lot's composition is still confirmed by the traceability officer at the Approval node
Vessel registrations are validated against the register via lookup, not accepted as typed or as remembered
The traceability write is idempotent per landing id, so a resent slip photo updates the record instead of duplicating a landing into the lot
Cost strategy
One economy-tier extraction per landing, and landings are the highest-count event in the whole chain — precisely where the cheap tier belongs, with a hard cap per message. The Sarvam transcription leg for quay voice notes is usage-billed per audio minute and is the main variable cost on a busy landing day. No premium tier is justified anywhere here; correctness comes from the schema, the register lookup and the human confirmation.
Output & delivery
The landing arrives on WhatsApp or Webhook → the economy-tier agent structures it with explicit gaps → `trace_completeness` applies the plant's own strictness and the Condition node asks the one missing question at the quay → the Loop rolls the day's landings into their export lots under the tenant's `landing_ref` format → the traceability officer confirms the lot composition at the Approval node → a Tool (MCP) node writes the record keyed to the lot id and an Output node confirms to the harbour agent.
2. Pre-shipment document completeness check before the container is committed
Today: the export documentation clerk assembles the pack the night before the container closes — health certificate, catch documentation, packing list, invoice, the lab reports for the parameters that market tests, and the buyer's own annexes — printed, in a folder, checked by reading them one after another. The lot ids, net weights and production dates have to agree across all of them, and the pair nobody thought to compare is the pair that stops the container. Everyone finds out at 11pm, or at the other end of the world.
Consignment enters pre-shipment.A Webhook from the export/ERP system (no first-party connector) or an Email carrying the document pack starts the check, with the destination market and the buyer's contract terms attached.
Knowledge
Load the destination's requirement set.A scoped Knowledge collection holds the per-destination documentary requirement list and the buyer's contractual annexes, so the check runs against the market this container is actually going to, not the generic list in the clerk's head.
Parallel
Read every document at once.A Parallel node fans the document pack out so each document is read concurrently — the pack is checked in the time the slowest single document takes, not in the time it takes to read them in sequence.
Agent
Extract the key fields per document.A per-document agent pulls the fields that must reconcile — lot ids, species, net and gross weights, production and expiry dates, certificate numbers, establishment approval number — and flags anything unreadable instead of assuming it.
Agent
Reconcile across the pack.A reconciliation agent cross-checks every extracted field against every other document and against the destination's requirement set, and returns a findings list: missing documents, absent fields, and — the expensive one — values that disagree between two documents.
Approval
Export desk clears the pack.An Approval node puts the findings in front of the export documentation desk. Committing a shipment date, releasing the pack to the buyer or to a certifying authority is a human action; the agent produces the checklist, not the clearance.
Output
Route the gaps to whoever can close them.An Output node sends each gap to its owner — plant QA, the lab, the traceability officer — on Email or WhatsApp, and files the findings against the consignment via a Tool (MCP) node.
Channels & connectors
Webhook
Email
WhatsApp
Knowledge base
Tool (MCP → export/ERP + document store)
Approval / HITL
Outcome
Every consignment gets a full cross-document reconciliation against its destination's requirement set before the shipment date is committed — every field against every other document, not the pairs one tired clerk thought to check at 11pm.
Why it helps
The mechanism is exhaustive cross-checking: a person reads a document pack sequentially and compares the pairs they think to compare, while the failure is almost always in a pair nobody thought of. Comparing every field against every document, every time, is exactly the work that is tedious for a person and cheap to automate — and the clearance stays human because a committed shipment date is a commercial promise.
Build spec
2 agents — 1 extraction agent (runs once per document, in Parallel) + 1 reconciliation agent (once per consignment). The requirement set, the desk's Approval and the filing are workflow nodes. · Pattern: Parallel per-document extraction → single cross-document reconciliation → export-desk Approval
System prompt (paste-ready)
(Extraction) Read ONE export document. Return strict JSON {doc_type, doc_number, issue_date, lot_ids[], species[], net_weight_kg, gross_weight_kg, production_date, expiry_date, establishment_approval_no, signatory, unreadable_fields[]}. Extract only what the document states — never carry a value in from another document in the pack, never normalise a weight or a date into what it 'should' be, and never fill a field from the consignment header. Anything you cannot read with confidence goes to unreadable_fields[] as null. You do not judge whether the pack is complete and you do not clear anything.
Agent roles & model tiers
Document extractor (per document, in Parallel) — Economy tier — bounded per-document extraction into a fixed schema, run several times per consignment; the multiplier lives here, and a fallback model prevents a provider blip from stalling a pack the night before closing
Extract the reconcilable fields from ONE document into strict JSON. No cross-document carry-over, no normalisation, unreadable fields explicitly null. No completeness judgement.
Pack reconciler (once per consignment) — Premium tier — the genuinely hard step: every field compared against every other document and against the destination's requirement set, where a missed mismatch is the entire failure mode. One call per consignment, so the tier costs little in aggregate.
Cross-check all extracted documents against each other and against the destination requirement set in Knowledge. Return findings as {missing_documents[], missing_fields[], mismatches[{field, doc_a, value_a, doc_b, value_b}], unreadable[]} with a severity per finding. Report only differences you can point at with both values. Do NOT declare the pack cleared, and do NOT suggest amending a document to make it match — flag the disagreement and let a human resolve it.
MCP connectors
Export / ERP system — via Tool (MCP): read the consignment header, destination market, buyer contract terms and shipment stage; file the findings back against the consignment
Document store — via Tool (MCP): fetch the document pack (health certificate, catch documentation, packing list, invoice, lab reports, buyer annexes) for the consignment
Certification portal — via Tool (MCP): check whether the certificate reference already exists against this consignment before the desk submits anything
Email / WhatsApp — document intake, and routing each gap to plant QA, the lab or the traceability officer
http_request (fetch the document pack; file the findings against the consignment)
send_email (route each gap to its owner with the document and field named)
user-defined tool `weight_agreement` (SpEL, sandboxed formula — no API calls, no code): (input.netA - input.netB > input.toleranceKg || input.netB - input.netA > input.toleranceKg) ? 'WEIGHT_MISMATCH' : 'WEIGHT_OK' — the exporter's own tolerance, applied identically to every document pair (no abs() needed; the grammar has no method calls)
user-defined tool `gap_owner_line` (SpEL): input.docType + ' · ' + input.field + ' → ' + (input.owner ?: 'EXPORT_DESK') — one fixed line per gap so the QA, lab and traceability inboxes all receive the same recognisable shape
Guardrails
The agents produce a findings list, never a clearance — releasing the pack, committing the shipment date and submitting to a certifying authority all pass the export desk's Approval node
Extraction never carries a value between documents: a field absent from a certificate stays absent, because inheriting it from the invoice is precisely how a mismatch gets hidden instead of found
A mismatch is reported with both sides quoted and both sources named; the agent never proposes editing a document to make the pack agree
`weight_agreement` compares two numbers against the exporter's own tolerance — it flags a discrepancy for a human, and 'WEIGHT_OK' never constitutes clearance of the pack or of the product
Requirements are read per destination market and per buyer contract from the scoped Knowledge collection — never a generic list, and the agent never asserts a requirement the set does not contain
Unreadable fields are surfaced as unreadable, so a scan-quality problem shows up as a finding instead of silently passing the reconciliation
Cost strategy
Cost is D × (economy-tier extraction, one call per document) + ONE premium-tier reconciliation per consignment. That split is deliberate: extraction is bounded, repetitive and schema-checked, so the cheap tier handles it; reconciliation is the hard reasoning step and gets the best model exactly once, which is affordable precisely because it runs once. The numeric tolerance comparison is done by a SpEL expression rather than by tokens. Running the extractions in Parallel cuts wall-clock time to the slowest document without changing per-document cost.
Output & delivery
The Parallel node fans economy-tier extraction across every document in the pack → the exporter's `weight_agreement` tolerance is applied to every document pair → the premium-tier reconciler cross-checks all fields against each other and against the destination's requirement set → the export desk reviews and clears at the Approval node → an Output node routes each gap in the tenant's own `gap_owner_line` format to plant QA, the lab or the traceability officer, and a Tool (MCP) node files the findings against the consignment.
3. Border-rejection risk review before a container ships
Today: the export head decides to ship on the strength of 'the lab reports came back fine' — which means fine against the domestic limit on the report header, because the destination's tighter limit lives in a circular saved on someone's desktop. The plant's own rejection history is a folder of old emails. Whether that market is currently testing this species harder than usual is something you hear about from another exporter at the association meeting. All the signals exist; none of them are ever in front of one person at the same time.
Trigger: Webhook (consignment ready to ship, pre-dispatch review)
How the workflow runs
Trigger
Pre-dispatch review opens.A Webhook from the export system fires when a consignment reaches pre-dispatch, carrying destination, species, product form, lot ids and the linked lab reports.
Knowledge
Destination rules + recent alert history.A scoped Knowledge collection holds the destination market's tested parameters and limits, the plant's own rejection and alert history, and the heightened-scrutiny notices the export desk maintains — the circular, the email folder and the association gossip, in one place the workflow can actually read.
Agent
Compare results against the destination's limits.An Agent node checks each lab parameter against the destination's specific limits — not the domestic ones on the report header — and highlights any result that is within domestic spec but close to or over the destination's tighter limit.
Agent
Assemble the risk picture.A second agent adds the non-lab factors: the traceability record's completeness, the species and product form's recent alert pattern for that destination, and any parameter that market is currently testing more intensively — and writes a structured risk review with each factor evidenced.
Condition
Any elevated factor?.A Condition node separates a clean review, which goes to the desk as a short confirmation, from one with an elevated factor, which is escalated with the full evidence for a considered decision.
Approval
Export head decides to ship, hold or re-test.An Approval node holds the decision. Shipping, holding, re-testing or re-routing a consignment to a different market is a commercial and food-safety judgement the export head makes; the workflow supplies the evidence and never clears a consignment itself.
Output
Record the decision with its reasoning.An Output node notifies the plant and the buyer-facing team on Email or WhatsApp, and a Tool (MCP) node writes the review, the decision and its reasoning against the consignment — which is also what makes the next review's history worth reading.
Channels & connectors
Webhook
Email
WhatsApp
Knowledge base
Tool (MCP → export/ERP + LIMS)
Approval / HITL
Outcome
Every consignment gets a written, evidenced risk review against its actual destination's limits and current scrutiny pattern before it ships — the circular, the rejection history and the traceability state read together, once, by the person deciding.
Why it helps
The mechanism is assembling scattered signals into one view at the last moment where acting is still cheap: the lab results, the destination's limits, the alert history and the traceability state all exist but live in a report header, a desktop circular, an email folder and another system. Nothing here predicts a rejection — it surfaces the evidence a person would have wanted, before the container is at sea.
Build spec
2 agents — 1 parameter-comparison agent + 1 risk-review assembler, both once per consignment. The destination rule set, the escalation branch and the export head's Approval are workflow nodes. · Pattern: Destination-specific parameter check → risk assembly → escalation gate → export-head Approval
System prompt (paste-ready)
(Parameter check) Compare ONE consignment's lab results against the DESTINATION market's limits, not domestic limits. Inputs: {destination, species, product_form, results[{parameter, value, unit, method, tested_at}], destination_limits[]}. Return strict JSON {per_parameter[{parameter, value, destination_limit, margin_pct, status (WITHIN|NEAR_LIMIT|OVER|NOT_TESTED)}], untested_required_parameters[], stale_results[]}. A parameter the destination requires but the consignment has not tested is NOT_TESTED and must be listed — never treat an untested parameter as passing. Never convert units unless the conversion is exact, and state it when you do. You do not decide whether to ship.
Agent roles & model tiers
Destination parameter check (per consignment) — Standard tier — unit-aware comparison against the correct market's limits, where the classic error is quietly checking the domestic limit printed on the report instead
Compare each result against the destination's limit, band it WITHIN / NEAR_LIMIT / OVER / NOT_TESTED, and list required-but-untested and stale results explicitly. Untested is never a pass. No shipping decision.
Risk review assembler (per consignment) — Premium tier — synthesises lab findings, traceability completeness and the destination's current scrutiny pattern into the document the export head decides on; one call per consignment, and the decision it informs outweighs any token bill
Write a structured risk review: each elevated factor with its evidence and source (lab result, traceability gap, recent alert pattern, current heightened-scrutiny notice), plus the factors checked and found clean. Present factors and their evidence — do not compute a false-precision risk score, do not predict an outcome, and do not recommend shipping. The export head decides.
MCP connectors
Export / ERP system — via Tool (MCP): read the consignment's destination, species, product form and lot ids at pre-dispatch, and write the review, decision and reasoning back against it
Lab / LIMS — via Tool (MCP): fetch every parameter result for the consignment's lots with method and test date, so staleness is visible
Plant traceability system — via Tool (MCP): read the completeness state of the lots in the consignment (open gaps from the landing workflow)
Email / WhatsApp — plant and buyer-facing team notification of the recorded decision
Built-in tools
knowledge_search (scoped Knowledge collection: destination limits and tested parameters, plant rejection/alert history, current heightened-scrutiny notices)
web_search (optional, desk-curated: check whether the destination authority has published a new notice since the Knowledge collection was last updated — a prompt to the desk to refresh it, never a substitute for the maintained rule set)
http_request (pull lab results and traceability state; write the review and the decision)
user-defined tool `dest_param_band` (SpEL, sandboxed formula — no API calls, no code): input.value == null ? 'NOT_TESTED' : (input.value > input.destLimit ? 'OVER' : (input.value > input.destLimit * input.nearFactor ? 'NEAR_LIMIT' : 'WITHIN')) — the exporter sets its OWN nearFactor per market and tightens it when a market gets stricter, with no developer and no redeploy; it bands a number, it never clears a consignment
Guardrails
FOOD SAFETY and commercial: no agent and no tenant expression clears a consignment to ship. The review presents evidenced factors; ship, hold, re-test and re-route are decided by the export head at the Approval node and recorded with their reasoning
A required parameter that was not tested, or whose result is stale, is reported as such and never treated as a pass — the missing test is the finding, and `dest_param_band` returns NOT_TESTED for a null rather than a comfortable default
Comparisons run against the destination market's limits held in Knowledge, never the domestic limit on the report header; the agent never asserts a limit the requirement set does not contain and states any unit conversion it performs
No numeric risk score or probability is produced — a fabricated percentage would look authoritative and mean nothing. Factors are listed with their evidence and their source
The destination rule set and scrutiny notices are maintained by the export desk in the Knowledge collection; the agent reads them and never edits or extrapolates them, and any web_search result is surfaced as 'the desk should verify and update', never adopted as a rule
Cost strategy
Both agents run exactly once per consignment and the decision they inform is worth more than any plausible token bill, so the parameter check sits on the standard tier and the single review-writing call is allowed the premium tier — this is the hard step the economy tier elsewhere in the stack exists to pay for. Volume is naturally bounded by consignment count, so there is no multiplier to manage; keep the Knowledge retrieval scoped to the destination in question rather than growing the tier further, and configure a fallback model so a provider outage cannot become a reason to ship unreviewed.
Output & delivery
The pre-dispatch Webhook opens the review → the parameter agent, using the exporter's own `dest_param_band` factors, compares every result against the destination's limits and names the untested ones → the premium-tier assembler adds traceability completeness, alert history and current scrutiny notices into an evidenced risk review → the Condition node escalates anything elevated → the export head decides ship, hold, re-test or re-route at the Approval node → an Output node notifies plant and the buyer-facing team and a Tool (MCP) node records the decision and its reasoning against the consignment.
4. Fisher intake and payment queries by voice, in the local language
Today: the purchase office runs on one phone. Fishers call in from the harbour wall or from the boat to declare what they are bringing, and call again days later to ask what grade it was assessed at, what it paid, and when the money lands. The clerk writes declarations on a pad, reads grades off a screen the fisher will never see, and repeats himself in Malayalam, Tamil or Konkani all day. There is a portal. Nobody uses it — the man asking is standing on a wet deck with one hand free.
Trigger: Voice call / WhatsApp voice note (fisher declares a landing or asks about payment)
How the workflow runs
Trigger
The fisher calls or sends a voice note.An inbound Voice call or a WhatsApp voice note from the fisher's registered number opens the conversation; the number identifies them against the purchase register.
Voice
Speak their language, both ways.A Voice node uses Sarvam for Indian-language speech-to-text and ElevenLabs for the spoken reply, so a Malayalam or Tamil voice note is understood as sent and answered aloud in the same language — no portal, no typing, one hand free.
Agent
Route the intent, then answer from the record.An Agent node separates a landing declaration from a payment query. A declaration is captured into the same structured landing schema the traceability workflow uses; a payment query is answered from the purchase and payout record pulled via a Tool (MCP) node.
Condition
Declaration, query, or dispute?.A Condition node routes: a declaration goes to the traceability sub-workflow, a plain payment query is answered, and anything disputing a grade, a weight or a rate — or requesting an advance — goes to a person.
Sub-workflow
Hand a declaration to the landing workflow.A Sub-workflow node passes a voice-declared landing into the catch-landing traceability recipe, so a spoken declaration produces the same gap-checked, human-confirmed record as a written slip — the convenient channel does not get a second, weaker data path.
Approval
Any rate or payout is human-approved.An Approval node holds every commitment involving money: quoting a purchase rate, releasing a payment, granting an advance, or correcting a disputed grade. The agent explains what is recorded; a person decides what changes.
Output
Answer aloud, and confirm the payment reference.An Output node replies in the fisher's language — spoken on a call or voice note, text on WhatsApp — and, where a human has approved and released a payout, includes the Razorpay UPI reference.
Channels & connectors
Voice/Call
WhatsApp
SMS/Twilio
Sarvam (Indian languages)
ElevenLabs (voice)
Razorpay (UPI)
Tool (MCP → purchase / payout system)
Approval / HITL
Outcome
Fishers can declare a landing or ask about a grade and a payment by voice in their own language at any hour, grounded in the actual purchase record — instead of queuing for one clerk on one phone — with every rate, payout and correction still passing a person.
Why it helps
The mechanism is removing the channel barrier without weakening the record: voice in a local language is how this workforce actually communicates, and a portal they will not use is the same as no system at all. Feeding voice declarations into the same traceability sub-workflow avoids the usual trap, where the convenient side-channel quietly produces worse data than the main one.
Build spec
1 agent — 1 intake-and-query agent. Speech in/out (Sarvam + ElevenLabs), the intent branch, the traceability Sub-workflow and the rate/payout Approval are workflow nodes — the landing record is structured by the sub-workflow's own agent, not duplicated here.
System prompt (paste-ready)
You are a seafood purchase desk's fisher-support assistant for {{plant}}. The fisher is identified by their calling number against the purchase register; an unregistered number is asked for a supplier code rather than served speculative data, and no fisher is ever shown another's records. First classify the intent: LANDING_DECLARATION, PAYMENT_QUERY, GRADE_QUERY, DISPUTE or ADVANCE_REQUEST. For a declaration, collect the landing fields and hand off to the landing sub-workflow — do not assess a grade or state a value yourself. For a payment or grade query, answer ONLY from the purchase and payout record returned by the Tool (MCP) lookup: state the assessed grade, weight, applied rate and payment status as recorded, and the documented payment cycle. Never quote a rate for a future landing, never estimate what a catch 'should' fetch, and never say a payment has been made unless the record says so. DISPUTE and ADVANCE_REQUEST are acknowledged in the fisher's language and handed to a person — never negotiated. Reply in the language the fisher used.
Agent roles & model tiers
Fisher intake & query agent (per conversation) — Economy tier — every fisher, most landing days, largely intent-routing and record read-back; correctness comes from the purchase-record lookup, not from model size. A fallback model on a second provider matters here, because the alternative during an outage is the one clerk and the one phone.
Classify intent, identify the fisher by registered number, and either hand a declaration to the landing sub-workflow or answer a grade/payment question from the real purchase record in the fisher's own language. No rate quotes, no grade assessments, no payment promises. Disputes and advances are handed off.
MCP connectors
Purchase / payout system — via Tool (MCP): look up a supplier's landings with assessed grade, weight and applied rate, and read the payment status for a cycle
Purchase / payout system — via Tool (MCP): the payout release call, invoked ONLY by the workflow after the Approval node, never by the agent mid-conversation
Voice / WhatsApp / SMS — the fisher's own channel, on the boat or the harbour wall
Razorpay UPI — payout reference read back to the fisher once a human has released the payment
http_request (look up the fisher's landings, grades and payment status by supplier code)
user-defined tool `payout_line_spoken` (SpEL, sandboxed formula — no API calls, no code): input.grade + ' · ' + input.weightKg + ' kg × ₹' + input.ratePerKg + ' = ₹' + (input.weightKg * input.ratePerKg) — the plant's own settlement line, arithmetic done by the expression rather than by a model, and read aloud in the same shape every time
user-defined tool `settlement_state` (SpEL): input.paidOn != null ? 'PAID' : (input.approvedBy != null ? 'AWAITING_RELEASE' : 'PENDING_APPROVAL') — reports where a payment stands from the record's own fields; it can describe the state, it can never advance it
Guardrails
Identity is bound to the registered calling number; an unrecognised number is asked for a supplier code and never served another fisher's grades or payments
The agent never assesses a grade and never quotes a purchase rate — grading is a physical assessment and a rate is a commercial commitment; both pass a person at the Approval node
Every payout, advance and disputed-grade correction is approved and released by a human. `payout_line_spoken` formats a settlement that already exists and `settlement_state` labels it; neither can move money
Voice-declared landings go through the SAME traceability sub-workflow, completeness gate and human confirmation as written slips — the convenient channel does not get a weaker record
Low-confidence transcription asks the fisher to repeat rather than acting on a guessed weight or species, and the reply always mirrors the language the fisher used
Cost strategy
One economy-tier agent call per conversation; the real variable cost is the Sarvam and ElevenLabs speech legs, billed per audio minute, so spoken replies are kept short and factual rather than conversational — and the settlement arithmetic is a SpEL expression, not tokens. No batch multiplier and no premium tier anywhere in this recipe: accuracy comes from the purchase-record lookup, the strict intent routing and the human approvals, and a bigger model would buy none of them. The fallback model is the spend that actually protects the service.
Output & delivery
Sarvam transcribes the fisher's call or voice note → the economy-tier agent classifies intent and identifies them by registered number → a declaration is handed to the landing traceability Sub-workflow (same gate, same human confirmation), a grade or payment question is answered from the real purchase record using the plant's own `payout_line_spoken` and `settlement_state` expressions, and a dispute or advance request is routed to a person → any rate, payout or correction passes the Approval node → an Output node answers aloud in the fisher's own language via ElevenLabs, with the Razorpay UPI reference included once a human has released the payment.
