Session state, resumption and forking: CCAR-F task statement 1.7

CCAR-F · Agentic Architecture & Orchestration (27% of the exam)

Task statement 1.7 sits in Agentic Architecture & Orchestration, 27% of the CCAR-F exam. It tests what to do with an agent's earlier work when you come back to it: carry on, branch off to try something different, or start again with a summary because the old results are out of date.

What the official guide covers

The Claude Certified Architect Foundations exam guide (version 1.0, effective July 2026) lists this under task statement 1.7, "Manage session state, resumption, and forking":

Knowledge of	Skills in
Resuming a named session with `--resume <session-name>` to continue a specific earlier conversation	Using `--resume` with session names to continue an investigation across working days
`fork_session` to create independent branches from a shared analysis baseline	Using `fork_session` to explore options in parallel, such as two testing strategies or two refactoring approaches from one codebase analysis
Telling the agent about changes to files it already analysed when a session resumes after code changes	Choosing between resuming (earlier context is mostly valid) and starting fresh with an injected summary (earlier tool results are stale)
Why a new session with a structured summary is more reliable than resuming with stale tool results	Telling a resumed session which files changed so it re-checks only those, instead of exploring everything again

What a session holds

A session is the saved conversation: your prompts, every tool call, every tool result and every reply. Claude Code writes it to disk as you work. When you resume, the agent gets that whole history back, including the files it read and the conclusions it reached.

Two facts drive most exam answers:

A session saves the conversation, not your files. Resuming or forking does not change or restore any file on disk.
Old tool results come back as they were. If a file changed after the agent read it, the session still holds the old contents. The agent does not know the file changed unless you tell it.

Resume, fork or start fresh

	Resume	Fork	Start fresh with a summary
What you get	The same session, continued	A new session with a copy of the history; the original is unchanged	A new session that holds only the summary you give it
Use when	Earlier context is still mostly true	You want to try a different direction and keep the original	Earlier tool results are largely out of date
Claude Code	`claude --resume <name>` or `/resume <name>`	`claude --resume <name> --fork-session`, or `/branch` inside a session	`claude`, then paste the summary
Agent SDK (Python)	`resume=session_id`	`resume=session_id, fork_session=True`	A new `query()` with the summary in the prompt

Naming and resuming sessions in Claude Code

Name a session so you can find it again. Start with claude -n auth-investigation, or run /rename auth-investigation during the session. The next day, return to it directly:

claude -n auth-investigation                  # day 1: start a named session
claude --resume auth-investigation            # day 2: continue it
claude --resume auth-investigation --fork-session   # branch a copy to try another approach

claude --continue reopens the most recent conversation in the current directory, which is handy but not the same as picking a specific named investigation. Inside a session, /branch try-streaming creates a copy of the conversation so far and switches you into it, leaving the original intact.

Scripts work the same way, using the session ID instead of a name. Read the ID from the JSON output of the first run and pass it to the next:

session_id=$(claude -p "Plan the billing module migration" --output-format json | jq -r '.session_id')
claude -p "Carry out step 1 of the plan" --resume "$session_id"

One detail catches people out: plain claude --continue skips sessions that were created with -p or the Agent SDK. A pipeline that relies on "the last session" can pick up the wrong one, so pass the ID.

Rewind, summarise or fork?

Three Claude Code features look alike and do different jobs:

Feature	What it does	Use it when
`/rewind` (or Esc twice on an empty prompt)	Returns the same session to an earlier prompt; can also restore the file edits Claude made since then	The last few turns went the wrong way and you want them gone
"Summarize from here" in the rewind menu	Compresses part of the conversation into a summary and stays in the same session	A long debugging detour fills the context and you want to stay in the session
Fork (`--fork-session` or `/branch`)	Creates a second session from a copy of the history; the original stays as it was	You want to keep both directions and compare them

Rewind restores only edits made through Claude's file editing tools. Changes made by shell commands, by most subagents or by you outside the session are not rolled back, so keep git as the real record.

Resuming and forking in the Agent SDK

In the Python SDK, read the session ID from the result message and pass it back with resume. Add fork_session=True to branch instead of continuing.

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, ResultMessage

async def run(prompt, **opts):
    session_id = None
    async for message in query(prompt=prompt, options=ClaudeAgentOptions(**opts)):
        if isinstance(message, ResultMessage):
            session_id = message.session_id
    return session_id

async def main():
    # 1. Shared baseline: analyse the codebase once
    base = await run("Map the payments module and its test coverage.",
                     allowed_tools=["Read", "Grep", "Glob"])

    # 2. Two independent branches from the same analysis
    plan_a = await run("Propose a testing strategy built on contract tests.",
                       resume=base, fork_session=True)
    plan_b = await run("Propose a testing strategy built on end-to-end tests.",
                       resume=base, fork_session=True)
    print(base, plan_a, plan_b)   # three different session IDs

asyncio.run(main())

Each fork gets its own session ID, and the baseline session stays unchanged, so you can return to it or fork it again. Because forking copies the conversation and not the filesystem, branches that edit code should work in separate git worktrees or use file checkpointing. Otherwise both branches change the same files.

Telling a resumed agent what changed

When you resume after code has changed, tell the agent exactly which files changed and ask it to re-read only those. That keeps the valid parts of its earlier analysis and fixes the stale parts.

