CCAR-F · Agentic Architecture
Sessions, resume, fork or start fresh
A session keeps the whole history: what was asked, what was decided and what each tool returned. That is useful as long as it is still true.
How to choose
| Situation | What to do |
|---|---|
| Nothing changed and the context is still useful | --resume |
| Some files changed, but the rest of the analysis still holds | --resume and tell it which files changed |
| Tool results are broadly out of date (stale context) | Fresh session with a summary |
| You want to try alternatives from the same baseline | fork_session |
Stale context
If you changed files, the history holds the old versions in its tool results. When only a few changed and the rest of the analysis still holds, resume and tell the agent which files changed, so it re-analyses them without redoing the whole exploration. But if much of what the tools returned is no longer true, resuming is fragile: the new version is added, the old one is still there and can keep steering the reasoning. Stale context is solved with a fresh session and summary injection that carries:
- findings and decisions;
- open questions and next steps;
- which files changed.
Never the full transcript or the old file contents: that’s a resume in disguise.
Fork
fork_session copies the current session into a new branch. It is for exploring two strategies from the same analysis, but it inherits everything, stale data included, so it cleans nothing. Also, a fork isolates the context, not the disk: if one branch edits files, the other one goes stale. For that, each branch needs its own copy of the code (a git branch or a worktree).
Other cases
- Several investigations in parallel: name your sessions and return with
--resume <name>.--continueopens the most recent one, which may not be the one you want. - Valid doesn’t mean useful: if the context is full of old exploration that no longer helps, a fresh session with a summary is also the way to go.
- Long jobs: persist a checkpoint outside the conversation, with what finished and what it produced. On restart, progress comes from that state, never from what the model says about itself.
Quick question
A practice exam question on this domain. It counts towards your progress.
A telecom provider's customer support agent lets the model decide which tools to call and in what order. It handles plan changes, billing questions, number porting and fault reports, and the team is pleased with how flexibly it adapts to different conversations.
The architecture team is now writing internal guidelines for future agents and wants a clear rule for when this model-driven approach is not good enough. Developers have argued about whether the trigger should be the number of tools, the volume of conversations or what users ask for. The guidelines will apply to the four new agents planned for next year.
In which situation should this model-driven approach be replaced by programmatic enforcement?