Free lesson · Claude Certified Architect - Foundations (CCA-F)
What Claude Code Is and How the Session Model Works
An Agent That Lives in Your Project
Claude Code is an agentic coding tool. It reads your files, edits them, runs commands, and searches your codebase - working inside your actual project rather than in a chat window you paste code into.
Everything from Domain 1 applies to it. It runs an agent loop. It calls tools. It has to decide when it is finished. The difference is that its tools operate on your repository and your machine.
Important: This domain carries 20 percent of the exam, against roughly 3 percent on the Developer exam. Most candidates assume the Developer credential is the one that tests tooling and under-prepare here. It is the reverse, and this is the most under-prepared domain relative to its weight.
Interactive animation: This domain carries 20 percent of the exam, against roughly 3 percent on the Developer exam.
Why This Is Different From Chat
The distinction that matters is where the work happens.
| Pasting code into a chat | Claude Code |
|---|---|
| You choose what it sees | It can find what it needs |
| You apply the changes | It edits the files directly |
| No knowledge of the wider project | Can search and read across the repository |
| Cannot verify anything | Can run tests and see the result |
That last row is the one that changes the nature of the work. An agent that can run your test suite can check whether its change worked, see the failure, and try again. That is the perceive-reason-act-observe loop from Module 01 with a real feedback signal.
Without it, you are the feedback loop.
The Session
A session is one working conversation with Claude Code in a project.
graph TD
A[Session starts] --> B["Loads configuration<br/>and instructions"]
B --> C["You describe a task"]
C --> D["Agent loop:<br/>read, reason, act, observe"]
D --> E{Needs permission?}
E -->|Yes| F["Prompts you"]
F --> D
E -->|No| D
D --> G[Task complete]
G --> C
This diagram shows the Claude Code session model. A session starts by loading configuration and instructions. You describe a task, and the agent loop of read, reason, act, and observe begins. When an action needs permission, it prompts you and then continues. When the task is complete, control returns to you for the next task.
Two things happen at session start that matter for everything in Domain 3.
Configuration loads. Instruction files, settings, permission rules, hooks, and connected MCP servers are all read at this point. Module 09 covers the hierarchy in detail.
Context accumulates from there. Everything read, every command run, every result - it builds up across the session, exactly as Module 03 described.
Interactive animation: A session loads configuration at the start, then runs the agent loop, prompting you whenever an action needs permission.
Sessions Are Where Context Lives
That second point has real consequences, and they are the ones people feel day to day.
A long session accumulates a great deal: file contents, command output, search results, the whole history of what has been tried. From Module 03, that context is re-sent every turn, so a session gets more expensive as it goes.
It also gets less focused. Twenty files read for a task you finished an hour ago are still there, competing for attention with what you are doing now.
| Session length | What happens |
|---|---|
| Short, one task | Focused, cheap, easy to follow |
| Long, one task | Context grows but stays relevant |
| Long, many unrelated tasks | Expensive, and old work clutters the current one |
Tip: Start a fresh session when you switch to an unrelated task. Carrying an hour of unrelated context into new work costs money on every turn and gives the agent material that is no longer relevant. This is the single easiest habit that improves both cost and quality.
What a Session Can Reach
A session operates in a working directory - your project. That scope is the practical boundary for most of what it does.
But the same caution from Module 07 applies here. Claude Code runs with your permissions on your machine. Its tools are constrained by the permission system, which Topic 5 covers, and underneath that it is a process with your access.
Warning: "It only works in my project" describes the usual case, not a hard limit. A shell command can reach outside the working directory, and the thing standing between you and that is the permission system rather than any inherent boundary. Understanding permission modes is therefore a security topic, not a convenience one.
The Agent Loop, Concretely
Watching a real task makes the model clear.
Example: Task: "The date parsing in the import module is failing on European formats. Fix it."
Turn What happens 1 Searches the codebase for the import module 2 Reads the file it found 3 Reads the related test file 4 Proposes an edit - prompts for permission 5 Applies the edit after approval 6 Runs the test suite - prompts for permission 7 Sees two failures, reads the output 8 Makes a second edit correcting the timezone handling 9 Runs the tests again, they pass 10 Reports what changed Notice turns 6 and 7. The agent found out its first fix was incomplete because it could run the tests. Without that, the session would have ended at turn 5 with a change nobody had verified.
That feedback loop is why Claude Code is more than a code generator, and it is why the tool system in the next topic matters so much.
Reading Is Cheap, Acting Is Not
A distinction that shapes how Claude Code is designed and how you should think about it.
graph LR
A["Reading and searching<br/>Changes nothing"] --> B["Generally auto-approved<br/>The agent cannot help<br/>without seeing the code"]
C["Editing and running commands<br/>Changes things"] --> D["Prompts by default<br/>This is your review point"]
This diagram contrasts two kinds of operation. Reading and searching change nothing and are generally auto-approved, because the agent cannot help without seeing the code. Editing and running commands change things, so they prompt by default, and that prompt is your review point.
This asymmetry is why the permission system is usable at all. If every read required approval, nothing would get done. Because reads are safe, the prompts concentrate on the moments that matter - which is Module 04's principle that guardrails belong at the act stage, not everywhere.
It also explains a common experience. A session may read a dozen files without asking and then stop before a one-line edit. That is not inconsistency; it is the system working as designed.
Where This Fits in the Domain
Interactive animation: The domain mapped: Module 08 fundamentals, Module 09 configuration, Module 10 commands, skills and subagents, Module 11 hooks.
Module 08 covers the fundamentals - what it is, what its tools do, how to get it useful in a real codebase, and how permissions work.
The rest of the domain builds on this. Module 09 is the configuration hierarchy that loads at session start. Module 10 is the mechanisms you build on top - commands, skills, subagents. Module 11 is hooks and automation, where the enforcement thinking from Module 04 returns.
All of it assumes the session model from this topic.
One more property worth internalising: Claude Code is stateless between sessions in the same way the API is. Nothing carries over automatically. What persists is what lives in the project - instruction files, configuration, and the repository itself. That is why Module 09's configuration work matters so much: it is the only thing that reliably reaches every future session, including sessions started by other people.
Interview: Scenarios in this domain often describe a team's working setup and ask what to change. The session model matters because it determines what loads when - configuration at start, context accumulating through. A scenario about instructions not taking effect is often about when configuration is read, and a scenario about degrading quality over a long session is usually about accumulated context.
In Short
Claude Code is an agent that works inside your project rather than in a chat window. It reads, edits, searches, and runs commands, which gives it a real feedback loop - it can check whether its own change worked.
A session is one working conversation. Configuration loads at the start, and context accumulates from there, which makes long multi-task sessions both expensive and unfocused.
The domain is worth 20 percent of the exam, considerably more than most candidates expect, and everything in it rests on this model.
Exercise: Starter. Name the two things that happen at session start. Then say why starting a fresh session for an unrelated task is worth doing.
Intermediate. Take a task you would give Claude Code and write out the turns you would expect, marking where it would need permission. Compare that against what actually happens when you run it.
Advanced. Take a long session you have had and estimate how much of its accumulated context was still relevant at the end. That proportion is the argument for shorter sessions, and it is usually lower than people expect.
In Short
Claude Code is an agent working inside your project. It reads, searches, edits, and runs commands, which gives it a feedback loop - it can check whether its own change worked, and correct itself when it did not.
A session is one working conversation. Configuration loads at the start; context accumulates from there and is re-sent on every turn, which is why long multi-task sessions get expensive and unfocused.
Reads are cheap in permission terms and expensive in context terms. Edits and commands are the reverse. That asymmetry is what makes the permission system usable, and it shapes everything else in this domain.
Quiz: Quick check: A developer works in one Claude Code session all day across four unrelated tasks. They notice responses getting slower and less focused. What is the most likely cause?
A) The model degrades over long conversations and needs restarting periodically B) Context from earlier unrelated tasks has accumulated, so every turn carries irrelevant material and costs more C) The permission mode is set incorrectly D) The project is too large for Claude Code to handle
Answer: B - context accumulates across a session and is re-sent every turn. Four tasks' worth of files and output is expensive and gives the agent material that no longer applies. A fresh session per unrelated task resolves both.