DEV Community: Patrick

Expert Advisor Agents: AI Sparring Partners Built from Real Frameworks

Patrick — Fri, 24 Jul 2026 17:33:05 +0000

"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.

How to Get the Most Out of Amazon Quick Desktop

Patrick — Thu, 14 May 2026 18:10:25 +0000

Updated May 2026: Added three new principles (6, 7, 8) based on patterns that emerged after several weeks of daily use.

I've been using the Amazon Quick desktop app as my primary work interface for a while now. Not as a chat-bot I occasionally ask questions of, but as an integrated system that reads my notes, connects to my tools, and runs automated workflows in the background. The experience has felt like the jump from feature phones to smart phones. The real value unlocks when you build systems around Quick.

This post isn't a configuration walk-through. It's a mindset guide: the principles and patterns that made Quick useful for me, and how you can apply them in your role.

Principle 1: Give It Files, Not Conversations

The single biggest unlock with Quick desktop is this: it can read and write files on your filesystem.

Many web based AI assistants are stateless. You paste context into a chat window, get a response, and the context is gone. Quick is different. Point it at a folder of notes, and it can search them by meaning, extract entities and relationships, and write new files directly.

This changes the dynamic completely. Instead of re-explaining context every conversation, you build a persistent knowledge base that Quick draws from automatically.

The mindset shift: Stop thinking of Quick as a chat interface. Start thinking of it as a reader and writer that happens to have a chat interface. Your files are the context.

What this looks like in practice

I keep all my work notes as markdown files in a synced folder. Every customer interaction, every meeting, every project: it lives in a file. Quick has access to the folder with semantic search and a knowledge graph enabled.

Now when I ask "what did we discuss with Matt last quarter?", Quick doesn't need me to paste anything. It searches my notes, finds the relevant files, and synthesizes an answer from my own records.

The knowledge graph layer

This goes beyond keyword search. Quick builds a persistent graph of people, projects, decisions, and relationships from your files and connected sources. When you ask "who's involved with Project X?" or "what decisions did we make about the migration?", it's not scanning for keywords. It's traversing a graph of entities it extracted from your notes, emails, calendar, and Slack messages.

The graph updates continuously as you add content. Over time, it becomes a map of your professional world: who works with whom, what projects are active, what decisions were made and when. You don't maintain it manually. You just keep writing notes, and the graph grows.

Making your notes Quick-readable

You don't need fancy tools. Any folder of text files works. The only requirement is that your notes exist as files on your filesystem.

If you want structure, a simple folder hierarchy goes a long way:

notes/
├── inbox/             ← capture point for rough notes
├── projects/          ← one subfolder per project or workstream
├── people/            ← 1-on-1 notes, team notes
├── reference/         ← evergreen knowledge and resources
└── templates/         ← reusable formats for recurring note templates

Adapt the top-level folders to match how you think about your work. The specifics don't matter; what matters is that Quick can traverse the structure and search across it.

For the editor, anything that writes plain text or markdown to disk works: Obsidian, VS Code, or even a folder of .txt files. The key is that your notes are files on disk, not locked in a proprietary format.

Tip: If you already have notes in a tool like Notion, Evernote, or Google Docs, look for a bulk export option. Most tools can export to markdown or HTML, both of which Quick indexes well. You don't have to migrate your workflow overnight; even a partial export gives Quick something to work with.

Principle 2: Connect Your Tools, Then Let Quick Cross-Reference

Quick connected to your calendar, email, messaging, and CRM changes the game. The value isn't in any single integration. It's in the cross-referencing. When Quick can see your calendar, read your emails, search your Slack messages, and access your notes, it can do things none of those individual tools can do alone.

The mindset shift: Each integration you add doesn't just add one capability; it multiplies the value of other integrations.

Examples of cross-referencing in action

Meeting prep: "Prep me for my 2pm with Jane Smith" → Quick checks your calendar for the meeting, searches your notes for past interactions with Jane, pulls her contact info, checks recent email threads, and looks up her company in your CRM. One prompt, five data sources.
Post-call capture: After a customer call, paste your raw notes and ask Quick to structure them. It knows the customer context from your CRM, knows who was on the call from your calendar, and files the structured note in the right folder automatically.
End-of-day review: "What customer interactions did I have today that aren't logged in the CRM?" Quick cross-references your calendar and notes against your CRM activity log and tells you what's missing.

