AI agent workflows for Textile & apparel manufacturing

Build spec

5 agents — 1 diff agent + 3 parallel impact assessors (materials / production / costing) + 1 supervisor that consolidates. Parallel, Approval, Knowledge and Sub-workflow are workflow nodes, not agents. · Pattern: Diff → tenant-authored severity scoring → Parallel fan-out (3 assessors) → Supervisor consolidation → human approval → optional sampling sub-workflow

System prompt (paste-ready)

(Diff agent) Compare the incoming techpack revision against the approved in-production techpack + BOM in Knowledge for style {{style}}. Return strict JSON {changes[{area (MEASUREMENT|FABRIC|TRIM|PRINT|PACKING|LABEL), field, old_value, new_value, delta_cm, status (CHANGED|ADDED|REMOVED), source_quote}], unchanged_confirmed: bool}. Quote old_value and new_value verbatim from the documents — if a value is not stated in one of the two documents, set it null and flag it; NEVER infer or normalise a measurement, and never unit-convert. You produce a change list only: you do not accept the revision, do not estimate a date, and do not price anything.

Agent roles & model tiers

• Techpack diff agent — Premium tier — the hard step; a missed measurement change becomes cut fabric. Configure an economy fallback model so a provider outage degrades to a slower, flagged diff rather than a stalled buyer thread

  Field-level diff of revised vs approved techpack/BOM. Verbatim quoted old/new values, null (not guessed) for anything absent, explicit status per field. No acceptance, no dates, no costing.

• Materials assessor (parallel) — Standard tier

  Given the scored change list, state materials impact only: which fabric/trim POs are affected, what is already issued or in transit, what must be re-sourced, and the lead time each supplier document actually states. Cite the document; never invent a lead time.

• Production assessor (parallel) — Standard tier

  Given the scored change list, state production impact only: which cut/sew/finishing operations change, whether cut fabric is affected, whether a new PP sample or re-approval is required, and which line-plan slots move. No dates to the buyer — internal feasibility only.

• Costing assessor (parallel) — Standard tier

  Given the scored change list, state cost impact only, computed from the rate/BOM data supplied — per-unit material delta, extra operations, rework or write-off of committed material. Show the arithmetic. Never round into a 'ballpark' and never present this as a quoted price.

• Merchandiser supervisor — Premium tier — one call, and it produces everything the buyer will read

  Merge the three assessments into one draft buyer position: absorbable changes, changes that move the ship date, changes that carry a cost, changes not feasible at this order stage. Flag every conflict between assessors rather than resolving it silently. Output is a DRAFT for the merchandising manager to approve or edit — never phrase it as a confirmed commitment.

Guardrails

• The workflow never accepts a revision, commits a delivery date or quotes a surcharge — all three sit behind the Approval node for the merchandising manager
• Every diff row carries a verbatim source quote; a value absent from either document is returned null and flagged, never inferred — measurements are never normalised or unit-converted silently
• Severity comes from the tenant-authored `change_severity` formula, so the threshold is auditable, per-buyer and editable by the business — the model never decides what counts as absorbable
• The supervisor surfaces assessor disagreement instead of resolving it — a costing/production conflict reaches the human as a conflict
• The floor is briefed and the sampling sub-workflow is triggered only AFTER approval, so no line changes on the strength of an unaccepted revision

Cost strategy

One revision costs: 1 premium diff + 3 standard assessors in parallel + 1 premium consolidation. Parallel buys wall-clock time here, not money — the three assessors cost the same run sequentially or together. Keep the assessors on the standard tier and spend on the two premium calls that bracket them: the diff (where a miss is expensive fabric) and the consolidation (which is what the buyer actually reads). Set an economy fallback model on both premium roles so a provider outage produces a slower flagged answer instead of a dead buyer thread. Revisions are low-volume and high-stakes — the wrong place to economise.

Output & delivery

A quoted field-level change list → each row scored by the tenant's own `change_severity` formula → three parallel impact assessments → one consolidated draft buyer position → the merchandising manager approves or edits at the Approval node → the sampling sub-workflow is triggered if a fresh PP sample is required → an Output node replies on the buyer's email thread while a second Output briefs the floor on WhatsApp via Sarvam, and a Tool (MCP) node attaches the approved change note to the style in the ERP/PLM.

Build spec

2 agents — 1 comment-mapping agent + 1 sample-plan agent. The completeness gate, the clarification loop, the date formula and the approval are workflow nodes and tools. · Pattern: Extract → completeness gate → bounded clarification loop → plan → human commits the date

System prompt (paste-ready)

