Why This Foundations Path Exists

This is Path 1 from How I'm Preparing for the Claude Certified Architect – Foundations Exam (CCAR-F).

If terms like LLM, context window, tool use, agent, MCP or Claude Projects already feel familiar, there's no reason to be here — Domain 1: Agentic Architecture & Orchestration is where the actual CCAR-F preparation starts.

But if a few of those words made us pause, even briefly, this post is for us.

The goal here isn't a three-month history of artificial intelligence. It's just enough of a mental model — in plain English, with diagrams where a picture beats a paragraph — that the CCAR-F domains stop reading like a wall of unfamiliar terminology and start reading like things we can reason about.

We've grouped the terms into four sets:

1. The basics — how Claude actually works under the hood.
2. How Claude gets things done — tools, agents, and the protocol connecting them.
3. Claude's workspace features — Code, Cowork, Projects, Artifacts, Skills, and more.
4. Working with Claude well — the habits and framing that make it actually useful.

---

The Basics: How Claude Actually Works

Claude, in One Paragraph

Claude is the family of AI models built by Anthropic. We talk to it, it talks back, and somewhere underneath that conversation is a large language model doing the actual work. That's really the whole picture we need for now — everything else in this section is about unpacking what that sentence means.

LLMs — Large Language Models

An LLM is, at its core, a very large statistical model trained to predict the next word (technically, the next token — more on that below) given everything that came before it.

That's it. That's the trick.

Trained on enormous amounts of text, the model learns patterns — grammar, facts, reasoning steps, code, tone — well enough that "predict the next word, over and over again" starts to look a lot like writing, explaining, and reasoning.

A token is just a chunk of text — sometimes a whole word, sometimes a piece of one. When we hear about "context window size in tokens," this is what's being counted.

Context Window

The context window is the model's working memory — the maximum amount of text it can hold and actively "see" at once while generating a response.

Everything inside it gets read together, every time:

1. System instructions — how the model should behave.
2. Our prompt — the actual question or task.
3. Any files or data we've handed it.
4. The chat history so far — every earlier message in this conversation.

If everything we've given the model fits inside the window, it remembers all of it perfectly. If it doesn't fit, the oldest parts get cut to make room for new text — and once something falls out, it's gone. We can't ask about message 5 if messages 6 through 80 have since pushed it out of the window.

The trade-off: a bigger window is better for long tasks — reading whole documents, hours-long conversations — but it's also slower and more expensive to process, since the model re-reads the entire window for every single response.

A rough sense of scale, in tokens:

Model	Approx. window	Roughly equivalent to
An older, small model	~4,000 tokens	A short story
A mid-sized model	~32,000 tokens	A 50-page novella
Claude (larger models)	~200,000 tokens	The entire Lord of the Rings trilogy

The rule worth remembering: if we paste a 500-page document into a model whose window only holds 300 pages' worth of tokens, it will have already forgotten the first 200 pages by the time it answers a question about the ending.

Constitutional AI

Constitutional AI is Anthropic's technique for training Claude to be helpful and harmless — instead of a human reviewing every single response for safety, Claude is given a written set of principles (its "constitution") and taught to check its own answers against them.

This flips the usual approach. Instead of humans manually labeling thousands of "bad" responses (slow, exhausting, and inconsistent between reviewers), Claude does most of that filtering itself, using its own rulebook. Humans mainly step in at the end, choosing between outputs that are already reasonably safe — rather than having to catch every problem from scratch.

Extended Thinking

Extended Thinking lets Claude take extra time and computation to reason through a problem step by step before answering, instead of responding immediately.

With it on, Claude effectively pauses to break the problem into parts, try different approaches, and check its own logic — then uses that groundwork to write a better final answer.

Worth turning on for: advanced math, debugging tricky code, multi-step technical problems where one early mistake ruins the whole result, or planning something with a lot of moving parts.

Not worth it for: quick factual questions, casual conversation, or anything where a fast, simple answer is genuinely all we need — extended thinking costs more time and tokens, so it should be reached for on purpose, not by default.

---

How Claude Gets Things Done

Tool Use

By default, a model can only generate text. Tool use (sometimes called function calling) is what lets it go further — Claude can say "I'd like to call this function, with these arguments," a system executes that function, and the result gets fed back in.

A simple example: we ask "what's the weather in Chennai right now?" The model has no live data — it can't know this on its own. But with access to a get_weather(city) tool, it can call that tool, receive the real result, and answer accurately instead of guessing.

Tool use is what turns a model from "a very good text generator" into something that can actually do things.

Agents

An agent, in this context, isn't a person or a mysterious black box — it's a loop:

1. The model looks at the current situation (our request, any tool results so far).
2. It decides what to do next — answer, or call a tool.
3. If it calls a tool, the result comes back in.
4. Repeat, until the model decides the task is done.

