CCAR-F - Agentic Architecture & Orchestration (27% of the exam) - Section 1.7
Manage session state, resumption, and forking.
Named session resumption with the resume flag continues a specific prior conversation, and fork_session creates independent branches from a shared analysis baseline for exploring divergent approaches. Candidates should inform a resumed agent about files that changed since the prior analysis, and should choose between resuming (prior context mostly valid) and starting fresh with an injected structured summary (prior tool results stale) rather than defaulting to one of the two.
named session resumptionfork_sessionstale tool resultsstructured summary injectiontargeted re-analysis after file changes
A developer tooling squad at Aldergrove Systems has spent about forty turns with an agent mapping a legacy job scheduler, and the session now holds the call graph, the two configuration files and a list of the modules that touch the queue. Two engineers want to explore competing migration routes from that same starting point without disturbing each other. They resume the session with forking enabled so that each engineer gets a branch. What is the effect on the original session?
AEach fork keeps appending to the original session identifier, so the second engineer's turns are interleaved into the first engineer's history and both see one merged record.
BEach fork is recorded under a new session identifier and the original session is left unchanged, so both branches carry the same forty-turn prefix and diverge independently from it.check_circle Correct
CEach fork copies the history and then locks the original session against further resumption until one branch is discarded or its findings are merged back into the parent.
DEach fork shares one live history with the other branch, so each engineer sees the other's turns appear in context as soon as they are appended to the record.
Forking a resumed session copies the prefix into a new session identifier and leaves the source session untouched, letting branches diverge independently. Forking splits the conversation record at the point of resumption. Subsequent turns are written to a new identifier rather than back onto the source, so the parent session remains resumable in its original state and each branch accumulates its own history from the shared prefix onwards.
Why A is wrong: Tempting because this is exactly what plain resumption without forking does, but forking exists precisely to avoid that interleaving by giving the branch its own identifier.
Why B is correct: Correct, because forking on resume writes subsequent turns to a new session identifier while the source session stays as it was, which is what makes two independent explorations from one shared prefix possible.
Why C is wrong: Tempting because branch-and-merge in version control does impose this kind of workflow, but a session record has no locking or merge step and the parent stays resumable throughout.
Why D is wrong: Tempting because both branches start from identical content, but the shared prefix is copied rather than shared live, so later turns in one branch never enter the other's context.
Exam traps in Agentic Architecture & Orchestration
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-F bank for this domain.
The Read tool served a cached copy for a path it had already read inside the same session record, so half the values the agent quoted came from that cache.
errorWhy it is wrong: Tempting because caching by path would be a reasonable optimisation, but each Read executes against the filesystem and returns current content, so the newer values were read correctly.
Raise the per-session ceiling on model calls so the agent has room to re-derive the decisions it appears to have lost track of during the resumed work.
errorWhy it is wrong: More iterations sound like more thinking room, but the rejected decision is present in the transcript rather than missing from it, and extra turns lengthen the conversation that is already causing the latency.
Raise the output limit on each invocation so a stage can write a longer prose summary, giving the next session more of the detail the previous stage gathered before it begins its own work.
errorWhy it is wrong: Tempting because the losses do look like a summary that was too short, but a longer summary is still a lossy retelling of tool results the next session cannot inspect, and it raises the token bill the team is trying to cut.