Domain 6: Stakeholder Communication & Lifecycle Management
14% of examConduct structured discovery and requirement gathering with stakeholders
Key Points
- Elicit the business outcome before constraints -- constraints without an agreed outcome have no anchor.
- Use structured questions to surface non-functional requirements stakeholders won't volunteer unprompted (regulatory context, data residency, peak load, failure tolerance).
- Separate wants (preferred implementation) from needs (the must-have outcome) to preserve tradeoff flexibility.
- Reflect requirements back and confirm before design -- this produces the agreed statement of success.
- Jumping to a solution before discovery is complete is the classic exam trap for this task statement.
Decision Rules
When: A stakeholder proposes a solution before requirements are established
→Pause and close the discovery gap rather than proceeding.
When: A stakeholder states a preferred implementation
→Probe whether it's a want or the underlying need, to preserve design flexibility.
When: Requirements have been gathered
→Reflect them back to stakeholders and get explicit confirmation before starting design.
✗ Anti-Patterns to Reject
- Proposing a design before establishing agreed constraints (especially SLA and data sensitivity).
- Treating a stakeholder's preferred implementation as the requirement itself, losing tradeoff flexibility.
Communicate architectural decisions and tradeoffs to stakeholders
Key Points
- Anchor tradeoff conversations on the constraint that matters most to the specific stakeholder (cost, latency, quality, risk).
- Frame decisions explicitly as 'we gain X, we pay Y' -- Anthropic's own agentic-complexity guidance (latency/cost for capability) is the template.
- Never present a design as the only possibility, and never bury a tradeoff in jargon.
- Use precise technical vocabulary with technical stakeholders; translate to outcome/cost/risk for non-technical audiences.
- Present options with a named recommendation ('here are two designs, here's the tradeoff, here's what I recommend') rather than a single verdict.
Decision Rules
When: A stakeholder asks for a fully autonomous multi-agent system with a sub-second latency SLA
→Explain the latency/cost tradeoff of agentic complexity and align on an achievable SLA -- don't silently build something simpler or refuse outright.
When: Presenting a design to a non-technical executive
→Translate the tradeoff into outcome, cost, and risk with a recommendation, not raw token-cost formulas.
When: Presenting a design decision
→Name what is gained and what is paid, and offer at least one alternative considered.
✗ Anti-Patterns to Reject
- Presenting a single design as the only possibility, removing the stakeholder's ability to weigh in.
- Burying a tradeoff in jargon a stakeholder can't parse, which is functionally the same as not naming it.
Manage feedback loops, expectation alignment, and SLAs
Key Points
- SLAs must be grounded in what the chosen model tier, retrieval steps, and infrastructure can measurably deliver -- not aspiration.
- Be honest that LLM output is probabilistic -- frame quality as evaluated and monitored against a bar, not guaranteed perfect.
- Classic trap: promising sub-second latency on a multi-step agentic pipeline with reranking -- both add latency the SLA must account for.
- Expectation management is continuous, not a one-time sign-off at launch.
- Establish a defined mechanism for stakeholders to report issues that feeds prioritized iteration; proactively re-align expectations when a model version, data change, or scaling need shifts what's feasible.
Decision Rules
When: Setting an SLA
→Ground it in the measured capability of the chosen model tier, retrieval hops, and infrastructure -- adjust the architecture first if a non-negotiable SLA can't be met as designed.
When: A model version, data change, or scaling event shifts what's feasible
→Proactively re-align expectations with stakeholders rather than waiting for them to notice the gap.
When: Stakeholders need a way to report issues
→Establish a defined feedback mechanism that feeds prioritized iteration.
✗ Anti-Patterns to Reject
- Committing to an SLA (e.g., sub-second latency) that a multi-step agentic pipeline with reranking cannot meet.
- Treating expectation alignment as a one-time event at sign-off instead of a continuous activity.
Document architectures and provide implementation guidance
Key Points
- Architecture documentation covers components, data flow (input -> processing -> output -> feedback), patterns, and decision rationale.
- Implementation guidance is the actionable layer beneath documentation: pinned model versions, prompt/Skill structure, integration protocols, retrieval config, guardrails, eval/monitoring setup.
- Record the why behind each decision, not just the decision -- rationale tells future maintainers which constraints a choice served.
- Documentation quality directly determines whether the handoff lifecycle phase succeeds.
Decision Rules
When: Documenting an architecture
→Cover components, the full data flow, chosen patterns, and the rationale for each decision.
When: Handing off to an implementation team
→Provide actionable guidance (pinned versions, prompt/Skill structure, protocols, retrieval config, guardrails, eval/monitoring), not just the high-level document.
When: Recording a decision
→Capture the rationale/constraint it served, not just the decision itself.
✗ Anti-Patterns to Reject
- Logging decisions without their rationale, leaving future maintainers to unwind a choice without knowing what it protected against.
- Treating documentation as complete without the actionable implementation-guidance layer beneath it.
Support the solution across the discovery-to-iteration lifecycle
Key Points
- Five lifecycle phases: discovery, design, handoff, monitoring, iteration.
- The lifecycle is a loop, not a line -- monitoring and iteration feed back into design as requirements, data, and models evolve.
- Handoff requires documentation plus implementation guidance; monitoring requires observability/eval to already be in place from handoff.
- Treating design as 'done' at handoff is the classic exam trap -- non-determinism, model updates, and data drift demand ongoing monitoring and iteration.
- When monitoring shows an SLA breach, feed it into iteration and re-align with stakeholders, don't ignore it or silence the alert.
Decision Rules
When: Handoff occurs
→Ensure observability and evals are already in place so monitoring can function.
When: Monitoring reveals latency creeping past an agreed SLA (e.g., after a data-volume increase)
→Feed the finding back into iteration and re-align expectations with stakeholders.
When: Asked whether design is 'done' once handed off
→No -- non-determinism, model updates, and data drift require ongoing monitoring and iteration.
✗ Anti-Patterns to Reject
- Treating handoff as an end state instead of one phase in a continuing loop.
- Disabling monitoring or ignoring an SLA breach instead of feeding it back into iteration.