That loop — observe, decide, act, repeat — is the agentic loop, and it's the foundation of Domain 1: Agentic Architecture & Orchestration, the single biggest chunk of the CCAR-F exam. We'll go much deeper into it in the Domain 1 post.

MCP — Model Context Protocol

MCP (Model Context Protocol) is an open standard for connecting models to external tools and data — a common plug shape, so any MCP-compatible tool can talk to any MCP-compatible model without custom, one-off integration code for each pair.

Before MCP, connecting a model to, say, a company's internal ticketing system meant writing bespoke integration code for that specific model and that specific system. MCP standardizes the connection: an MCP server exposes tools and data, and an MCP client (built into the model-facing application) discovers and uses them.

So how is this different from just using an API? Say 3 AI apps — a chatbot, a coding assistant, an email agent — all need to check the weather and manage a calendar. Without a shared protocol, each app needs its own integration for each service: its own auth, its own response parsing, its own hardcoded "call this when the user asks about weather" logic. That's 3 apps × 2 services = 6 integrations to maintain — and it scales badly: 10 apps and 20 tools is 200 integrations. With MCP, someone builds one server per service; any MCP-compatible app plugs in with no custom code. Same scenario becomes 3 + 2 = 5. N × M becomes N + M, and fixing the weather server once fixes it for every app using it.

The other shift: with a plain API, a developer decides in advance exactly which endpoint gets called and hardcodes that logic. With MCP, the model reads a tool's description at runtime and decides whether and how to use it — discovery instead of a pre-wired call.

Should MCP replace APIs, then? No. An MCP server is usually a thin wrapper around an existing API — someone still has to build and run the actual service underneath. Most API traffic isn't AI-driven at all (a mobile app calling a backend, one microservice talking to another), so wrapping it in a discovery layer adds pure overhead for no benefit there. MCP also has real costs a direct API call doesn't: extra latency from the discovery round-trip, less control over each call, and a live security concern — prompt injection, where malicious instructions hidden in a tool's description or output trick the model, something a hardcoded API call simply isn't exposed to.

The mental model: the API is the underlying capability; MCP is the model-facing interface, added specifically where a model needs to discover and call that capability dynamically. For a direct, known integration between two pieces of software we control, a plain API call is usually still simpler and more predictable.

This is what Domain 2: Tool Design & MCP Integration is about — designing good tools and wiring them up cleanly.

Structured Output

Left to its own devices, a model replies in free-flowing prose. Great for a chat, painful for a system that needs to parse the response programmatically.

Structured output constrains the model's response to a specific shape — usually JSON matching a schema we define — so downstream code can rely on it. Instead of parsing "the weather is sunny with a high of 31°C" out of a sentence, we get back {"condition": "sunny", "high_celsius": 31} directly.

This matters the moment an agent's output feeds into another system rather than a human reader — which, in most production architectures, is most of the time.

---

Claude's Workspace Features

Claude Code

Claude Code is Anthropic's agentic coding tool — it can read a codebase, make edits, run commands, and iterate, all through the same agentic loop described above, applied specifically to software engineering tasks.

We don't need to be Claude Code experts for CCAR-F, but we do need to understand how it's configured and used in real workflows — that's Domain 3: Claude Code Configuration & Workflows.

Claude Cowork

Claude Cowork turns Claude from a conversational chatbot into an active agent that can work directly with the files and folders on our computer — no more copy-pasting text back and forth.

We authorize Claude to access a specific folder, describe the outcome we want, and step away while it reads, edits, and creates files there. A few things it's genuinely useful for:

• Sorting a messy Downloads folder by date or file type.
• Turning a folder of receipt screenshots into a spreadsheet with formulas.
• Drafting a report from a folder of scattered notes.

Currently a research preview on the Claude desktop app (macOS and Windows) for Pro, Max, Team, and Enterprise plans.

Projects in Claude

Projects are self-contained workspaces that give Claude specialized context for a specific piece of work, so we're not re-explaining the same background in every new chat.

A project carries:

• A knowledge base — documents, code, or files Claude treats as background for every chat inside that project.
• Project instructions — standing rules, like "use a formal tone" or "answer as a product manager would."

There are two distinct kinds worth telling apart:

	Chat Projects	Cowork Projects
Where	claude.ai/projects (cloud)	Claude Desktop (local)
Works with	Documents, chat history	Local folders on our computer
Extra features	—	Scheduled tasks, persistent memory

We can even import an existing Chat Project into a Cowork Project.

Artifacts

Artifacts give substantial content — code, a document, a webpage, an interactive tool — its own dedicated window, separate from the back-and-forth of the chat itself. Instead of scrolling back through a long conversation to find a code snippet, it's sitting right there in its own panel to view, edit, or download.

