Rapid Revision Guide

Purpose: Last-day revision for an AI/Agentic FDE problem-decomposition interview.

Don't memorise architectures. Memorise the decision process.

---

Whenever you get a vague prompt:

Customer Problem
      ↓
Discovery
      ↓
Functional Requirements
      ↓
Non-Functional Requirements
      ↓
Happy-Path Architecture
      ↓
Data / RAG
      ↓
Agent / Tools / Actions
      ↓
Policy / HITL
      ↓
Scale
      ↓
Latency + Cost
      ↓
Reliability
      ↓
Evaluation + Release
      ↓
Observability + Security
      ↓
Trade-offs

Opening line

"Before jumping into architecture, I'd first understand the business outcome and current workflow, then clarify users and scale, data and integrations, how much autonomy the AI should have, success criteria, and production constraints."

---

Remember:

WHY
TODAY
WHO
SCALE
DATA
ACTION
SUCCESS
BOUNDARIES

WHY

What business problem are we solving and what outcome matters?

TODAY

How does this process work today and where are the biggest pain points?

WHO + SCALE

Who uses the system, how many users do we expect, and what are peak volume and concurrency?

DATA

What data does the system need, where does it live, and how fresh must it be?

ACTION

Does AI only answer/recommend, or can it take actions?

Which actions require human approval?

SUCCESS

How will we measure success?

Think:

Business KPI
AI Quality
Task Success
Latency
Reliability
Cost

BOUNDARIES

Ask about:

Security
Privacy
Compliance
Latency
Availability
Cost
Integrations

---

Think:

Understand
    ↓
Retrieve
    ↓
Route
    ↓
Reason
    ↓
Tool
    ↓
Act
    ↓
Escalate
    ↓
Audit

Typical requirements:

• Accept and understand requests
• Maintain relevant context
• Retrieve enterprise knowledge
• Respect user permissions
• Route to correct capability
• Call enterprise tools/APIs
• Execute approved actions
• Escalate risky/uncertain cases
• Handle failures
• Maintain audit trail
• Capture feedback

---

Remember:

SCALE
LATENCY
RELIABILITY
QUALITY
SECURITY
SAFETY
COST
OBSERVABILITY
AUDIT

Don't invent numbers.

Ask the customer and turn requirements into measurable SLOs.

Example (the 5 seconds is a placeholder — confirm the real number with the customer):

Bad:
"The system must be fast."

Better:
"P95 response latency < 5 seconds
for interactive requests."

---

API Gateway

User
 ↓
API Gateway
 ↓
AI Application

Handles:

Authentication
Authorization
Tenant Context
User Rate Limits
Quota
Request Validation

Think:

User → Application control

---

Model Gateway

AI Application
      ↓
Model Gateway
      ↓
Model A / B / C

Handles:

Model Routing
Provider Abstraction
Fallback
Retry
Provider Limits
Tokens
Cost

Think:

Application → Model control

---

Router

Determines:

What capability should handle this request?

Use deterministic rules/classifiers where possible.

---

Orchestrator

Controls:

Workflow
State
Branching
Agents
Tools
Retries
Checkpoints

---

State Store

Stores durable:

Session
Workflow
Agent
Approval State

---

Queue

Use when:

Long-running work
Traffic bursts
Async processing
Background jobs

---

Cache

Use for repeated safe work.

Remember:

Cache
 ↓
Latency ↓
Cost ↓

BUT

Freshness risk ↑

---

Ingestion

Documents
 ↓
Parse
 ↓
Chunk
 ↓
Embed
 ↓
Index

Query

Question
 ↓
Permission / Metadata Filter
 ↓
Retrieve
 ↓
Rerank
 ↓
Context
 ↓
LLM

Remember:

Recall

Did I retrieve the relevant information?

Precision

How much retrieved information is actually relevant?

Groundedness

Is the answer supported by retrieved evidence?

Static vs Live

"What is the refund policy?"
        ↓
       RAG

"Where is my refund?"
        ↓
     Live API

Security rule

Apply permissions during retrieval. Don't retrieve everything and ask the LLM not to expose unauthorised information.

---

First ask:

Do I actually need an agent?

Deterministic problem
       ↓
Workflow / Code

Dynamic reasoning
       ↓
Agent

Then ask:

Do I actually need multiple agents?

Don't create multi-agent architecture without a reason.

Agent loop

Reason
 ↓
Tool
 ↓
Observe
 ↓
Reason
 ↓
Action

Always bound agents

Max Steps
Max Tools
Max Tokens
Max Retries
Max Time
Max Cost

---

Prefer:

Agent
 ↓
Controlled Tool
 ↓
Enterprise System

rather than unrestricted production access.

For business actions:

Agent
 ↓
Recommendation
 ↓