Since this session, these files changed on main (from git diff --name-only):
- src/payments/refund.py  (refund_order now takes a reason argument)
- tests/test_refund.py
Re-read only these two files, update your earlier findings that depend on them,
then continue with the migration plan.

Without this, the agent works from the old contents it read before and may suggest edits to code that no longer exists. With it, the agent does not need to explore the whole module again.

When to start fresh instead

If most of what the agent read is now out of date (a large merge, a rewrite, a dependency upgrade), resuming brings back a history full of wrong tool results. Start a new session and give it a structured summary of what still holds:

the goal and the decisions already made
conclusions that do not depend on the changed code
open questions
the files to look at first

Anthropic's session documentation makes the same point for moving work between machines: capturing the results you need and passing them into a fresh session's prompt is often more reliable than carrying transcript files around.

The summary is only as good as the instruction that produced it. "Summarise the session" tends to drop exactly what the next session needs. Ask for named items: every file changed and why, every decision and the option rejected, every error hit and how it was resolved, and what is still open. Claude Code takes the same steer: text after /compact tells the summary what to keep, and the summarize options in the rewind menu accept instructions too.

Session state in your own application

When you build an agent on the API or the Agent SDK, you decide what survives between sessions. Make that choice at design time, from the shape of the work:

Memory approach	What carries over	Fits	Watch for
In-context only	Nothing after the session ends	Short, self-contained sessions	Cost and context grow with every turn
External storage	State saved to a database and loaded again at the start	A user who returns over days, or several agents sharing state	Read and write logic you must build and secure
Summary injected at start	A condensed record of earlier sessions	Long-running assistants whose full history would not fit	Anything the summariser left out is gone
Stateless	Nothing	Jobs that finish and close, such as converting one file	Follow-up questions have no history to draw on

A support agent that replays every earlier transcript into each new session works in testing with one long session, then runs out of context within a week of short daily sessions in production. Storing state outside the context and loading only what the current session needs avoids that.

Rules that decide exam answers

Resume a specific session by name. To continue one particular investigation, choose --resume <name>, not --continue, which picks whatever ran last.
Fork to compare. Two approaches from the same analysis means forking the baseline, not running both in one session or repeating the analysis twice.
Forks branch the conversation only. If both branches edit files, keep their file changes apart (separate worktrees or checkpoints).
Name the changed files. After code changes, the best resume option tells the agent which files changed for targeted re-analysis, not "re-explore everything".
Stale results mean start fresh. When most earlier tool results are out of date, a new session with a structured summary beats resuming.
Rewind undoes, fork keeps both. To drop a wrong turn, rewind. To compare two directions from the same point, fork.

Where it appears in the exam

Domain 1 is a primary domain in three of the six exam scenarios: Customer Support Resolution Agent, Multi-Agent Research System and Developer Productivity with Claude. Long investigations of unfamiliar or legacy code that run over several days fit the Developer Productivity scenario most closely. The guide's preparation advice also asks candidates to build an agent with session management.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A developer spent a day in a named Claude Code session analysing 40 files for a migration. Two days later she resumes it with claude --resume migration-audit. Meanwhile, teammates merged changes to 3 of those files, and the agent now suggests edits that use an old function signature. What should she do?

A. Start a new session and ask the agent to read all 40 files again.B. Fork the session with --fork-session and continue in the fork.C. Run /compact so the agent works from a summary of the session.D. Tell the resumed agent which 3 files changed and ask it to re-read only those.

Answer: D. Most of the earlier analysis is still valid, so a targeted update keeps it and fixes the stale part. A throws away a day of valid work. B copies the same stale results into a new branch. C summarises the old results but does not replace them with the new file contents.

Question 2

An agent spent an hour mapping a monolith's dependencies. The team now wants to compare two refactoring approaches, each starting from that same analysis, and each approach will edit code. Which setup fits best?

A. Fork the analysis session once per approach and run each branch in its own git worktree.B. Resume the analysis session for approach one, then try approach two in the same session.C. Start two new sessions and ask each one to redo the dependency analysis first.D. Resume the same analysis session in two terminals at once, one per approach.

Answer: A. Each fork starts from the shared baseline with its own history, and separate worktrees stop the two branches from editing the same files. B mixes the two approaches in one history. C repeats the hour of analysis twice. D interleaves messages from both terminals into one transcript.

Build exercise

Start a named session with claude -n module-audit, ask Claude to map one module, then exit and resume with claude --resume module-audit. Confirm it remembers the map.
Edit one function the agent read, resume again without saying anything, and ask about that function. Note the stale answer. Then name the changed file and ask again.
Use claude --resume module-audit --fork-session twice to create two branches with different goals. Run claude --resume and find all three sessions in the picker.
Repeat steps 1 and 3 with the Python Agent SDK, using resume and fork_session=True, and print each session ID to confirm the forks differ from the baseline.

Practise this topic

Claude Certified Architect practice exam: free, 20 questions, no sign-up
Claude Certified Architect hub
CCAR-F study guide: all topics
Previous topic: 1.6 Task decomposition
Next topic: 2.1 Tool interface design

Sources

Claude Certified Architect Foundations Exam Guide, version 1.0, effective July 2026 (Anthropic), task statement 1.7
Claude Agent SDK documentation: Work with sessions
Claude Code documentation: Manage sessions
Claude Code documentation: Checkpointing
Claude Code documentation: Run Claude Code programmatically