MCP servers extend the reach

Quick supports MCP (Model Context Protocol) servers, which means you can connect it to virtually any data source. See the Quick MCP integration guide for setup details. I use MCP servers for:

CRM access: query opportunities, log activities, pull account data (e.g., a Salesforce MCP server)
Documentation: search product docs and knowledge bases for accurate, up-to-date answers

Browser automation

Quick can also control a browser directly: navigate pages, fill forms, click buttons, extract data from web apps that don't have APIs. I use this for internal tools that only exist as web interfaces. Quick logs in with my existing Chrome session, navigates to the right page, and extracts what I need. No MCP server required for tools that already have a browser UI.

Note: Local folders are a native Quick feature, not an MCP integration. Add them directly in Settings → My Computer → Local Folders.

Principle 3: Teach It Once, Use It Forever (Skills)

Here's where most people leave value on the table. They do the same multi-step workflow with Quick over and over, re-explaining the process each time.

Skills fix this. A skill is a saved workflow: a set of instructions that Quick follows when triggered. You teach Quick the workflow once, save it as a skill, and from then on, a single phrase kicks off the entire process.

The mindset shift: Every time you find yourself giving Quick the same instructions twice, that's a skill waiting to be created.

How to create a skill

The process is surprisingly natural:

Do the task manually in a conversation. Walk through the workflow with Quick. Correct it when it gets something wrong. Iterate until the output is exactly right.
Ask Quick to save it. Say "Save this workflow as a reusable skill." Quick generates a skill file based on your conversation and saves it in your skills.

That's it. No code, no configuration files to write by hand, unless you want to make manual edits.

Skills I use daily

Capture interaction notes: I paste raw notes from a call and say "capture this." Quick classifies the interaction type, structures it using my template, files it in the right folder, and offers to log it to my CRM.

Generate customer overview: "Update overview for Acme Corp." Quick pulls current data from my CRM, combines it with my recent notes, and produces a one-page snapshot: what they do, relationship health, key contacts, and active threads.

Log CRM activity: After capturing an interaction note, one phrase logs it to Salesforce with the correct activity type and goal tags. No more end-of-day data entry marathons.

Generate a deliverable from notes: "Build a deck from my session notes." Quick takes raw meeting notes or workshop content and generates a customer-ready PowerPoint with the right structure and content. What used to take an afternoon takes minutes.

Pre-mortem a decision: "Pre-mortem this: [decision]." Quick classifies it as reversible or irreversible, maps what I know vs. don't know, and gives me a clear recommendation on whether to decide now or wait.

Challenge a belief: "Challenge this: [belief]." Quick plays devil's advocate, finds counterarguments, identifies my assumptions, flags cognitive biases, and tells me whether to revise my confidence.

Tips for good skills

One skill, one job. If a skill does three things, split it into three skills. Small, atomic skills compose better than monolithic ones.
Be specific about output format. Tell Quick exactly what sections you want, what to include, what to exclude.
Include failure handling. "If you can't determine the customer name, ask me."
Compose, don't combine. Need a multi-step pipeline? Build each step as a separate skill and chain them. When one step needs updating, you update it without touching the others. Scheduled agents (Principle 5) handle the orchestration.
Iterate. The first version won't be perfect. Use it a few times, notice what's off, and update.

Principle 4: Set your personal preferences

Without personal preferences, Quick is a generic assistant. With personal preferences, it knows your role, your communication style, and how you think.

This matters more than you'd expect. When Quick drafts an email on your behalf, should it be formal or conversational? When it analyzes a problem, should it give you options or a single recommendation? When it talks to a technical audience vs. a business audience, should it adjust?

Your personal preferences answer all of these questions once, so you don't answer them every conversation.

The mindset shift: Personal preferences aren't a nice-to-have customization. It's the difference between a generic assistant and one that actually sounds like you.

What to include

Your role and focus area: what you do, who you work with
Communication style: direct vs. diplomatic, concise vs. thorough
Audience adaptation rules: how to adjust for different audiences
Thinking methodology: when you ask for analysis, how should Quick structure it?
Error handling: what should Quick do when it doesn't have enough information?

The engram shortcut

