---
name: charter-agent-session-learning
description: 'Learn from recorded agent sessions and transcripts: what went wrong
  and why, what worked, repeated corrections and changes of direction; return ready
  changes for whoever can make them. Not a recap or catch-up, live recovery or automatic
  instruction rewriting.'
metadata:
  content_version: charter-agent-session-learning@2026.10.20.0
---
# Charter · Agent Session Learning

A session record connects what the person wanted, what reached the agent, what
it chose and did, and what the person got. Learning from it explains where that
held or broke and why, keeps what worked, and turns both into changes someone
can make. Acknowledging a correction is not applying it: an agent can accept,
save and explain a correction while its next brief still uses the old premise.
Catching up or recovering live work needs none of this.

## Establish what the record can show

Establish the source's identity, scope and every way human input arrives:
ordinary turns, queued prompts, attachments, interruptions, and text carried
inside injected wrappers. Inspect the actual record format when a view cannot
show who supplied a message or whether it was replayed. Use delivery or message
identity to tell replay from repetition: one delivery copied into successive
context windows is one input; the same words in two human turns are two. Where
identity is unavailable, keep the ambiguity.

Keep each excerpt traceable to its original location, and disclose omitted
payloads, deduplication and missing child histories. Absence from an incomplete
view is not evidence that the person never asked. An imported review shows what
its author proposed, not what the person adopted.

## Cover what was asked

A named session or transcript means all of it unless the person narrows it; do
not ask for a longer request. When a record is too large to read faithfully in
one context, map chronological slices, reduce the relationships across them,
then synthesize. Every in-scope exchange is read for meaning; an activity index
locates evidence without showing that it was understood, and an assignment is
not a completed reading. Open
[Large-record analysis](references/large-record-analysis.md) for extraction,
assignments, sampling and studies across many sessions. If coverage stays
incomplete, name what was not read and the conclusions it limits.

## Start from earlier learning

Before mapping, look for earlier or concurrent assessments of the same work and
what was sent or applied from them. Treat each as a fix under test: was it
proposed, applied, or shown to govern later work? Does later evidence support,
narrow or overturn its explanation? A fix that reached the later decision and
did not hold calls for a different lever, not a repetition. For a session still
running, read past the analyzed point before saying what is still live.

## Reconstruct intent apart from the agent's account

Read requests as commitments, not message counts: one turn may hold several,
several turns may clarify one. A later message may add a requirement, repeat
one already given, replace a choice, correct a misreading, or ask for status
without authorizing more work, and each leads to a different comparison.
Silence establishes neither acceptance nor closure. Compare that trajectory
with the agent's acknowledgements, plans, briefs, actions and results. Judge
each action against the intent in force when it was taken.

## Explain the mechanism at the failing decision

Establish a divergence before explaining it. A partial result can be a
legitimate checkpoint; keeping a capability owed differs from dropping it or
claiming the whole result without it. A correction shows that the person met a
gap, not which part failed. Locate the break: was the requirement missing from
the brief, contradicted there, carried but not executed, or executed without
producing the result?

Then explain the decision where it failed: what the agent had in front of it
then (the instructions it loaded, a compaction summary, a helper's brief, its
own notes and plans), what it could control, and which observation would
distinguish the explanations. A remainder missing from the next brief may never
have reached the agent, so delivery needs repair; may have arrived without
becoming owed work, so acceptance does; or may have been rightly deferred, so
it should be kept with its condition. When the evidence cannot tell them apart,
say so and choose a repair that works across them. Group episodes under one
explanation only while it supports one repair. Repeated status requests can
mean the reports leave the person to reconstruct the work or can simply follow
real progress; repeated corrections can mark a dropped requirement or a genuine
refinement.

Successful contrasts discriminate: if the same guidance reached two episodes,
missing guidance cannot explain why only one failed. An agent's
self-explanation does not prove its reasoning. When a conclusion concerns the
quality of what was delivered, inspect the delivered result itself; the absence
of complaint does not establish good work. Count friction shifted to the
person, such as reconnecting requirements or checking that a correction reached
the artifact. What worked can be know-how worth keeping: an example, template,
retrieval route or tool use.

## Match each verdict to its evidence

Guidance was adequate for a miss only if the specific point that would have
changed the failing choice was in front of the agent when it chose; a passage
on the same subject is not enough. Concluding that no change is needed takes
the same inspection as proposing one. For each candidate change, say whether
the point is already present (and where), present without reaching the
decision, or absent. One episode can justify fixing its own brief without
justifying a standing rule, and consequence ranks findings, not how often their
wording recurs. When others challenge a conclusion, ask them to test both
directions without handing them yours.

## Choose changes that can be made

Before calling a defect live, inspect where it would now live: instructions,
brief, plan, source or delivered artifact. Keep a historical miss, a live
defect, a repaired episode and a superseded direction apart, and make the
recommendation conditional when that inspection is unavailable. The change
follows the broken link: repair delivery, carry an understood correction into
the next executable brief, supply a better resource or tool, or keep a practice
that worked. Write a guidance change as the general distinction, with its
boundary and a nearby case where it does not apply; the person's words remain
evidence, not the rule.

Use `charter-instruction-system-design` when guidance is implicated,
`charter-systemic-failure-analysis` when the mechanism crosses owners,
`charter-prompt-design` for an actual prompt, `charter-skill-package-design`
for missing expertise, and `charter-ai-evaluation` for adopt-or-replace
decisions and systematic comparison.

Learning recommends; it does not write memory or instructions itself. Each
recommendation names the gap, where the change goes, who acts, its state
(proposed, sent, applied, held, did not hold) and, before anyone acts on it,
the next occurrence that would test the diagnosed behavior. Product progress
alone does not test it.

## Return one usable assessment

Open with what the person does now: send this message there, approve this edit,
or nothing, and say when nothing else is needed. Give the ready text itself,
not a description of it. Then state the judgment in a few sentences, naming
each main finding beside one of the person's own sentences that shows it (or
the exchange, if none), and the practices worth keeping. Evidence locations,
coverage and closeout come last. The result can recommend no change; it is
complete when the promised coverage is fulfilled and the judgment supports a
useful next choice.