Halfway through a design review, an architect explains why she picked a multi-agent pipeline over a single long-context call. Two minutes later, the VP interrupts: are we spending more or less than last quarter? The architect never finishes her sentence about context windows. That gap, between what an architect optimizes for and what a stakeholder actually asked, is the whole problem with how technical teams pitch AI systems.
In this article:
I sat the Claude Certified Architect exams earlier this year, and wrote about that week separately [1]. The domain that stuck with me wasn’t the one on retrieval or evaluation. It was the domain on stakeholder communication, mostly because it’s the one domain architects tend to treat as a soft skill rather than a design constraint.
Stakeholder Communication and Lifecycle Management makes up 14% of the Claude Certified Architect Professional exam [2][3], which puts it roughly on par with governance and risk management, and only a few points behind integration work. That weighting comes from third-party exam-prep summaries rather than Anthropic’s own published exam guide, which I could not locate as a fetchable primary document during this research; I’m flagging that distinction here and again in the Sources section below, because a 14% figure sourced secondhand is a claim, not a fact.
What the same third-party material does describe clearly is a framework worth stealing regardless of where you got it: present architecture decisions along three levers, capabilities, cost and speed, and safety and security [2]. Each lever maps to a question a non-technical stakeholder already knows how to ask. Capabilities answers “what can this system actually do.” Cost and speed answers “what does this cost us and how fast is it.” Safety and security answers “what happens when it’s wrong or attacked.” None of those questions require the listener to know what a token is.
The workflows-versus-agents decision is a good test case because architects tend to explain it backwards [4]. The technical framing starts with control flow: a workflow is predetermined code paths, an agent is a model directing its own tool calls in a loop, and the tradeoff is between predictability and flexibility. A stakeholder doesn’t have a strong opinion about control flow. What they have an opinion about is whether the system can handle a case nobody anticipated, and whether that flexibility is worth the loss of a guaranteed path through the logic.
So the capabilities lever reframes the same decision as a coverage question. A workflow-based system will do exactly what you specified, and nothing else, which is a feature when the task is well understood and a liability when it isn’t. An agentic system trades that ceiling for the ability to improvise, at the cost of being harder to fully test in advance. Once that’s the framing, the follow-up question a stakeholder asks changes from “why not just use the smarter model everywhere” to “how well do we actually understand this task,” which is the question that should have been driving the architecture choice in the first place.
The same reframing works for context management. An architect explaining why a system’s accuracy degrades as a conversation grows longer is describing context rot, the tendency for a model’s attention to get diluted across an overstuffed context window rather than the window simply running out of room [5]. A stakeholder doesn’t need the internals. They need to hear that longer isn’t automatically better, and that the fix usually costs engineering time, not just more compute budget.
Cost and speed is the lever most architects think they’ve already covered, because they’ve priced out the tokens. What they usually haven’t done is connect the price tag to a tradeoff the stakeholder can weigh against something else they care about. Choosing a larger model over a smaller one isn’t just a line-item increase, it’s a bet that the accuracy gain is worth the latency and dollar cost at the volume you’re actually running [6]. Choosing to prompt-cache repeated context isn’t an optimization detail, it’s the difference between a support bot that’s affordable at ten thousand daily conversations and one that isn’t.
The number that actually moves a budget conversation is a per-unit cost at realistic volume, not a headline price per million tokens. That’s the same argument I made when I broke down when it’s worth paying for a larger Claude model versus a smaller one [7]: the model choice is a cost curve, not a single number, and stakeholders fund cost curves, not model names.
Safety and security is the lever where architects tend to over-promise, because “we have guardrails” sounds reassuring and specific in a way that “we have tested this against known attack patterns and it still fails sometimes” does not. Prompt injection is the clearest example: it’s a real, documented risk class for systems that let a model process untrusted text or browse the web, not a hypothetical [8]. A stakeholder who hears “guardrails” pictures a wall. What you’re actually offering is closer to a set of tripwires and a monitoring process, which is a different and more honest thing to promise.
The honest version of the safety pitch names what you tested, what you didn’t, and what the plan is when the guardrail fails rather than holds. That’s a harder pitch to give than “it’s secure,” but it’s the one that survives the first incident, because you never claimed the wall was load-bearing.
The lifecycle half of this domain is the part architects skip most often, because a design review feels like the finish line. It isn’t. An architecture that gets approved on a set of assumptions about traffic, task distribution, and acceptable error rates needs a mechanism for someone to notice when those assumptions stop holding. That mechanism is usually a feedback loop tied back to the same three levers: capability drift shows up as more edge cases slipping through, cost drift shows up as the per-conversation number creeping past what was budgeted, and safety drift shows up as a new failure mode nobody tested for.
Framing the pitch this way going in, as a set of levers you’ll keep reporting on rather than a decision you’re defending once, changes the nature of the meeting. Stakeholders stop treating the review as a one-time approval gate and start treating it as the first checkpoint in an ongoing conversation, which is a more accurate description of what a production AI system actually is.
If you enjoyed the article and wish to show your support, make sure to: The Three Levers That Get AI Architecture Approved was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.