Quick has a built-in feature called the engram builder. After you've had a few weeks of conversations, ask Quick to "build an engram from my messages." It analyzes your writing patterns and communication style, creating a profile of how you communicate.

Think of the engram as a bootstrapping tool. It gives Quick a head start on matching your voice. Over time, your preferences file becomes the authoritative source for how Quick should behave, and the engram serves as a reference for voice and tone when Quick generates content on your behalf.

Principle 5: Automate the Background Work

This is where Quick stops being a tool you use and starts being a system that works alongside you.

Quick supports scheduled agents: automated workflows that run on a recurring schedule, check your connected services, process files, and post results to a feed. You see what matters without having to ask.

The mindset shift: The best use of an AI assistant isn't answering questions when you ask them. It's doing work you'd forget to do, surfacing things you'd miss, and keeping your systems current without manual effort.

Scheduled agents I run

Morning strategist: On a schedule each morning, Quick reviews my calendar, scans overnight emails and Slack messages, checks my customer portfolio for changes, and produces a prioritized brief for my day. Not a raw dump of notifications. A synthesized view of what matters and what needs my attention first.

Inbox processor: On a recurring schedule, Quick checks my processing folder for new files. If it finds any, it classifies each one (customer interaction, internal meeting, 1-on-1, reference material), structures it using the right template, files it in the correct folder, and logs customer interactions to my CRM. If the folder is empty, it does nothing and stays quiet. I dump raw notes into the inbox; everything else is automatic.

Customer overview refresh: Every morning, Quick scans my customer folders and refreshes any overview that's fallen behind. If I've had new interactions with a customer since the last overview update, it pulls fresh CRM data and regenerates the snapshot.

Knowledge extraction: Every evening, Quick reviews my recent notes for reusable concepts: frameworks, patterns, approaches that worked. It captures these as standalone reference notes so good ideas don't stay buried in meeting notes.

Smart scheduling

Agents run on a schedule, but the good ones check whether there's work to do before acting. My inbox processor runs every 15 minutes, but if there's nothing new in the folder, it finishes instantly and produces no output. The morning strategist runs once at 7am, because it always has something to synthesize.

The key design pattern: schedule the agent to run frequently, but write the instructions so it stays silent when there's nothing to report. This gives you the responsiveness of event-driven automation without the complexity. You get results when something happened, and silence when it didn't.

The compound effect

Each of these agents is simple on its own. Together, they create a compound effect:

Raw notes get structured and filed automatically
Customer overviews stay current without manual effort
CRM activities get logged without end-of-day data entry
Reusable knowledge gets extracted and organized

After a few weeks, you realize your notes folder has become a well-organized, cross-referenced knowledge base, and you barely had to think about it.

Principle 6: Sharpen Your Thinking

The first five principles are about production: capturing information, connecting tools, automating tasks, generating output. But the most surprising value I've gotten from Quick isn't production at all. It's rigor.

I have skills that exist to challenge my reasoning. One stress-tests my assumptions before I commit to a decision. Another plays devil's advocate against a belief I hold, finds counterarguments I hadn't considered, identifies cognitive biases in my reasoning, and tells me whether my confidence is warranted.

These aren't tasks I was doing manually and now do faster. They're things I wasn't doing because the cognitive overhead was too high. Nobody schedules 20 minutes to systematically disconfirm their own beliefs. But when it's one sentence, you actually do it.

The mindset shift: The best skills aren't the ones that save time. They're the ones that improve the quality of your decisions. Quick doesn't think for you; it forces you to think more carefully by surfacing what you'd otherwise skip.

Examples

Pre-mortem a decision: I describe a pending decision, and Quick classifies it as reversible or irreversible, maps what I know vs. what I don't, identifies the highest-risk unknowns, and gives me a clear recommendation: decide now, or gather more information first.

Challenge a belief: I state something I believe to be true, and Quick actively searches for disconfirming evidence. It identifies my assumptions, flags potential biases, finds counterarguments from credible sources, and gives me a revised confidence level.

The pattern: any recurring judgment call that benefits from structured thinking is a candidate for this type of skill. You're not outsourcing the decision. You're making the decision with better inputs.

Why this matters

Production skills save time. Thinking skills change outcomes. The decision you didn't pre-mortem that turns out to be irreversible. The belief you held for six months that had a blindspot. These are the gaps that structured reasoning fills, not by thinking for you, but by making you more thorough in the moments that matter.

