Stakeholder Communication & Lifecycle Management

Knowledge of

• The primacy of eliciting the business outcome before constraints (latency/SLA, volume, criticality, data sensitivity, cost ceiling, quality bar)
• The need for structured questions that surface non-functional requirements stakeholders may not volunteer (regulatory context, data residency, peak load, failure tolerance)
• The distinction between must-have outcomes (needs) and preferred implementations (wants), and why preserving that distinction leaves room for the right tradeoffs
• Validating requirements by reflecting them back to stakeholders and confirming before design begins
• Discovery output as a shared, agreed statement of what success means -- the anchor every later tradeoff is justified against

Skills in

• Eliciting the business outcome first, then systematically working through non-functional constraints with stakeholders
• Asking structured questions that surface regulatory context, data residency, peak load, and failure-tolerance requirements that stakeholders do not volunteer unprompted
• Separating stated wants from underlying needs to preserve design flexibility for the architecture phase
• Reflecting requirements back to stakeholders and securing explicit confirmation before starting architectural design
• Recognizing when a solution is being proposed before discovery is complete, and pausing to close the gap rather than proceeding

Knowledge of

• Framing a tradeoff in the stakeholder's language as the core communication skill of an architect
• Anchoring on the constraint that matters most to a given stakeholder -- cost, latency, quality, or risk -- and connecting the decision to it
• Anthropic's own framing of agentic complexity as a tradeoff of latency and cost for capability, as a template for stakeholder tradeoff conversations
• Shared vocabulary (context engineering, retrieval, model tiers) for technical stakeholders, and the need to translate it into outcomes and costs for non-technical audiences
• Presenting options with an explicit recommendation rather than a single unquestionable verdict

Skills in

• Anchoring tradeoff conversations on the business-value pillar (cost, latency, quality, risk) that matters most to a specific stakeholder
• Explicitly naming what is gained and what is paid ("we gain X, we pay Y") when presenting an architectural decision, rather than presenting only the chosen design
• Translating technical vocabulary (context engineering, retrieval, model tiers) into outcome-and-cost language for non-technical audiences
• Presenting multiple viable designs with a clear tradeoff comparison and a named recommendation
• Avoiding jargon-heavy or single-option presentations that prevent stakeholders from meaningfully aligning on a decision

Knowledge of

• Expectation management as a continuous activity, not a one-time sign-off
• Realistic SLA-setting grounded in what the chosen model tier, retrieval steps, and infrastructure can actually deliver
• The probabilistic, non-deterministic nature of LLM systems and the need to set expectations around evaluation and monitoring rather than perfection
• The need to re-align expectations proactively when a model version, data change, or scaling need shifts what's feasible
• Feedback loops as the mechanism by which stakeholders report issues, and how those reports feed prioritized iteration

Skills in

• Grounding SLA commitments in the measured latency/reliability capability of the actual chosen architecture (model tier, retrieval steps, infrastructure) rather than aspirational targets
• Establishing a defined mechanism for stakeholders to report issues that feeds into prioritized iteration
• Communicating the probabilistic nature of LLM output honestly, framing quality as evaluated and monitored rather than guaranteed
• Proactively re-aligning SLA and quality expectations with stakeholders when a model version change, data change, or scaling event shifts what the architecture can deliver
• Recognizing and avoiding commitments to SLAs the architecture cannot meet (e.g., sub-second latency on a multi-step agentic pipeline with reranking)

Knowledge of

• The components an architecture document must cover: components, data flow (input -> processing -> output -> feedback), chosen patterns, and the rationale behind each decision
• Implementation guidance as the actionable detail beneath the documentation: pinned model versions, prompt/Skill structure, integration protocols, retrieval configuration, guardrails, and eval/monitoring setup
• Recording decision rationale specifically so future maintainers understand which constraints a given choice served
• Documentation quality as the determinant of handoff success, the lifecycle phase that follows design

Skills in

• Documenting the full data flow (input -> processing -> output -> feedback) alongside the components and patterns chosen
• Recording the rationale behind each architectural decision, not just the decision itself, referencing the constraint it served
• Producing implementation guidance detailed enough to build from without re-deriving the design: pinned model versions, prompt/Skill structure, integration protocols, retrieval config, guardrails, and eval/monitoring setup
• Writing documentation and guidance to the standard required for a successful handoff to an implementation team

Knowledge of

• The five named lifecycle phases and the architect's role in each: discovery, design, handoff, monitoring, iteration
• The lifecycle as a loop, not a line -- monitoring and iteration feed back into design as requirements, data, and models evolve
• Handoff as the transfer of the design together with documentation and implementation guidance
• Monitoring's role in ensuring observability/eval are in place, and watching quality, latency, and cost against SLAs
• The risk of treating design as "done" at handoff, given non-determinism, model updates, and data drift

Skills in

• Mapping each of the five lifecycle phases (discovery, design, handoff, monitoring, iteration) to the concrete deliverables and responsibilities it requires
• Ensuring observability and evaluation are in place at handoff so monitoring can track quality, latency, and cost against agreed SLAs
• Feeding monitoring findings and stakeholder feedback back into the design phase as an iteration loop, rather than treating handoff as an end state
• Recognizing that non-determinism, model updates, and data drift require ongoing monitoring and iteration to keep an architecture within its SLAs
• Connecting the lifecycle loop to the stakeholder feedback loops and SLA re-alignment practices used elsewhere in the engagement