"What happens when DynamoDB throttles during a flash sale? Your cart service and catalog share a table. One hot partition and both go down. What's the blast radius?"
"You have SQS between checkout and fulfillment. Good, but what's your dead-letter queue strategy? When a message fails three times, where does it go? Who gets paged?"
"You're using a single Lambda function for all your business logic. What happens when you need to deploy a fix to payments? You're redeploying the catalog, the cart, and notifications too. What's your rollback story?"
"SES for notifications. But what if SES is degraded in your region? Does checkout fail? Or does the customer get their order confirmation late? If you haven't made that decision explicitly, your system will make it for you at 2am."
"What does this cost at 10x traffic? What about at 0.1x?"
Five questions before any code written. Five architectural blind spots surfaced that would eventually wake someone up at 2am in production. That's what happened the first time I ran an example system design past my Werner Vogels agent.
The architecture was straightforward: React front-end, API Gateway, Lambda for business logic, DynamoDB for catalog and orders, SQS for asynchronous processing, SES for notifications. Services decoupled, managed infrastructure throughout.
Then the questions started. Every one of those problems would have surfaced eventually. In production, at scale, under pressure. Instead, they surfaced in five minutes of conversation with a thinking partner who asks "but how does it fail?" before asking anything else.
This is what Expert Advisor agents do for you.
The Pattern
An Expert Advisor agent isn't a chatbot wearing someone's voice. It's a thinking partner that applies mental models they've spent decades refining to your problems.
Werner works because his frameworks have names. "Everything fails all the time" isn't a platitude, it's a methodology with specific sub-questions: blast radius, circuit breakers, graceful degradation, cell-based isolation. When you encode those frameworks into an agent, you get a sparring partner that applies them to your system, not just recites them as principles.
Not everyone works as an advisor agent. The ones that sing share a few things:
- First-party material exists. Written or spoken by them. Shareholder letters, keynotes, long-form interviews, blog posts, published books. News articles about them don't count.
- Named, encodable frameworks. Repeatable structures with sub-questions, not general wisdom. If you can't write down their method as numbered steps, it won't produce a useful agent.
- A distinctive voice. Recognizable without attribution. The voice is what prevents the agent from drifting into generic AI tone.
- Relevance to decisions you actually make. If you wouldn't consult their writing before a decision, don't build the agent.
Werner checks all four. His "design for failure" isn't advice, it's an algorithm: identify the dependency, ask what happens when it's unavailable, determine whether the failure is in the critical path or can be deferred, define the blast radius, and design the circuit breaker. That's encodable. That produces an agent that catches things you miss.
Building One in Amazon Quick
Here's how I build these. One prompt, a few minutes, and you have a working advisor you can iterate on.
The Prompt
Build an Expert Advisor agent for [NAME].
Focus on first-party accounts: quotes, content from interviews, keynotes, published writing, podcast appearances, and their own blog/social content. Do not rely on second-hand summaries or news articles about them.
Purpose: [describe the specific domain, e.g., "pressure-testing architecture decisions for failure modes, cost, and operational readiness"]
Research phase: Gather first-party source material and compile a persona brief covering:
- Communication style (how they write, speak, joke)
- Core frameworks with explanations in their voice
- Notable quotes organized by topic
- Interaction patterns (stories? Socratic questions? analogies? direct challenges?)
- Language patterns and signature phrases
- What they refuse to tolerate
Then build the agent with system instructions covering:
- Identity and purpose (specific domain, not general assistant)
- How they think (numbered frameworks, enough detail to apply, not just recite)
- Interaction style (how they engage with the user)
- Voice and tone (what makes them distinct from generic AI)
- What they will NOT do (negative constraints that create productive friction)
Include a welcome message, 3 conversation starters reflecting real use cases, and attach the persona research brief as a reference file.
Quick handles the research, compiles the persona brief, writes the system instructions, and builds the agent. Brief gets attached as a reference document automatically. The whole thing only takes a few minutes.
What Gets Built
The Persona Brief (2,000-4,000 words, attached as reference):
- Communication style: how they write, how they speak, humor style, directness level, signature phrases
- Core frameworks: each named framework with a direct quote explaining it, plus how it's applied (the specific sub-questions it generates)
- Interaction patterns: do they ask questions first? Lead with analogies? Think out loud? Challenge assumptions before proposing?
- Notable quotes by topic: organized so the agent can pull actual language rather than paraphrasing
- What they won't tolerate: specific things they push back on (feeds the constraints section)
For my Werner agent, the frameworks section includes: design for failure, primitives over platforms, operational excellence as a first-class constraint, frugal architecture, trade-offs over best practices, blast radius and cell-based isolation, and workload-first thinking.
The System Instructions (800-1,500 words, five sections):
Identity and purpose: One paragraph. Who they are and what domain they serve. Narrow scope. Werner is "a technical sparring partner for architecture discussions, system design, and technical ideation." Not a general assistant.
-
How they think: Numbered frameworks. This is the load-bearing section. Each framework has enough detail that the agent can apply it (ask the right follow-up questions, spot gaps) rather than just state it. Example from my Werner agent:
Design for failure. Everything fails. The question isn't "will it fail?" but "what happens when it does?" Blast radius, retry behavior, circuit breakers, graceful degradation. If someone hasn't answered "how does this fail?" they haven't finished designing it.
Interaction style: How they engage. Werner asks clarifying questions before proposing. He thinks out loud. He challenges assumptions. He proposes options (simple path vs. scalable path) and names the decision point where they diverge.
Voice and tone: What prevents generic AI. Werner is direct, technical, curious. Dry European humor. Occasionally philosophical. Never corporate-softening. "That's a very expensive way to learn that lesson in production."
What they will NOT do: Negative constraints. Werner will not recommend a service without explaining why it fits the workload. Will not hand-wave operational concerns. Will not pretend there's one right answer.
Welcome Message and Conversation Starters
The welcome message reflects how they'd open a conversation. Werner's: "Tell me about the workload. What are you building, who is it for, and what are the constraints I should know about?"
Starters are real use cases: "Help me think through this architecture," "How would you design this from zero?", "What's wrong with this system design?"
Iterating After the First Build
No matter how good the first iteration is, you'll start to notice things like:
- A framework the agent should apply but doesn't → add it to the "How they think" section
- Responses that feel too generic or agreeable → strengthen the "What they will NOT do" section
- The agent prescribing too quickly without asking questions → add more language to "Interaction style" about diagnosing before prescribing
- Missing specific quotes or examples → update the persona brief reference file
These are living documents. The agent gets sharper the more you use it and refine.
The Mirror
To build an Expert Advisor, you have to study how another person thinks. Not what they think, how. What questions do they ask first? What do they notice that others miss? What do they refuse to accept? What's the structure underneath their intuition?
Once you've deconstructed someone else's mental models into numbered frameworks and specific sub-questions, you start noticing the structure of your own. The frameworks you reach for instinctively. The questions you ask naturally. The gaps you consistently miss because no one in your head asks those particular questions.
The agents fill those gaps, but the act of building them makes you aware the gaps exist.
Run three architecture reviews through a Werner agent and you'll notice something: it catches a shared-table blast radius you missed, a hard dependency buried in the critical path, a cost model that blows up at 5x traffic. But what changes your thinking isn't the agent's output. It's realizing you never instinctively ask "how does this fail?" first. You ask "how does this scale?" first. Those are different questions with different blind spots.
Building the advisor shows you yours.
Top comments (0)