Policy
 ↓
Executor
 ↓
Enterprise System

Critical term: Idempotency

Refund
 ↓
Timeout
 ↓
Retry

Must NOT
 ↓
Refund twice

Use an idempotency key that the execution path actually honours.

---

Remember:

Agent recommends
      ↓
Policy decides
      ↓
Executor acts

Do not use the LLM as the final authority for deterministic business rules.

Example (illustrative thresholds — the customer sets the real ones, including the middle band):

Refund < $100
      ↓
Auto

Refund $100–500
      ↓
Policy checks

Refund > $500
      ↓
Human Approval

Other terms:

Least Privilege
Fail-Closed
Kill Switch
Defense in Depth

---

Interviewer says:

"Now scale this to 100K users."

Think:

Stateless Workers
Horizontal Scaling
Rate Limits
Admission Control
Queue
Backpressure
Fairness
Tenant Isolation
Caching
Autoscaling

Rate Limit

May this user/tenant send this much traffic?

Admission Control

Does the system currently have capacity to accept this work?

Backpressure

What happens when incoming work exceeds processing capacity?

Fair Queue

Prevent:

Tenant A ███████████████████

Tenant B █

Tenant C █

Noisy Neighbor

One tenant consumes shared resources and hurts others.

---

First decompose:

Total Latency
     │
     ├── Queue
     ├── Retrieval
     ├── LLM
     ├── Agent
     ├── Tool
     └── Network

Then optimise.

Remember:

MEASURE
   ↓
SLO
   ↓
STREAM
   ↓
PARALLELIZE
   ↓
REDUCE MODEL HOPS
   ↓
OPTIMIZE RETRIEVAL
   ↓
OPTIMIZE TOOLS
   ↓
CONTROL QUEUE
   ↓
ASYNC LONG TASKS

Track:

P50
P95
P99
TTFT

Don't optimise only average latency.

---

Break cost down:

Model
Tokens
Retrieval
Tools
Compute
Retries

Then:

MODEL
 ↓
CONTEXT
 ↓
CACHE
 ↓
CALLS
 ↓
BOUNDS
 ↓
BATCH
 ↓
MEASURE

Questions to ask

Can a smaller model handle this?

Can I reduce context?

Can I cache it?

Do I need this LLM call?

Can deterministic code handle it?

Is the agent making unnecessary calls?

Best metric

Cost
 ÷
Successful Tasks

Cost per successful task — the one I'd lead with, because it counts retries and failed attempts.

---

When something fails:

Failure
 ↓
Timeout?
 ↓
Retry?
 ↓
Fallback?
 ↓
Degrade?
 ↓
Recover?
 ↓
Escalate?

Know these:

Timeout

Don't wait forever.

Retry

Retry transient failures, and only when the call is safe to repeat.

Exponential Backoff + Jitter

Don't hammer a failing dependency.

Circuit Breaker

Repeated failures
       ↓
Stop calling temporarily

Graceful Degradation

One non-critical service failing shouldn't necessarily kill everything.

DLQ

Fail
 ↓
Retry
 ↓
Retry
 ↓
DLQ

Checkpoint

Resume long-running workflows after failure.

A checkpoint doesn't make an external action happen exactly once. If a write may have gone through, reconcile its status first.

Blast Radius

If this fails, how much of the system is affected?

---

RAG

Evaluate:

Retrieval
Groundedness
Answer Quality

Agents

Evaluate:

Routing
Tool Selection
Tool Arguments
Trajectory
Task Success

Deterministic

Correct schema?
Correct tool?
Correct arguments?
Latency threshold?
Required citation?

Non-Deterministic

Helpful?
Relevant?
Grounded?
High-quality?

Use human/LLM judges.

Offline

Before release.

Online

Production traces + outcomes + feedback.

Remember:

Beautiful Answer
      ≠
Successful Task

---

Avoid:

New Prompt
   ↓
100% Production

Prefer:

Change
 ↓
Offline Evaluation
 ↓
Release Gate
 ↓
Shadow / Canary
 ↓
Online Evaluation
 ↓
Full Production

Shadow

Request
 ├→ Current → User
 └→ Candidate → Evaluate only

Canary

Candidate
 ↓
Small % Users
 ↓
Observe
 ↓
Expand / Rollback

Also know:

Versioning
Feature Flags
Rollback
Kill Switch

---

Trace the entire request:

Request
 ↓
Router
 ↓
Agent
 ↓
Retriever
 ↓
LLM
 ↓
Tool
 ↓
Response

Capture:

Latency
Tokens
Cost
Model
Agent Steps
Retrieved Docs
Tool Calls
Errors
Outcome

Observability vs Audit

Observability

Why is my system behaving badly?

Audit

Why did my system take this business action?

---

Authentication

