🎓 Claude Architect KB CCAR-F · CCAR-P study guide

AI Fluency Bridge — The 4D Framework, Architect Edition

Anthropic's free AI Fluency course teaches the human side of working with AI — a framework called the 4Ds. This KB teaches the system side. Here's the bridge between them, because the certification quietly tests both: every scenario question is a 4D judgment wearing an architecture costume.

📖 New here? Two vocabularies, one discipline

Builders who work with AI daily develop strong instincts they can't name — they feel when to hand a task to the model versus keep it, when a prompt needs an example versus an instruction, when output needs checking. The AI Fluency course names those instincts: Delegation, Description, Discernment, Diligence. This KB names the machinery those instincts operate: harness, gates, evals, schemas.

Put them together and something clicks: the architecture in this guide is fluency, made durable. A skill file is a delegation decision that outlives the session. A system prompt is description made authoritative. An eval suite is discernment turned into code. A HITL gate is diligence you can't forget to apply. If you've internalized the domains here, you already practice the 4Ds — this page just hands you the shared vocabulary.

🧭 Your seat at the table: this page is the clearest statement of the whole guide's thesis about you. The model brings reasoning; you bring the 4Ds — what to hand over, how to describe it, how to judge what comes back, and what you owe the people affected. Every artifact you build (a prompt, a schema, a gate, a skill) is one of those four judgments, frozen into infrastructure.

The three interaction modes — and where each lives in this guide

The course opens with a spectrum of how humans and AI interact. Every system you'll ever architect sits somewhere on it:

Mode What it means A concrete shape Where this KB covers it
Automation AI performs a defined task; you define, it executes a content assembly line: an orchestrator fans workers across thousands of items overnight, each validated before landing Domain 1 workflows · batch API (Domain 5) · scheduled-batch runtime (Deployment)
Augmentation AI as thinking partner; you iterate together pair-building a feature, coaching through an interview answer, multi-model design review interactive Claude Code (Domain 2) · evaluator-optimizer (Domain 1)
Agency you configure how AI acts independently, then it acts an agent with standing rules (memory files, skills, permission policy) handling work unattended CLAUDE.md + skills + hooks (Domain 2) · headless/CI + services (Deployment)

The architect's insight the course won't say this bluntly: the modes are a maturity ladder for the same task. Work often starts as augmentation (you and the model figuring it out together), gets compressed into automation (the figured-out part becomes a workflow), and graduates to agency (the judgment itself gets encoded as standing rules the model applies without you). Knowing which mode a task deserves today is half of Delegation.

The 4Ds, mapped to the machinery

The D The fluency question The architecture that answers it
Delegation what do I hand over vs. keep? pattern choice (workflow vs agent, Domain 1) · the tool catalog — every tool you define IS a delegation grant · HITL gates = the tasks you deliberately kept
Description how do I communicate intent, tone, success? system prompts + examples + schemas (Domain 3) · CLAUDE.md and skills (Domain 2) — description that persists instead of being retyped · tool descriptions (Domain 4) — you describing capability to the model
Discernment how do I judge what comes back? validation + repair (Domain 3) · evals, golden sets, negative controls (Domains 1 & 5) · stop-reason checks — discernment's cheapest, most-skipped move
Diligence what do I owe the people affected? guardrails the model can't talk past (Domain 1) · injection defense (Domain 3) · least privilege + egress control (Domains 4 & Deployment) · audit trails and honest failure (Domain 5)
🔍 See it run — one team's support agent, told twice: fluency language vs. architecture language

Same project, both vocabularies — watch them describe identical decisions:

Fluency telling: "We delegated order lookups and replacements to the AI but kept refund approval human. We described the job with a role, policy rules, and worked examples, and defined success as 'resolved without policy violations.' We discern by spot-checking transcripts weekly and replaying 24 fixed test conversations on every change. Out of diligence, customers are told they're talking to an AI, and anything over $100 waits for a person."

Architecture telling: "The tool catalog exposes get_order and create_replacement; issue_refund isn't a tool — it's an escalation path (Delegation). The system prompt carries policy P-12 plus three few-shot examples, and the output contract is a closed schema (Description). CI replays a golden set with negative controls; the harness checks stop reason before parsing (Discernment). A HITL gate fires above $100, the disclosure line is templated, and every run is traced (Diligence)."

The exam moment: scenario questions are written in the first language and answered in the second. When a stem says "the team wants to ensure the agent never…", it's a Diligence sentence — and the correct option is whichever one is deterministic machinery, not prompt hope. Translating fluently between these two tellings is, quietly, the certified skill.

The Description–Discernment loop — the engine of getting better

The course's deepest pattern: describe → evaluate → re-describe better, in a loop. This KB's Domain 3 teaches its in-session form (prompt iteration against a golden set, one variable at a time). But the architect's version compounds across time: every discernment catch becomes durable description. Caught the model inventing a field? That's now additionalProperties: false forever. Caught a tone miss? The style example goes into the standing instructions. Caught a wrong-tool choice? The tool description gets the "when NOT to use" clause. Teams that run this loop stop re-fixing the same failures — their descriptions carry the scar tissue of every evaluation that ever failed.

🎯 Exam lens: "the agent keeps making the same mistake across sessions — what's the architectural fix?" The tested answer is move the correction into persistent description (memory files, skills, tool descriptions, schemas), not "correct it in each conversation." One-time fixes are chat; durable description is architecture.

Study this page's source material