Why AI agents forget what worked.

Because the tool that observes an outcome is almost never the tool that needed it. An agent drafts and publishes a post. Six days later somebody comments; three weeks after that a reply turns into a meeting, and the meeting is recorded in a CRM by a person who never saw the post. Each system holds one fragment and none holds the causal chain. So when the same agent runs again, it starts from the same blank state it started from last time — not because it lacks intelligence, but because nothing handed it the answer. This is a plumbing problem rather than a model problem, which is why swapping in a stronger model changes surprisingly little: a better writer with no memory of what landed is still guessing, just more fluently.

No, and the reason is structural rather than a matter of size. A context window is scoped to one conversation and one agent. The outcomes that matter here arrive after that conversation has ended — days or weeks later, through a channel the agent was never watching — so there is no window still open to put them in. Worse, a window is not shared: a lesson learned by the agent writing social posts is invisible to the agent writing outreach, even though it is exactly the lesson that would have helped. What the problem actually calls for is a durable store that sits outside any single model: written to when results land, and read by whichever agent acts next.

Four things, and they map to four moments rather than four database tables. First, the advice an agent was given before it acted — because you cannot later tell a good outcome from a lucky one without knowing what was intended. Second, what it actually did, including which advice it followed and which it ignored. Third, what genuinely came back: a reply, a meeting, closed revenue, arriving late and in pieces, which is how real outcomes arrive. Fourth, what a human thought. That last one is usually sitting in plain sight as the edit somebody made before hitting approve, and most systems discard it.

Because it is the only signal in the set that someone paid attention to produce. Clicks and opens are cheap and ambiguous; an edit made in the seconds before approval is a person saying "not like that, like this" about a specific sentence, with the corrected version attached. It is precise, it is attributable, and it is almost free to collect, because it already happens in any workflow with a human approval step. The useful pattern is repetition: one edit is a preference, and the same correction three times is a rule the agents should be keeping without being asked.

Fine-tuning bakes what was learned into weights nobody can read. That is acceptable when the lessons are certainly true, and a serious liability when they are not — and early lessons frequently are not, because they are drawn from small samples in a narrow window. If a lesson turns out to be wrong, there is no line to delete; there is only a retrain. Keeping each lesson as a retrievable record with its evidence attached — how many similar cases, what the measured difference was, which runs it came from — means it can be shown to whoever asks, argued with, and removed. Inspectability is not a nice-to-have here. It is what makes the system safe to trust.

Start with the approval step you already have, because it is the cheapest place to capture the highest-quality signal. Log the draft, the edit, and the final version, and do nothing clever with them for a few weeks. Then read them. The recurring corrections in that pile are your first real rules, and they will be more specific than anything you would have written as a style guide up front. Only after that is it worth wiring outcomes back from downstream systems, which is the harder half of the work because it crosses tools that were never designed to talk to each other.