Claude creates one automatically for anything substantial (roughly 15+ lines). If it doesn't and we wanted one, asking directly — "show me this as an artifact" — works fine.

Skills

A Skill is a reusable package of instructions, resources, and sometimes scripts that teaches Claude how to perform a particular type of task consistently.

A simple way to think about a Skill is as a playbook for Claude.

For example, we might create Skills for:

• Creating presentations using our company guidelines
• Analyzing Excel files using our standard approach
• Reviewing pull requests according to our engineering standards
• Generating API documentation using our templates
• Performing a specific data analysis workflow

The key point is that Skills are not limited to coding or PR reviews. We can create a Skill for any repeatable workflow where we want Claude to follow a specific process, use specific resources, or produce a specific type of output.

Why do we need Skills?

If we repeatedly ask Claude to perform the same type of work, we often have to repeat the same instructions.

For example:

“When creating a presentation, use our standard structure, terminology, branding guidelines, and approved messaging.”

Instead of providing these instructions every time, we can put them into a Presentation Skill once.

Later, when we ask:

“Create a presentation summarizing our quarterly results.”

Claude can recognize that the Presentation Skill is relevant and apply those instructions.

So the basic idea is:

Teach once → Reuse whenever relevant

What does a Skill contain?

A Skill is essentially a folder containing a SKILL.md file and any supporting resources.

For example:

presentation-skill/
├── SKILL.md
├── brand-guidelines.md
├── presentation-template.pptx
└── examples/
    └── example-deck.pptx

SKILL.md contains the main instructions for the Skill. The folder can also contain:

• Reference documents
• Templates
• Examples
• Scripts
• Configuration files

Therefore, a Skill is more than just a prompt. It packages the instructions and resources needed to perform a particular workflow.

How does Claude know when to use a Skill?

Each Skill has a short name and description in the frontmatter of SKILL.md.

For example:

---
name: Presentation Creation
description: Create presentations using our approved structure,
terminology, branding, and templates.
---

When we give Claude a request, Claude can compare the request with the descriptions of the available Skills.

If we ask:

“Create a presentation explaining our new product.”

Claude can recognize that the Presentation Creation Skill is relevant and load its detailed instructions.

Skills are loaded on demand

Claude does not load the complete instructions for every available Skill into every conversation.

This is important when we have many Skills installed.

The simplified flow is:

Our request
    │
    ▼
Claude checks available Skill descriptions
    │
    ▼
Is a Skill relevant?
    │
    ├── No ──► Continue normally
    │
    └── Yes
          │
          ▼
    Load detailed instructions
          │
          ▼
    Perform the task using the Skill

This approach is often called progressive disclosure: only the detailed information needed for the current task is loaded.

Skills can contain scripts

A Skill can contain executable scripts in addition to instructions.

For example:

data-analysis/
├── SKILL.md
├── analysis-guidelines.md
└── scripts/
    └── calculate_metrics.py

SKILL.md can describe the analysis process, while the Python script can perform calculations deterministically.

This is useful because Claude can use actual code for tasks where deterministic execution is preferable to reproducing the logic through natural-language reasoning.

Skills can provide guardrails

A Skill can also specify which tools Claude is allowed to use while the Skill is active.

For example, a Skill might allow Claude to read files and run a specific analysis script, while preventing other actions.

This gives us an additional level of control, especially when using Skills created by others.

Built-in and Custom Skills

There are two broad types of Skills.

Built-in Skills

Anthropic provides Skills for common tasks such as:

• Excel
• Word
• PowerPoint
• PDF

Claude can use these when appropriate without us having to create them.

Custom Skills

We can create our own Skills for workflows specific to us, our team, or our organization.

Examples include:

• Presentation Skill — follow our company presentation guidelines
• PR Review Skill — review code using our engineering standards
• Data Analysis Skill — follow our standard analysis methodology
• API Documentation Skill — use our documentation structure and templates

Where do Skills live?

Personal Skills

Personal Skills can be stored under:

~/.claude/skills

These can be used across our projects.

Project Skills

Project-specific Skills can be stored under:

.claude/skills

inside the repository.

Because project Skills can be committed to the repository, they can be shared with the rest of the team.

Skills can be shared

Custom Skills can be distributed through mechanisms such as:

• Git repositories
• Plugins
• Enterprise-managed configurations

This allows an organization to create standard Skills and make them available across teams.

For example:

              Company Skills
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
   Development   Analytics    Business
       │            │            │
   PR Review    Data Analysis  Presentation
   Security     Reporting      Documentation

Everyone can then follow the same predefined workflows instead of maintaining separate instructions.

Skills vs. CLAUDE.md vs. Slash Commands

These three mechanisms serve different purposes:

	CLAUDE.md	Slash Command	Skill
