Tell me about pushing back on a 'just add an agent' request.
- 1 min — the request and its context
- 2 min — task analysis, prototypes, the comparison
- 1 min — persuading the requester
- 1 min — results, the reusable rule, regret
The interviewer is checking that you choose the simplest system that meets the need — a workflow before an agent — and that you can say no in a way that still delivers the outcome the requester wanted.
Requests for an agent often hide a well-defined workflow. The pushback should be a prototype comparison, not an opinion.
Staff answers set a reusable decision rule for the org — when to use an agent vs a workflow — so the next twenty requests don't need a debate.
What the answer sounds like at each level
Suggested a simpler implementation than the one requested for a feature they owned.
Ran a prototype comparison and delivered the requester's outcome with a simpler, safer design.
Turned the debate into an org-wide decision checklist and changed how agent requests are triaged.
Follow-ups the interviewer will push
1When would you have built the agent?
If the paths were open-ended and couldn't be enumerated — say, a long tail of supplier formats needing exploratory tool use — and the actions were reversible or approval-gated.
2How did you avoid looking like you were blocking innovation?
I built a prototype of both and let the numbers decide, with my colleague's agent version evaluated fairly on the same 300 invoices.
Red flags interviewers listen for
- Says no without an alternative.
- Dismisses agents entirely rather than stating when they fit.
- No evaluation behind the recommendation.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Judgement | Task structure analysed before choosing architecture. |
| Evidence | Head-to-head prototypes on the same data with cost. |
| Leverage | A reusable decision rule for future requests. |
A workflow instead of an invoice agent
Illustrative exampleOur finance director asked for an autonomous agent to process supplier invoices end to end — read the PDF, match it to a purchase order, and approve payment — after seeing a vendor demo. Volume was ~7,000 invoices a month and a mismatch cost real money.
I led the AI engineering group of seven. I had to decide what to build and, if not an agent, persuade the director.
I mapped 300 historical invoices with an AP clerk: 88% followed one of four fixed paths (exact PO match, partial delivery, price variance under 2%, missing PO). That's a workflow, not an open-ended task. I built a two-day prototype: an extraction step with structured output, deterministic matching rules, and an LLM only for line-item reconciliation, with every payment above $5,000 routed to human approval. On the 300 invoices it was correct on 94% versus 81% for an agent prototype my colleague built in parallel, at a tenth of the cost. The director's concern was that it wouldn't handle the odd 12%; I routed those to a clerk queue with the extraction pre-filled.
Shipped in five weeks. Clerks' handling time fell from 11 to 4 minutes per invoice on average across ~7,000 a month, with zero erroneous payments in the first quarter. We wrote an agent-vs-workflow checklist that the group now uses for every request. My regret: I framed my first reply as 'agents are risky', which put the director on the defensive; leading with the prototype comparison would have saved a week.