Who are you?

Authorisation

What are you allowed to do?

Then:

Identity
 ↓
Authorization
 ↓
Data Permissions
 ↓
Tool Permissions
 ↓
Policy
 ↓
Human Approval
 ↓
Audit

Remember:

Least Privilege
Tenant Isolation
Permission-Aware RAG
Secrets Management
PII
Data Residency
Defense in Depth

---

Almost every decision should have:

Decision
 ↓
Why?
 ↓
Trade-off?

Main triangle

             QUALITY
              /   \
             /     \
          COST ─── LATENCY

Examples:

Stronger Model
→ Quality ↑
→ Cost ↑
→ Latency ↑

More Retrieval
→ Recall potentially ↑
→ Tokens ↑
→ Cost ↑
→ Latency ↑

Cache
→ Cost ↓
→ Latency ↓
→ Freshness Risk ↑

More Agents
→ Potential capability ↑
→ Cost ↑
→ Latency ↑
→ Complexity ↑
→ Failure Points ↑

Strong interview sentence

"I'm choosing X because of requirement Y. The trade-off is Z."

---

This is the section to revise immediately before the interview.

---

After drawing your architecture, quickly ask yourself:

1. SCALE
   What happens at 100K users?

2. LATENCY
   Where is the critical path?

3. COST
   Where are model calls/tokens growing?

4. FAILURE
   What happens if model/RAG/tool fails?

5. STATE
   What happens if a worker dies?

6. SECURITY
   Can users access unauthorized data/actions?

7. SAFETY
   Can the agent take dangerous actions?

8. QUALITY
   How do I know the AI works?

9. RELEASE
   How do I safely change it?

10. OPERATIONS
    How do I debug it?

---

Try answering each in 1–2 minutes, not 20 minutes.

1.

"Build an AI customer-support agent."

What are your first discovery questions?

2.

"Now it needs to issue refunds."

What changes architecturally?

3.

"We now have 100K users."

What changes?

4.

"P99 latency is 20 seconds."

How do you investigate and optimise it?

5.

"The AI bill increased 3×."

How do you investigate and reduce it?

6.

"The refund API is unreliable."

How do you design around it?

7.

"Employees have different document permissions."

How does your RAG architecture change?

8.

"We changed the prompt."

How do you safely release it?

9.

"The agent gives good responses but sometimes chooses the wrong tool."

How do you evaluate this?

10.

"One enterprise tenant consumes most model capacity."

How do you protect other tenants?

---

Before finishing:

□ Business problem clear?

□ Current workflow understood?

□ Functional requirements defined?

□ NFRs measurable?

□ Every architecture box justified?

□ RAG vs live API clear?

□ Agent actually required?

□ Actions protected by policy?

□ High-risk actions HITL?

□ Scale addressed?

□ Latency addressed?

□ Cost addressed?

□ Failure handling addressed?

□ Security addressed?

□ Evaluation defined?

□ Release strategy defined?

□ Observability defined?

□ Major trade-offs explained?

---

If everything else disappears from your head:

CUSTOMER PROBLEM
      ↓
DISCOVERY
      ↓
REQUIREMENTS
      ↓
SIMPLE HAPPY PATH
      ↓
DATA + AI + ACTIONS
      ↓
PRESSURE TEST
 ┌────┼────┬────┐
Scale Latency Cost Failure
 └────┼────┴────┘
      ↓
SECURITY + SAFETY
      ↓
EVALUATION
      ↓
RELEASE + OBSERVABILITY
      ↓
TRADE-OFFS

And use this reasoning pattern repeatedly:

Customer says X
      ↓
Therefore Requirement Y
      ↓
That creates Constraint Z
      ↓
So I introduce Component A
      ↓
Trade-off is B

Don't demonstrate how many architecture terms you know. Demonstrate that you know exactly when and why to use them.

---

Sources (checked 27 Sep 2026)

• Google SRE Book - Service Level Objectives — SLI, SLO and SLA definitions
• Google SRE Workbook - Canarying Releases — canary as a partial, time-limited rollout that is evaluated
• AWS Builders' Library - Timeouts, retries and backoff with jitter — backoff and jitter; retry only when safe to repeat
• Azure Architecture Center - Circuit Breaker pattern — stop calling a failing dependency for a while
• Amazon SQS Developer Guide - Dead-letter queues — retry, then move to a DLQ
• Stripe API reference - Idempotent requests — idempotency key honoured on retry
• Temporal blog - Idempotency and durable execution — checkpoints don't stop duplicate side effects; idempotent consumers
• OWASP GenAI LLM08:2025 Vector and Embedding Weaknesses — apply permissions during retrieval
• OWASP GenAI LLM07:2025 System Prompt Leakage — don't rely on the prompt to hide unauthorised data