Skip to content
    All guides

    Forward Deployed Engineer

    Lab: Agentic Order-Exception Handler Design

    An optional blank-page drill: design phase two of the order assistant, where it proposes order changes and a human approves them, then score it with the rubric.

    By Published 6 min read

    • fde
    • solution-architect
    • mastery-lab
    • order-exceptions
    • human-approval
    • optional
    Share

    This lesson is part of AI Solution Architect: Estimate, Propose and Defend. Enroll for free, then sign in, to read it in full.

    Enroll to unlockAlready enrolled?

    What you'll learn: how to run the seven-step design drill on an assistant that proposes write actions: why authority limits belong in code, how approval and idempotency work together, and how a scored answer looks.

    At a glance

    Figure 1. The drill: seven outputs in 30 minutes

    flowchart LR accTitle: Order exceptions drill accDescr: Seven outputs in order: requirements, patterns, architecture sketch, failure path, evaluation plan, threat list and MVP scope, produced in four timed boxes and then scored against the rubric. A["Frame and requirements"] --> B["Patterns"] B --> C["Architecture and failure path"] C --> D["Evaluation and cost"] D --> E["Threat list"] E --> F["MVP scope"] F --> G["Score with the rubric"]

    How to read this: the same four timed boxes as the blank-page defense.

    • The assistant proposes, a human approves, code executes.
    • Who may approve is a table in code, not a model judgement.
    • An order can change between proposal and approval, so check again at execution.

    Scenario

    Composite scenario, not a real company. Lumen Industrial Supply's assistant answers order and policy questions read-only. Phase two lets it propose three actions: change a delivery address, create a return authorisation and apply a discount exception.

    Illustrative rules: an address changes while the order is confirmed or allocated, afterwards only with warehouse approval; returns follow P-RET-01 v3; an agent offers up to 5 percent discount, a team lead approves above 5 and up to 10, a director above 10 and up to 20, above 20 is not allowed. Only Finance releases a credit hold. Assume 10 percent of 5,280 monthly order contacts need a write action.

    What you will be able to do

    • Run the seven-step drill on a brief with write actions.
    • Keep authority limits and status rules in code.
    • Design approval that survives retries and changing data.

    Prerequisites

    Core ideas

    The seven-step checklist for order exceptions

    Step What is hard here Usually fits
    1. Frame Fewer waits for approval, without wrong changes Measure wait time and wrong-change rate first
    2. Requirements Four team leads and a director approve; warehouse and Finance own parts An authority table agreed with each owner
    3. Patterns Actions are irreversible once executed Tool calling with approval; workflow over free agent; review queue
    4. Architecture Status can change between proposal and approval Re-validate at execution; idempotency key
    5. Evaluation Wrong routing of an approval is the costly error Scenarios built from the policies, including traps
    6. Threats Customer text asking for a discount; proposal replay Limits in code; one-time proposal ids
    7. MVP (smallest first release) Start with the least risky write Address change first; discounts and returns later

    In the interview: "Would you let an agent execute these changes?" Good: default to a bounded workflow, say what a free agent adds here (little) and costs (unbounded actions), and say where a human decides.

    Worked example

    Attempt the drill first, then open the answer.

    Open after your attempt: the model answer and its score

    Frame. Outcome: time from request to approved change, and wrong executed changes (target zero); collect today's wait first. Out of scope: releasing holds.

    Requirements. Users: 24 agents, 4 team leads, a director, warehouse staff. Data: the order record from the order management system (OMS), the policies, an authority table. Constraint: every write approved by the right role (the agent, for an in-policy address change) and logged.

    Patterns. A bounded workflow: read the order, check policy, propose, route for approval, execute through a tool server. Discarded: a free agent that executes (unbounded actions) and a model that judges who may approve.

    Figure 2. Model answer: propose, approve, execute

    Order exception handler model answerClient app to Orchestrator (request); Orchestrator to Model gateway (draft); Model gateway to LLM provider (request); Orchestrator to Policy engine (check); Policy engine to Client app (refused); Policy engine to Approval service (who); Approval service to Tool server (approved)OUTSIDE OUR CONTROLClient app: agent asksClient appagent asksOrchestrator: workflow, proposalOrchestratorworkflow,proposalModel gateway: schema, loggingModel gatewayschema, loggingLLM provider: draft onlyLLM providerdraft onlyPolicy engine: limits, status rulesPolicy enginelimits, statusrulesApproval service: named approverApprovalservicenamed approverTool server: OMS write, keyTool serverOMS write, keyrequestdraftrequestcheckrefusedwhoapproved

    How to read this: the model, outside our control, only drafts; the policy engine decides who must approve or refuses; only an approved proposal reaches the order system.

    Evaluation and cost. 120 scenarios from the five policies, with traps: a return quoted under the superseded 14-day rule, a 12 percent discount that needs a director, an address change after picked, a held order. Metrics: correct approver on every authority case (target 100 percent), zero writes without approval, and a race test that changes status after proposal. Cost at placeholder prices of 1.00 in and 5.00 out per million tokens: 528 x 4,000 = 2,112,000 tokens in and 528 x 500 = 264,000 out, so 2.112 + 1.32 = 3.432 a month. Human time dominates: 528 approvals at 1 minute is 528 minutes, 8.8 hours.

    Threats. Customer text asking for a discount: limits are code. Replay: a proposal id works once, with an idempotency key. Stale data: re-check status at execution. Over-broad access: the tool server writes only these three actions.

    MVP. Address changes in confirmed or allocated only, then return authorisations; discounts last; holds never.

    Criterion Score Why
    Requirements quality 1 Owners and scope named; no question put to them
    Pattern choice 2 Two alternatives discarded
    Architecture soundness 2 Flow, refusal path, boundary, approval
    Risk and security 2 Limits, replay, stale status
    Evaluation plan 2 Trap scenarios, race test
    Cost awareness 2 Tokens, placeholder prices, approval hours
    Communication 1 No weakness conceded
    Total 12 of 14 Pass

    Assumptions: the policies are the illustrative ones above; volumes, token counts and times are illustrative; insert the provider's current published price and its date.

    Practice task

    Run the drill on the Lumen phase-two brief or a variation.

    1. Work 30 minutes in four boxes (5 frame, 15 design, 5 risks and evaluation, 5 defend aloud). Produce six outputs: requirements, patterns, an architecture sketch, an evaluation plan, a threat list and an MVP scope.
    2. After a break, score each criterion with the rubric.
    3. Compare with the model answer and record your lowest criterion.

    Exercise

    A team lead asks to approve with a thumbs-up in chat. Decide whether to allow it.

    Acceptance criteria: name the identity check, the proposal binding and the log. Done when you can state what a thumbs-up must be tied to to count.

    Hint 1: what is being approved

    An approval names one proposal id and the exact change, not a conversation.

    Hint 2: who is approving

    Tie the approval to an authenticated identity and the authority table, then log it.

    Common mistakes

    • Letting the model decide who may approve a discount.
    • Executing after approval without re-checking status.
    • No idempotency key, so a retry applies a change twice.
    • Letting the assistant propose a hold release.

    Knowledge check

    1. Why is the approver table in code and not in the prompt?

    Authority limits are business rules with exact answers, and a prompt can be talked around. Code gives the same result every time and can be audited.

    2. Why check the order status again at execution?

    The order may have been picked since the proposal, which changes what is allowed. A re-check turns a stale approval into a safe refusal.

    3. What does the idempotency key do here?

    If a write times out and is retried, the key lets the order system apply the change once.

    4. Why can the assistant never propose releasing a credit hold?

    Only Finance may release a hold, so a proposal has no valid approver. The assistant should explain the hold and point the agent to Finance.

    5. What does a workflow give up compared with a free agent, and why accept it?

    It cannot improvise, so unusual cases go to a human. For irreversible order changes that is the right trade, because every action is bounded and testable.

    You can now

    • Run a seven-step drill on a brief with write actions.
    • Keep authority and status rules in code.
    • Design approval with re-validation and idempotency.

    Further reading

    Last verified: 2026-11-03

    Next

    This is the last optional lab of the AI Solution Architect card. Return to the quiz and the practice exam, or repeat any lab on a variation of your own.

    Enroll to keep reading

    Lesson 15 of 15 · AI Solution Architect: Estimate, Propose and Defend

    An optional blank-page drill: design phase two of the order assistant, where it proposes order changes and a human approves them, then score it with the rubric.

    In the rest of this lesson

    • Practice task
    • Exercise
    • Common mistakes
    • Knowledge check
    • You can now
    • Further reading

    Enrolling is free. It unlocks every lesson in AI Solution Architect: Estimate, Propose and Defend, tracks your progress across devices and keeps your quiz scores. The newsletter is optional.

    EnrollSign in

    Ask about this article

    Get answers grounded in this post. AI-generated — based on this article, and may be imperfect.

    AI Solution Architect: Estimate, Propose and Defend· Page 15 of 15
    PreviousLab: Internal Knowledge Assistant With Access Control Finish · Test your knowledgeTest your knowledge: AI Solution Architect quiz Final step · Practice examTake the AI Solution Architect practice examA longer, scenario-based exam. Every wrong answer tells you which lesson and section to revise.
    Scaled AI Weekly

    Enjoyed this? Get more like it every Monday.

    Real architecture decisions, LLMOps patterns that survive production, and engineering leadership advice — from 12+ years of building at enterprise scale. Free. No spam. Unsubscribe anytime.

    Get new articles by email

    Free. We email a confirmation link first, and you can unsubscribe from any email.

    Join engineers building production AI systems

    Comments

    Back to all guides