4.2 — Spotting a Genuine AI Automation Opportunity · Core
Strong candidates have clear, consistent inputs, well-defined outputs, and steps that can be precisely described and verified. Workflows needing constant exception judgment outside any written policy are lower-feasibility until that judgment is scoped.
Attention dilution: passing too many items into one request (14+ files in a single review pass) produces uneven depth and self-contradiction across items. A bigger context window does not fix this — decomposition does (per-item passes + a separate integration pass).
The POC-to-production gap: a demo on 20–50 clean inputs hides four things production reveals — real cost distribution (a long tail of large requests can make an average-based cost model underestimate total spend by 2–3×), p95 latency under concurrent load, the need for retry logic, and edge-case input formats the demo never saw.
⚠ Often-missed — Building Before Discovery Is Complete · Gap
Starting to design or build before all five discovery outputs exist is a Foundations-level mistake, even when it looks like it saves time. Constraints not yet gathered (a HITL authorization requirement, a PHI handling rule) surface later — during compliance review or after launch — at exactly the point where changing direction is most expensive. A correction during discovery costs a conversation; the same correction after build costs weeks.
4.3 — Designing a Multi-Step Solution · Core
Three design questions, every time:
- How are tools connected? Direct API/SDK for a single application; MCP when the same capability must be reused across multiple surfaces ("build once, expose everywhere" — adding MCP with no reuse requirement is needless overhead).
- How is step order enforced? A prompt instruction ("always do Step 1 first") is probabilistic and has a documented non-zero failure rate. A programmatic prerequisite gate — code that checks Step 1's result is present and valid before Step 2 runs — is deterministic. Use the gate whenever the ordering has financial, safety, or compliance consequences; strengthening the prompt language ("MUST", "MANDATORY") does not close the gap.
- What happens when something breaks? Retry with exponential backoff around transient errors (429/5xx/timeouts); checkpoints after each major step so a crash resumes from the last completed step, not from zero.
A complete handoff to a human must include: customer ID, root-cause analysis, the relevant amounts, and a recommended next action — the handoff is the recipient's only context; they should never need to re-investigate from scratch.
4.4 — Communicating the Design to Stakeholders · Core
Every significant decision needs four elements — the reversal-cost question is the one most often skipped:
- What do we gain?
- What do we give up?
- What does it cost to reverse this later if we're wrong?
- What does this do to our compliance posture?
Translate every metric into business terms: "adds $0.008/request but lifts first-contact resolution 12 points," not "2× better benchmarks." Never commit to "always correct." Commit to a named accuracy figure on a defined eval set plus a remediation path for the error budget ("95% accuracy; the 5% error budget routes to human review").
Lifecycle order is fixed and non-negotiable: Discovery → Design → Build/Handoff → Monitoring → Iteration. A correction during discovery costs an hour; after build, weeks.
Exam reflexes for Domain 4
- Stakeholder says "seamless" / "easy" / "fast" → ask what would make it feel the opposite; don't assume a number.
- "What must the system NOT do" not yet asked → the category stakeholders never volunteer — ask explicitly.
- Design or build starts before all five discovery outputs exist → wrong, regardless of time pressure.
- "Must guarantee step ordering" (refund, compliance, safety) → programmatic gate, not a prompt instruction.
- Single application, no reuse need → direct API. Reused across multiple surfaces → MCP.
- Cost model built from average request size → check the long tail; averages underestimate skewed distributions.
- Missing current-process baseline before launch → no retroactive fix; improvement claim can't be verified.
- SLA commitment phrased as "always correct" → wrong; commit to a measured rate + remediation path.