(Comment mapper) You map buyer sample comments to actions for {{style}} round {{round}}. Return strict JSON {actions[{comment_quote, area (MEASUREMENT|FIT|TRIM|CONSTRUCTION|FABRIC|PACKING), action, spec_point, priority (MANDATORY|ADVISORY), confidence}], unmapped[], contradictions[]}. Every action must carry the buyer's own words in comment_quote. If a comment is ambiguous, contradicts another comment, or you cannot tell which measurement point it refers to, put it in unmapped[] or contradictions[] — do NOT guess a spec point and do NOT drop it. 'Approved' is recorded only where the buyer explicitly approves; silence on a point is never approval.

Agent roles & model tiers

• Comment mapper — Premium tier — the accuracy-critical step; a mis-mapped measurement comment costs an entire sampling round and a week of calendar. Economy fallback model configured for outages

  Free-text buyer comments → one discrete action each, with verbatim quote, area, spec point and MANDATORY/ADVISORY priority. Ambiguous or contradictory comments go to unmapped[]/contradictions[], never to a guess. Silence is never approval.

• Sample-plan agent — Standard tier

  From the confirmed action list, produce the sample-room work order: revised spec points, pattern/trim actions in execution order, materials to be pulled, and an INTERNAL readiness estimate taken from the lead-time formula. Label the estimate internal-only — you never state a buyer-facing dispatch date.

Guardrails

• The buyer-facing dispatch date passes the Approval node — the formula's estimate is explicitly marked internal-only and is never sent as-is
• Completeness gate: every comment maps to exactly one action or lands in unmapped[]/contradictions[], and the round does not proceed — nothing is silently dropped
• Every action carries the buyer's verbatim comment, so the pattern master can always see what was actually asked for rather than someone's paraphrase
• Explicit approval only — a point the buyer did not comment on is never recorded as approved
• Clarifications are batched per round by the Loop node, so the buyer is never drip-fed questions across a week

Cost strategy

Per round: 1 premium mapping call + 1 standard planning call, plus a cheap re-run of the mapper on each clarification reply. The mapper earns the premium tier because it is accuracy-critical and runs a handful of times per style — not per unit. The plan agent is assembly work and sits on the standard tier; drop the clarification re-mapping passes to economy once the action list is largely settled. The date formula costs nothing — it is a SpEL expression, not a model call, which is precisely why the lead-time policy belongs there rather than in a prompt.

Output & delivery

Comments become quoted, prioritised actions → the completeness gate blocks on anything unmapped or contradictory → one consolidated clarification round per cycle → a sample-room work order with an internal readiness estimate from the tenant's own formula → the sampling head approves the buyer-facing dispatch date → an Output node issues the work order on WhatsApp via Sarvam and confirms the date on the buyer's email thread, with the round written back to the ERP/PLM sample tracker.

Build spec

2 agents — 1 defect-classification agent (every report) + 1 proposal agent (only reports that breach the band). The disposition rule is a user-defined SpEL tool, not an agent — deliberately, so it is auditable and editable per buyer. · Pattern: Voice/WhatsApp intake → in-language transcription → tenant-authored AQL formula → human lot decision → in-language response

System prompt (paste-ready)

(Classifier) You triage inline QC reports from a garment line. From the transcribed report, return strict JSON {defect_class, severity (CRITICAL|MAJOR|MINOR), lot_ref, bundle_range, sample_size, defects_found, missing_fields[]}. Classify ONLY against the buyer's defect glossary and AQL plan in Knowledge. If sample_size or defects_found is not stated, put it in missing_fields[] and stop — do NOT assume a sample size and never estimate a defect rate. Ask the supervisor for the missing numbers in THEIR language. You never accept, rework or reject a lot; the disposition band comes from the factory's own rule and the decision belongs to the QA head.

Agent roles & model tiers

• Defect classifier — Economy tier — runs on every floor report, including the majority that turn out to be within tolerance

  Transcribed report → defect class, severity, lot/bundle refs and the two numbers that matter (sample size, defects found). Missing numbers are asked back in-language, never assumed. No lot decision.

• Lot-proposal agent — Standard tier — runs only on reports the AQL formula bands as REVIEW or REJECT_REWORK. Economy fallback model so a provider outage still produces a flagged, human-readable case

  Draft the lot proposal with the arithmetic visible: sample size, defects found, the documented AQL limit applied, affected bundle range, recommended action and the specific rework operation. Cite the AQL clause. Present as a recommendation awaiting the QA head.

Guardrails

