Designing an End-to-End Agent Workflow
Transform vague customer requests into a defined workflow by identifying users, current steps, error costs, and measurable success criteria. Choose which steps require a model and enforce identity, authorization, output validation, and resource budgets in application code. Keep consequential decisions with operators, and route invalid or incomplete results to manual review. Start with a fixed workflow, then consider agents only when evaluation justifies their complexity. Define stopping conditions, release gates, operating ownership, and fallback procedures before proposing deployment.
We'll cover the following...
“The customer wants an agent that closes tickets. Walk me through what you’d build.” System Design rounds often open with a request this vague, and the interviewer watches what you ask before you draw a box. Strong answers turn the request into a workflow first: who does the work today, what a mistake costs, which steps need a model, and which steps plain code already handles. Only then do they decide whether the system needs an agent at all.
Northstar’s request is exactly that kind: “Handle service requests automatically and close the easy ones.” The first design decision is what Northstar should allow the system to do.
What does the work look like today?
Recall Northstar’s baseline: 18,000 service requests a month, nine minutes of handling time each. An operator reads the incoming note, checks the authorized service record, classifies urgency, drafts a response, and decides whether to escalate or close the request.
Start discovery with the operators who do that work, plus the service-operations owner and the customer engineering owner. Ask which operators handle incoming requests and where they see their work; what they check before deciding urgency or closure, and where requests wait; what happens if an out-of-service request is closed too early, and what an extra review costs; who defines correct triage, controls access to records, supports failures, and approves launch; and which requests enter the pilot and where handling time starts and stops.
This is delivery work as much as model selection. OpenAI’s FDE role description includes discovery, technical scoping, System Design, build, and production rollout with customer engineering and domain teams, and it measures success partly through workflow impact.
Which mistake is expensive?
Northstar reviewed 24 historical requests offline. Six described equipment out of service, and an automatic-close proposal marked three of those six as resolved. No live ticket was closed.
The two kinds of error carry very different costs. A premature closure buries a request whose equipment needs attention. An unnecessary review costs an operator a few minutes, but the request stays visible to someone who can act on it. Choose the release boundary before you consider any implementation.
Three misses out of six is a finding about the proposed closer, not a production failure rate. Investigate why those notes were misread, and keep automatic closure out of the first release in the ...