Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Mostly a workflow. Supplier onboarding has a known sequence (collect documents, verify tax and bank details, check sanctions lists, set up in the ERP), so the steps should be fixed code. Use models inside the steps that handle messy input: reading uploaded documents, extracting fields, and drafting follow-up emails. Reserve agent-style autonomy for the narrow exception-handling step, if it earns it.
How to approach it
Define the terms in one line each: a workflow follows transitions you designed; an agent decides its own next step. Then ask about the process. Is the sequence the same for every supplier? Where does it get stuck today? Which steps involve money or compliance? The answer comes from mapping the process, not from the technology.
A strong answer
Map the current process first. For a marketplace or retailer it typically looks like this: the supplier submits a form and documents; someone checks the tax registration (GST in India, VAT in Europe), bank details, and identity; someone screens against sanctions and internal blocklists; someone sets the supplier up in the ERP with payment terms; and someone chases missing or unclear documents, which is where most of the delay sits.
Now ask, step by step, whether the next action varies in ways rules cannot capture.
| Step | Varies unpredictably? | Design |
|---|---|---|
| Collect form and documents | No | Fixed form, upload |
| Read documents, extract fields | Yes: formats, scans, languages | Model inside a fixed step |
| Verify tax ID and bank account | No: call the registry or verification API | Code |
| Sanctions and blocklist screening | No, and must be auditable | Code plus human review of matches |
| Create ERP record | No | Code |
| Chase missing information | Somewhat: depends on what is missing | Model drafts the message; workflow sends it |
| Handle odd cases (mismatched names, unusual entity types) | Yes | Human, or a constrained agent later |
Most of the process is deterministic, and it should stay that way. Money and compliance steps need to be predictable and auditable: a regulator or auditor asking "why was this supplier approved?" needs a fixed trail, not a model's reasoning. Fixed transitions also make the system easy to test, cheap to run and fast.
The stakes on those two steps are concrete. Changed bank details are the classic route for payment fraud: the FBI's 2025 Internet Crime Report records about $3.05 billion of reported business email compromise losses in 2025. A bank account is verified against the registry or the bank, in code, every time. Sanctions screening has its own failure history: the US Treasury's OFAC compliance framework (2019) lists screening software that "did not account for alternative spellings of prohibited countries or parties" among the causes of violations. That argues for tested matching logic plus human review of near-matches, with nothing improvised.
The model earns its place in two spots. Document extraction turns a scanned GST certificate or a bank letter in any format into structured fields, which is exactly the messy-input work models are good at. Drafting follow-ups turns "PAN missing, bank letter name does not match" into a clear, polite message in the supplier's language.
This matches the advice the model providers themselves give. Anthropic's guide to building agents recommends "finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all." OpenAI's practical guide (April 2025) is the useful counterpoint: it names "difficult-to-maintain rules" such as vendor security reviews as a good fit for an agent, while saying that otherwise "a deterministic solution may suffice". Both point at the same step, the judgment-heavy exceptions.
Agent-style autonomy (the model choosing what to do next) only makes sense for the exception queue, and even there I would start with the model proposing a next step and a human approving it. If, after a few hundred cases, its proposals are accepted almost unchanged for certain exception types, those types can run automatically.
What this buys: predictable cost per supplier, an audit trail, and steps that can be evaluated separately (extraction accuracy, for instance, can be measured against a labelled set of documents). A free-roaming agent with access to the ERP would be harder to test, harder to explain to auditors, and more expensive for no gain on the steps that never vary.
I would reverse this if the process really did vary supplier by supplier, say a services marketplace where every onboarding involves different licences, insurance and negotiation. Then more of the routing decisions belong to a model, with tight tool permissions.
What interviewers probe next
"Leadership asked for 'an agent' specifically. How do you handle that?" Deliver the outcome they want (faster onboarding with less manual work) and explain that a workflow with model steps is how you get it reliably. Few leaders care about the label once they see the cycle time.
"How would you measure success?" Days from submission to active supplier, share of onboardings with no human touch, extraction accuracy, and zero sanctions misses.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Framing | Builds an agent because it was asked for | Distinguishes agents from workflows | Chooses the least autonomy per step, mapped from the actual process |
| Model placement | Model everywhere or nowhere | Uses the model for documents | Model on messy-input steps, code on money and compliance steps, human on screening matches |
| Path to autonomy | None | Mentions human review | Proposal-and-approval in the exception queue, promoted by exception type on evidence |
Common mistakes
Giving a model open-ended access to the ERP and payment systems because "agents can figure it out".
Treating "agent" as the goal rather than onboarding speed and accuracy.
Leaving compliance decisions to model judgment with no deterministic trail.