Purpose	General rules and context	Explicitly request an action	Reusable expertise/workflow
Activation	Available as project/user context	We invoke it explicitly	Claude recognizes when it is relevant
Example	“Our project uses Python 3.12.”	/review-pr	“Use our standard PR review process.”

A simple mental model:

CLAUDE.md → “These are the general rules Claude should know.”

Slash Command → “Explicitly perform this action.”

Skill → “Use this playbook when this type of work comes up.”

The key idea

The simplest way to remember Skills is:

A Skill teaches Claude a repeatable process once, so we don't have to explain the same process every time.

If we repeatedly find ourselves telling Claude how to perform a particular type of task, that process is a good candidate for a Skill.

Teach once → Reuse automatically when relevant.

Enterprise Search

Enterprise Search is a pre-configured project that searches across a company's connected tools in one place — Microsoft 365, Slack, Google Workspace, wikis, CRM — instead of us hunting through each app individually.

We ask a question, Claude searches every connected source in parallel, and synthesizes one answer with citations back to where it found each piece.

Research

Claude's Research mode is built for the questions that need more than one search — it plans out a research approach, searches the web (and any connected sources) across multiple steps, and comes back with a structured, cited report rather than a single quick reply.

Worth reaching for on genuinely open-ended questions — market analysis, competitive landscapes, "what do we currently know about X" — not on questions with one clear factual answer.

Claude Design

Claude Design is a collaborative design and prototyping tool — it lets us create interactive designs, prototypes, and presentations just by describing them in conversation, combining a frontier model with the functionality of a traditional design tool.

---

Working With Claude Well

Writing Effective Prompts

Every interaction starts with a prompt, so it's worth spending a moment on what makes one good. The best mental model: talk to Claude the way we'd talk to a capable coworker — naturally, concisely, conversationally.

Three things worth including:

1. Setting the stage — our role, and any context Claude should know about the work.
2. Defining the task — the specific action we want (write, analyze, build, something else).
3. Specifying rules — tone, format, or examples of what "good" looks like.

Example, using all three:

"I'm the marketing lead at an indie streaming startup, and we're preparing an investor pitch deck for Series A investors. Can you research the current state of the independent film streaming market and identify key trends, competitor positioning, and growth opportunities? Use current web research with citations and structure it as a professional report of up to 5 pages, with an executive summary, market analysis, competitive landscape, and growth opportunities."

Stage: the pitch deck and the startup context. Task: research the market, with specific angles (trends, competitors, opportunities). Rules: cited web research, a 5-page professional report with named sections.

Learning Mode

Learning Mode changes how Claude responds — instead of handing us the answer directly, it acts more like a tutor, using questions and prompts to guide us toward finding the answer ourselves.

It started as part of Claude for Education, then rolled out to all users in August 2025. Under the hood, it's not a different model — it's the same Claude, working from a system prompt that nudges it toward a guided, teaching style instead of a direct one.

You Bring the Expertise

Claude knows how to do things. It doesn't automatically know what matters to us, specifically.

Without our own judgment in the loop, Claude is a brilliant intern with no context — it can produce flawless-looking text with no way to know whether it's actually accurate, useful, or right for our situation. That judgment call is still ours to make.

Continued and Frequent Communication

The first response to a genuinely complex ask is usually generic. That's not a prompt-wording problem to solve with one longer message — it's fixed by iterating: giving feedback, asking follow-ups, correcting course as we go.

Because Claude's context window holds the whole conversation, each correction compounds — by the tenth exchange in a session, it's working from a much sharper picture of what we actually want than it had after the first message. A single one-shot prompt, however carefully worded, can't reach that same depth.

The AI Fluency Framework

AI Fluency is the skill of using AI effectively, efficiently, and ethically — not just knowing how to type a question into a chat box, but knowing when to use AI, how to guide it, and how to judge what it hands back.

Competency	In plain terms	The question it answers
Delegation	Deciding who does the task — us, a plain tool, or AI.	"Should I do this myself, or hand it to Claude?"
Description	Writing clear, specific instructions.	"How do I ask for exactly what I need?"
Discernment	Checking the output for mistakes, bias, or hallucinations before trusting it.	"Is this answer actually correct and usable?"
Diligence	Using AI responsibly — credit, privacy, wider impact.	"Am I using this fairly and safely?"

---

Where We Go From Here

That's the full vocabulary set: from the basics (LLM, context window, Constitutional AI, extended thinking) through how Claude gets things done (tool use, agents, MCP, structured output), Claude's workspace features (Code, Cowork, Projects, Artifacts, Skills, Enterprise Search, Research, Design), and the habits that make working with it actually effective.

None of these ideas are complicated in isolation — they just tend to get thrown around together, which makes them feel more intimidating than they are.

From here, both paths converge on the same place:

Continue the CCAR-F preparation → Domain 1: Agentic Architecture & Orchestration