The decision mindset

🔴 MUST KNOW · Your job is to choose a system that solves the client's problem safely and economically.

Overview

• A decision framework is a repeatable sequence of questions that turns a requirement into justified architecture.
• Each added capability should solve a concrete gap.
• It prevents treating every client request as an opportunity to deploy every AI framework.

Why this matters

Complexity creates costs and failure modes even when a demo looks impressive.

An everyday example

A builder decides what the house needs before buying every tool in the store.

A technical example

Claim status needs authenticated service lookup; policy explanation needs evidence plus language generation; adaptive intake may need a bounded agent.

How it works

1. Define outcome/risk
2. Test ordinary-code baseline
3. Identify language/knowledge/action gaps
4. Add minimal AI capabilities
5. Enforce boundaries
6. Evaluate
7. Instrument
8. Estimate cost/capacity.

Architecture and flow

See the decision flow below.

The insurance assistant example

Build one insurance assistant with separate controlled routes rather than forcing status, FAQ, and submission into one autonomous loop.

When to use it

Every new client requirement and every proposal to add a framework, agent, provider, or data store.

When to avoid it

Do not make it bureaucratic: a trivial requirement may be resolved by a few clear answers.

Interview answer

“I choose the minimum architecture that meets task quality, security, reliability, latency, and cost requirements, then justify each extra component with evidence.”

Benefits, trade-offs, and production considerations

• Decisions are revisable.
• Record the assumption, alternative, measurable trigger for change, and owner.
• Avoid premature distributed architecture, but recognize when durable state or security isolation is required from the start.

flowchart TD
  A[Do I need AI? Define the outcome] --> B[Can deterministic code solve it?]
  B -->|Yes| C[Use ordinary code and normal reliability controls]
  B -->|No: language or media ambiguity| D[Do I need an LLM or a smaller task model?]
  D --> E[Do I need external knowledge? Add RAG if justified]
  E --> F[Do I need current data or actions? Add safe tools]
  F --> G[Do next steps vary? Consider bounded agent]
  G --> H[Should execution be a controlled workflow?]
  H --> I[Where is exact human approval required?]
  I --> J[How do I secure every boundary?]
  J --> K[How do I evaluate outcomes and failures?]
  K --> L[How do I observe runs and audit actions?]
  L --> M[What is total cost per successful task?]
  M --> N[How does it scale within quotas and budgets?]
  C --> J

• This is a sequence of questions, not a requirement to answer “yes” to every technology.
• RAG, tools, agents, and workflows are independent capabilities that can be combined only where needed.