πŸŽ“ Claude Architect KB CCAR-F Β· CCAR-P study guide

AI Fluency Bridge β€” The 4D Framework, Architect Edition

Anthropic has a free AI Fluency course↗. It teaches the human side of working with AI, using a framework called the 4Ds. This KB teaches the system side. This page connects the two. The certification tests both, even though it does not say so. Each scenario question is really a 4D decision, written in the words of system architecture.

πŸ“– New here? Two vocabularies, one discipline

People who build with AI every day develop strong habits, but they often cannot name them. They feel when to give a task to the model and when to keep it. They feel when a prompt needs an example and when it needs an instruction. They feel when the output needs checking. The AI Fluency course gives these habits four names: Delegation, Description, Discernment, Diligence. Delegation means choosing which work you give to the AI and which work you keep. Description means telling the AI clearly what you want. Discernment means checking whether the result is correct and good. Diligence means taking responsibility for how the result affects people. This KB names the system parts that carry out these habits: the harness (the software that runs and controls the model), gates, evals, and schemas.

When you put the two together, the connection becomes clear: the architecture in this guide is fluency that stays in place. A skill file is a delegation decision that lasts after the session ends. A system prompt is a description that the model treats as its main instructions. An eval suite is discernment written as code. A HITL gate (a point where a human must approve) is diligence that you cannot forget to apply. If you already understand the domains in this KB, you already practice the 4Ds. This page only gives you the shared words.

🧭 Your seat at the table: this page states most clearly what the whole guide says about your role. The model brings reasoning. You bring the 4Ds: what to give to the model, how to describe it, how to check what comes back, and what you owe the people who are affected. Everything you build (a prompt, a schema, a gate, a skill) is one of these four decisions, saved into the system so it keeps working.

The three interaction modes β€” and where each lives in this guide

The course starts with a range of ways that people and AI work together. Every system you design fits somewhere in this range:

Mode What it means A concrete shape Where this KB covers it
Automation AI does a defined task; you define it, the model decides, the harness runs the actions a content assembly line: overnight, an orchestrator sends workers to thousands of items, and each result is checked before it is saved Domain 1 workflows Β· batch API (Domain 5) Β· scheduled-batch runtime (Deployment)
Augmentation AI is a thinking partner; you improve the work together, step by step building a feature together, coaching an interview answer, a design review with several models interactive Claude Code (Domain 2) Β· evaluator-optimizer (Domain 1)
Agency you set up how the AI acts on its own, then it acts an agent with standing rules (memory files, skills, permission policy) that does work with no person watching CLAUDE.md + skills + hooks (Domain 2) Β· headless/CI + services (Deployment)

Here is an architect's point that the course does not state so directly: the modes are stages of maturity for the same task. Work often starts as augmentation: you and the model work it out together. Then it becomes automation: the part you worked out becomes a workflow. Later it becomes agency: the judgment itself is written as standing rules, and the model applies them without you. Knowing which mode a task needs today is half of Delegation.

The 4Ds, mapped to the machinery

The D The fluency question The architecture that answers it
Delegation what work do I give to the AI, and what do I keep? pattern choice (workflow vs agent, Domain 1) Β· the tool catalog: every tool you define IS permission to do that work Β· HITL gates = the tasks you chose to keep for a person
Description how do I tell the AI my goal, the tone, and what success looks like? system prompts + examples + schemas (Domain 3) Β· CLAUDE.md and skills (Domain 2): description that stays saved so you do not type it again Β· tool descriptions (Domain 4): you explaining to the model what each tool can do
Discernment how do I check whether the result is right? validation + repair (Domain 3) Β· evals, golden sets, negative controls (Domains 1 & 5) Β· stop-reason checks: the cheapest discernment step, and the one people skip most
Diligence what responsibility do I have to the people affected? guardrails that the model cannot argue its way around (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

This is the same project described in both sets of words. Notice that both versions describe the same decisions:

Fluency version: "We delegated order lookups and replacements to the AI, but we kept refund approval with a person. We described the job with a role, policy rules, and worked examples. We defined success as 'resolved without breaking any policy.' We discern by checking a sample of transcripts every week. We also replay 24 fixed test conversations after every change. Because of diligence, customers are told that they are talking to an AI, and any amount over $100 waits for a person."

Architecture version: "The tool catalog offers get_order and create_replacement. issue_refund is not a tool; it is an escalation path, where the case goes to a person (Delegation). The system prompt contains policy P-12 and three few-shot examples, and the output must match a closed schema (Description). CI replays a golden set with negative controls. The harness checks the stop reason before it parses the output (Discernment). A HITL gate triggers above $100, the AI-disclosure line comes from a template, and every run is traced (Diligence)."

What this means for the exam: scenario questions are written in the first set of words, and you answer them in the second. A stem may say "the team wants to ensure the agent never…". That is a Diligence sentence. The correct option is the one that uses deterministic machinery (code that always enforces the rule), not a prompt that only hopes the model obeys. The real skill the exam tests is translating easily between these two versions.

The Description–Discernment loop β€” the engine of getting better

The most important pattern in the course is a loop: describe β†’ evaluate β†’ describe again, better. Domain 3 of this KB teaches the version that happens inside one session: you improve the prompt against a golden set, changing one thing at a time. The architect's version grows over time: every problem that discernment finds becomes a lasting description. Did the model invent a field? Now the schema has additionalProperties: false forever. Was the tone wrong? The style example goes into the standing instructions. Did the model choose the wrong tool? The tool description gets a "when NOT to use" sentence. Teams that run this loop stop fixing the same failures again and again. Their descriptions keep the lessons from every evaluation that ever failed.

🎯 Exam lens: a question may ask, "the agent keeps making the same mistake across sessions; what is the architectural fix?" The expected answer is move the correction into a saved description (memory files, skills, tool descriptions, schemas). The wrong answer is "correct it in each conversation." A one-time fix is only chat; a saved description is architecture.

Study this page's source material