5. Case: multi-agent workflow¶

Advanced · 6 min read

The prompt: "Design a system that processes 20,000 supplier invoices a day. Invoices arrive as PDFs and email attachments. Extract the details, match each invoice to a purchase order, flag problems, get approvals, and post approved invoices to the ERP."

"Multi-agent" questions test judgement as much as architecture. (Background: Multi-agent patterns.)

5.1 Requirements¶

Functional	Non-functional
Extract vendor, GSTIN, line items, taxes, totals	20,000 invoices/day, same-day processing
Match to purchase orders and goods receipts	Field accuracy ≥ 99% on posted invoices
Flag duplicates, mismatches and tax errors	Never post twice; never post without approval
Route exceptions; post to the ERP	Every decision auditable

5.2 The estimate that reframes the problem¶

invoices, exception_rate, minutes_per_review = 20_000, 0.18, 3
llm_cost_per_invoice = 0.026                     # extraction + matching + explanations (placeholder prices)
print(f"LLM cost: ${llm_cost_per_invoice * invoices:,.0f}/day")
print(f"human review: {invoices * exception_rate * minutes_per_review / 60:,.0f} reviewer-hours/day")

Output

LLM cost: $520/day
human review: 180 reviewer-hours/day

The LLM is the cheap part. Human review time is the real cost, so the goal is a high straight-through rate (invoices posted with no human touch) without ever posting a wrong one.

5.3 Architecture¶

flowchart LR
    IN[Inbox / upload] --> Q[[Durable queue]] --> WF[Workflow engine<br/>state saved per step]
    WF --> X[Extractor agent<br/>vision + schema] --> V[Validator<br/>rules: totals, GST, duplicates]
    V --> M[Matcher agent<br/>PO and vendor tools] --> D{Decision<br/>policy in code}
    D -->|clean match| P[Post to ERP<br/>idempotency key]
    D -->|exception| H[Human review queue] --> P

The key insight: this is a deterministic workflow with agents only where judgement is needed (reading messy documents, fuzzy matching), not a team of autonomous agents. The steps are known, money moves, and every decision must be auditable, so the decision to post is made by code under explicit rules, with humans on the exceptions.

In the full GenAI System Design guide (PDF)

The full cost and throughput model, step by step, and reviewer staffing
Extraction you can trust: structured output plus validation rules (with the GST checks)
Durable state, resuming after crashes, and never paying an invoice twice
Designing the human review queue so it scales
Evaluation: field accuracy, straight-through rate, exception precision
Trade-offs, failure modes and model answers to the follow-ups below

See the full guide in the Store → · Get notified when it goes on sale ↓

Interview follow-ups¶

Why not let a team of autonomous agents handle the whole process?
How do you guarantee an invoice is never paid twice?
How would you increase the straight-through processing rate safely?

Next: 6. Trade-offs and capacity estimates Back to: GenAI System Design overview · Notes overview