- In short
- Additive configuration is the practice of explicitly adding a constraint, preference, or piece of background to standing instructions or Memory when Claude has not automatically captured a fact that matters, rather than re-supplying it every session. Configuration maintenance is additive as well as corrective: gaps get filled in, not just stale entries removed. If a fact keeps needing to be re-stated, that is a signal it belongs in configuration, and the choice between instructions and Memory follows the same instruction-versus-fact distinction as initial setup.
Maintenance adds as well as removes
Much of maintenance is corrective: finding stale elements and fixing them, as in the Memory lifecycle and the review cadence. But the CCAO-F exam also tests the other direction, an apply-level skill: maintenance is additive. Sometimes the problem is not a wrong entry but a missing one, a fact that matters which Claude never automatically captured, and the fix is to add it to configuration.
The signal is repetition. If you find yourself re-supplying the same constraint, preference, or piece of background in conversation after conversation, that recurring re-explanation is telling you the fact belongs in configuration. Rather than re-stating it every session, you capture it once, and the correction stops being needed.
- Additive configuration
- The practice of explicitly adding a constraint, preference, or piece of background to standing instructions or Memory when Claude has not automatically captured a fact that matters, instead of re-supplying it each session. Configuration maintenance is additive as well as corrective, filling gaps rather than only removing stale entries. A fact that keeps needing re-stating is the signal to capture it, and the choice of slot follows the instruction-versus-fact distinction.
The signal: re-stating the same thing
The practical trigger for additive configuration is noticing a repeated correction. Claude does not capture every fact automatically, so a constraint you care about, a preference in how something is done, a bit of background context, may keep dropping out and needing to be re-supplied. Each time you re-explain it, you are paying the same cost again.
That repetition is the diagnostic. A fact re-stated once is a normal conversation; a fact re-stated every session is an un-captured configuration gap. The additive move is to recognise the pattern and fill the gap deliberately, so the fact is present from then on without anyone re-supplying it. This is the mirror image of anticipating use cases: there you pre-load known needs, here you capture a need that surfaced through repetition.
Choosing the slot for a captured fact
Adding the fact is only right if it goes in the right place, and the choice uses the same logic as initial setup. Follow the instruction-versus-fact distinction: if the missed item is a behavior rule, it belongs in standing instructions; if it is an evolving Project-specific fact, it belongs in Memory. The decision does not get a special "it was captured during maintenance" rule; it is placed by kind, exactly as it would have been at setup.
There is one refinement the exam watches for. Not every captured fact should default to Memory. If the item is actually a stable reference fact, it may belong in the knowledge base rather than Memory, and if it is a behavior rule it belongs in instructions. Adding everything to Memory by reflex is a slot mistake; the additive move still routes each fact to the mechanism its kind calls for.
What the CCAO-F exam trips candidates on
The exam sets two traps. The first is repeatedly re-supplying the same constraint or preference in every conversation instead of adding it once to configuration. The scenario shows someone re-explaining the same thing session after session; the credited answer captures it in the right slot so the re-explanation stops. Treating a recurring re-supply as normal rather than as a signal is the tell.
The second is adding every missed fact to Memory by default without considering whether it is actually a stable fact that belongs in the knowledge base or a behavior rule that belongs in instructions. The scenario dumps a captured item into Memory reflexively; the credited answer routes it by kind. Both traps reward the additive discipline done correctly: fill the gap, but place the fact in the mechanism its type calls for.
Worked example
In a reporting Project, a user re-explains the same two things almost every session: that the team must never quote figures without a source, and that the current fiscal year runs February to January. What should be done, and where should each go?
Both items are un-captured gaps, so the additive move applies, but they route to different slots.
Re-explaining the same two things nearly every session is the diagnostic signal: these are facts Claude did not automatically capture, and re-supplying them each time is the first trap. The additive fix is to add them to configuration once so they stop needing to be re-stated. That is the easy half; the important half is placing each correctly, and defaulting both to Memory would be the second trap.
"Never quote figures without a source" is a behavior rule, how Claude should act on every factual claim, so it belongs in standing instructions (and it should be paired with sources in the knowledge base to be usable). "The fiscal year runs February to January" is a fact. Because it is a stable, unchanging reference rather than an evolving Project decision, it fits the knowledge base better than Memory; if it were instead an evolving, Project-specific detail, Memory would be right. Routing by kind, using the same instruction-versus-fact logic as initial setup, is what makes the additive move correct rather than just convenient.
Common misreadings to avoid
Misconception
If Claude keeps needing a fact re-explained, you just re-supply it each session.
What's actually true
Misconception
Any fact you capture during maintenance should go into Memory.
What's actually true
How this shows up on the exam
Domain 5 questions describe a recurring re-explanation and ask what to do. The credited answer captures the fact once and places it by kind, behavior to instructions, evolving fact to Memory, stable reference to knowledge, rather than re-supplying it or dumping it into Memory by default.
Additive configuration complements the corrective Memory lifecycle and mirrors anticipating use cases in instructions. Its slot-selection logic is the instructions-versus-knowledge distinction, and it can surface during a broader root-cause audit as a gap to fill.
A user re-explains the same standing constraint to Claude in nearly every session because it keeps dropping out. What is the best response?
People also ask
What do I do when Claude keeps forgetting a fact?
Should a repeated constraint go in instructions or Memory?
Is configuration maintenance only about removing stale entries?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.