Principle 7: Encode Your Standards, Not Just Your Workflows

There's a difference between "do this task for me" and "enforce this quality bar on everything I produce." Skills handle the first. But the second is more powerful and less obvious.

I have a quality pipeline that runs on any document before it reaches anyone outside my team. It checks factual accuracy, verifies claims against source data, ensures the structure matches the target format, and confirms the tone is appropriate for the audience. Multiple skills, composed into a mandatory pipeline.

This isn't a workflow I trigger manually. It's a standard that applies automatically. The decision isn't "should I run the quality check?" The decision has already been made. Everything customer-facing runs through it.

The mindset shift: Don't just automate what you do. Automate what you should do but sometimes skip when you're in a hurry. Encode the standards you hold yourself to, and let Quick enforce them consistently.

What this looks like in practice

Start by identifying where you have implicit quality bars that you occasionally let slip:

Every customer email gets a tone check before sending? Encode it.
Every interaction note should include next steps and a follow-up date? Encode it.
Every analysis should cite its data sources? Encode it.
Every deliverable gets a factual accuracy review? Encode it.

The implementation follows the composability principle from Principle 3: build small, single-purpose skills for each quality check, then chain them. Each one does one thing well. The composition creates the standard.

Tips for encoding standards

Make them mandatory, not optional. A standard you have to remember to invoke isn't a standard. Build it into the workflow so it runs automatically.

Keep the checks atomic. One skill checks factual accuracy. Another checks structure. Another checks tone for the audience. When one needs updating, you update it without touching the others.

Accept that it adds time. Running multiple passes on a document takes longer than shipping the first draft. That's the point. The tradeoff is consistency: every deliverable meets the same bar, whether you wrote it at 9am or 11pm.

Principle 8: Curate What It Remembers

Quick learns. Not just within a conversation, but across weeks and months. It picks up your preferences, your patterns, the people you work with, the projects you're tracking, the way you like things structured. Over time, it builds a persistent understanding of your work context that makes every interaction more efficient.

But memory isn't set-and-forget. Uncurated memory becomes noise. Quick will remember things that are no longer true, store duplicates of the same fact, and accumulate details you never intended to persist. Left alone, the signal-to-noise ratio degrades.

I treat Quick's memory like a garden. Periodically, I review what it's stored and prune what's stale, incorrect, or irrelevant. I have explicit rules about what should and shouldn't be remembered. Preferences and style rules live in the preferences file (loaded every conversation), not in memory, because memory creates stale copies that diverge from the source of truth.

The mindset shift: The value of an AI assistant compounds over time, but only if you're intentional about what sticks. Memory is an asset that requires maintenance. Curate it, and you get an assistant that knows your work cold. Neglect it, and you get one that confidently applies outdated context.

How to think about memory hygiene

Separate concerns. Preferences and standards belong in your preferences file (loaded every conversation). Facts about people, projects, and decisions belong in memory. Don't duplicate across both, or you'll end up with contradictions.

Prune regularly. Ask Quick to scan for stale or personal memories every few weeks. Things change: people move teams, projects end, priorities shift. Memory should reflect current reality.

Be explicit about boundaries. Tell Quick what not to remember. If information doesn't serve your work, it shouldn't persist.

Let the knowledge graph do the heavy lifting. The knowledge graph (Principle 1) handles the "what's happening in my world" layer: people, projects, decisions, meetings, and how they connect. It's continuously rebuilt from source data and requires less manual curation. Think of memory as "how I want things done" and the knowledge graph as "what's going on around me."

The Mental Model

Quick is infrastructure, not an app.

An app is something you open, use, and close. Infrastructure is something that's always running, always connected, always working. You build on top of it.

When you treat Quick as infrastructure, connecting your tools, building skills, encoding standards, running background agents, curating what it learns, it stops being "that AI chat thing" and starts being the connective tissue between everything you do.

The chat interface is just the front door. The real value is in the system you build behind it.

Resources

If you want to dig deeper, here are the official links:

Amazon Quick homepage: overview, use cases, and what's included
Desktop, Mobile & Browser downloads: installers for macOS and Windows
Admin guide: identity, access management, and org-level configuration
User guide: full documentation for end users
FAQs: common questions answered