A clerk’s office needs a multi-step document-intake agent that OCR-checks filings, classifies them, and routes exceptions. Which orchestration approach fits that municipal workflow?
Select an answer to reveal the explanation.
Short Explanation
Multi-step intake is a relay race: OCR hands off to classification, then routing. Step Functions is the track official—each leg is visible, retryable, and does not vanish into one giant mystery prompt.
Full Explanation
A clerk’s office multi-step document-intake agent that OCR-checks filings, classifies them, and routes exceptions needs reliable orchestration. AWS Step Functions design patterns fit municipal workflows: each stage becomes a durable, observable, retryable state with clear handoffs, timeouts, and exception paths instead of an opaque prompt loop. That reliability matters when filings are legal artifacts and clerks must see where a case stopped.
Running every intake step as an untracked sequence of manual emails between clerks fails by concept: email chains are not observable state machines and drop retries, SLAs, and auditability. Collapsing OCR, classification, and routing into one unbounded recursive prompt with no state machine fails because long agentic loops lack deterministic checkpoints and complicate failure recovery. Storing filings only on a shared USB drive and skipping automated orchestration fails chain-of-custody, scalability, and security expectations for a clerk’s office.
Exam caveat: Step Functions orchestrates; it does not by itself guarantee OCR quality or correct legal classification—those remain model and human-review concerns. Use choice states and dead-letter or exception queues for low-confidence classifications rather than silently advancing filings.
Operational check: run a test filing through OCR → classify → route, force an OCR failure and confirm a retry or exception path, inspect execution history for each stage, and verify clerks can identify the stalled step without reading unstructured email threads.