• No lot is ever accepted, reworked or rejected by the workflow — the QA head's Approval is the only path to a disposition, and the line is told only after that
• The disposition band comes from the tenant-authored `lot_disposition` formula against the buyer's documented AQL limit — the model never sets the threshold, and the rule that was applied is recorded with the decision
• Missing sample size or defect count blocks the proposal and is asked back to the supervisor in their own language, rather than being assumed
• Both the inbound transcription and the outbound decision stay in the supervisor's language — the English structured record exists for the office and the audit log, not for the floor
• Knowledge is scoped per buyer, so one buyer's AQL plan can never be applied to another buyer's lot
• Every decision is written back against the lot id, keeping the quality log auditable for the buyer's own inspection

Cost strategy

This is the one recipe here with real per-event volume, so tiering carries weight: the classifier runs on every floor report and belongs on the economy tier, while the standard-tier proposal agent runs only on the minority of reports the formula bands as REVIEW or REJECT_REWORK — the SpEL tool plus the Condition node is what keeps that ratio honest, and it costs nothing to evaluate. Transcription is billed per voice note and is the entire reason the floor participates at all.

Output & delivery

A WhatsApp voice note in any supported Indian language → Sarvam transcription → economy-tier classification against that buyer's AQL plan → the tenant's own `lot_disposition` formula bands it → PASS is logged as an advisory, REVIEW/REJECT_REWORK escalate (and optionally flag a registered line device) → a numbers-shown proposal → the QA head approves on their phone → the decision returns to the line group in the supervisor's language and is logged against the lot in the ERP.

Build spec

2 agents — 1 document checker (once per checklist line via the Loop) + 1 reducer that writes the readiness report. Loop, Knowledge and Approval are workflow nodes; the urgency band is a SpEL tool. · Pattern: Map-reduce over the checklist → tenant-authored urgency banding → owner-wise routed chase → human releases the pack

System prompt (paste-ready)

(Checker) Verify ONE audit-checklist line for an audit on {{audit_date}} under standard {{standard}}. Return strict JSON {checklist_item, status (PRESENT_VALID|PRESENT_EXPIRED|WRONG_PERIOD|MISSING|UNREADABLE), doc_ref, valid_until, covers_period, owner_dept, note}. Compare valid_until against {{audit_date}} — a document expiring before the audit date is PRESENT_EXPIRED even if it is valid today. If a date is unreadable or the file is a scan you cannot parse, return UNREADABLE; never assume a document is valid because it exists, and never infer a validity period that is not printed on it.

Agent roles & model tiers

• Document checker (per checklist line) — Economy tier — runs once per line across the whole checklist, so its tier sets the cost of the run

  One checklist line → presence, version, validity-vs-audit-date and period coverage, as strict JSON with the document reference and owning department. UNREADABLE rather than assumed-valid. No pack-level judgement.

• Readiness reducer — Standard tier — reasoning. Economy fallback model so the report still lands during a provider outage, flagged as degraded

  Aggregate the per-line verdicts into a readiness report: ready, expiring before the audit date, missing, unreadable. Split gaps by owning department, attach the renewal lead time each documented SOP states, and flag any gap whose lead time exceeds the days remaining. Use only the verdicts supplied — never assert a document exists that no verdict covers.

Guardrails

• Nothing is submitted to the buyer or uploaded to the audit platform before the compliance head's Approval — the pack is a formal representation about the factory
• Validity is arithmetic against the audit date, not against today; a certificate expiring mid-window is reported as expired, and the urgency band comes from the tenant's own formula
• A document that cannot be parsed is UNREADABLE and gets chased — never counted as present
• The reducer may only report on lines a checker actually returned; an absent verdict is a gap, never an assumption of compliance
• web_search results are treated as leads for a human to verify, never as an authority that changes the checklist — the checklist of record stays in Knowledge
• Gap lists are routed per owning department in that owner's own channel and language, so accountability is individual rather than a group broadcast

Cost strategy

Cost is linear: N checklist lines × economy-tier checker + ONE standard-tier reduce. The checker's tier is the dominant lever because it runs across the whole checklist — and its job is deliberately narrow (presence, version, two date comparisons) precisely so it can stay there. The urgency banding is a SpEL expression and costs nothing, which is the right home for a policy that changes per standard. Run the map in Parallel batches to compress wall-clock time without changing per-line cost.

Output & delivery

The checklist for that standard is mapped line by line by a cheap checker → each verdict banded by the tenant's own `renewal_urgency` formula → a reducer produces the readiness report and an owner-wise gap list with lead times → each owner is chased on WhatsApp via Sarvam or Email → the compliance head releases the assembled pack at the Approval node → only then does a Tool (MCP) node upload it to the buyer's audit platform.