Same task, same context, same tools. It just didn't perform. The confidence that had been there in prior runs was gone. It hedged where it used to commit. It asked clarifying questions it used to skip because the pattern was obvious. I had built something that could forget.
That realization sent me down a rabbit hole I wasn't expecting: century-old memory science that turned out to be the missing piece.
The Problem Nobody Names
When we talk about AI agent capability, we mostly talk about initial acquisition: training, fine-tuning, skill scaffolding, retrieval quality. We obsess over what the agent knows on day one.
What we don't talk about is what happens over the operational lifetime of the system, as the agent runs real tasks, accumulates episodic history, and gets pulled in different directions depending on what the pipeline needs that week. Some skills get exercised constantly. Others go weeks without a single invocation. And in a system where skills are updated, reinforced, and pruned based on what's working, the ones that don't get touched start to drift.
This is skill decay. It's not a bug, exactly. It's an emergent property of any learning system that updates incrementally on feedback. The trouble is that the decay is invisible. Nothing breaks. The agent doesn't error out. It just gets slightly worse, then a little more, and one day you're watching a failure that looks inexplicable until you trace it back to a skill that hasn't been exercised in six weeks.
I had built a fairly sophisticated fleet before I noticed that none of those agents had anything like a maintenance schedule. They had skill files, memory, episodic logs. But no one was asking: when did this skill last get a real workout? How confident should we be in it right now?
The answer was already sitting in the open-source research community, in software that students worldwide use to learn languages and pass medical licensing exams.
What Ebbinghaus Figured Out
Hermann Ebbinghaus spent years in the late 1800s memorizing nonsense syllables and testing himself on them. Obsessive, yes. But what he found was remarkably precise: memory decays as a predictable exponential curve. Review something once and your retention drops fast. Review it again before you forget, and the next decay is slower. Do this enough times and the thing stabilizes into long-term memory.
The insight is that the timing of review matters as much as the review itself. Too early and you're wasting effort on something you'd remember anyway. Too late and you've already lost it and have to relearn from scratch. The sweet spot is reviewing just before the decay curve dips below a critical threshold. That's when review has the most effect.
Spaced repetition schedulers operationalize this. They track, for every item, three values: how stable the memory is (stability), how hard the item is to remember (difficulty), and the current probability you'd recall it right now (retrievability). From those values, the scheduler calculates when your next review should be.
FSRS, the Free Spaced Repetition Scheduler, is the modern, open-source implementation of this idea. It was developed with a published paper, validated empirically against human recall data, and is built into Anki, the most widely adopted flashcard tool in use today. What matters about FSRS isn't that it's clever. It's that it works. The retention predictions are accurate. The scheduling is tight. And the math is clean enough to be applied somewhere its designers never imagined.
What Three Parameters Can Do
Here's the realization I had at 2am on a Tuesday, which is the hour when most of my actual ideas show up.
An agent skill has a stability. It gets exercised frequently, or it doesn't. It degrades if it isn't run against real tasks. It recovers faster on re-exposure if it was once mastered well. That's exactly what FSRS models with the stability parameter.
An agent skill has a difficulty. Some skills are simple and universal, invoked constantly, trivially maintained. Others are narrow and complex, rarely triggered, requiring specific conditions to exercise meaningfully. The difficulty parameter captures this: hard skills need shorter intervals between reviews even when their stability looks acceptable.
And an agent skill has a retrievability at any given moment. If I want to know whether an agent can reliably execute a particular task right now, that question has a probabilistic answer based on how recently the skill ran, how hard it is, and how stable the agent's mastery has historically been. The FSRS framework gives me the machinery to compute that number.
I started thinking about what it would mean to build that into a fleet runtime. Not as a proxy metric or a vague confidence score, but as a first-class scheduling primitive. Every skill invocation is a review event. The outcome, success or failure, updates the skill's state. The scheduler computes when that skill should next be exercised, whether through an organic task or through a deliberate synthetic review. Skills that drift below a threshold get flagged or, in a more autonomous system, get triggered before the drift compounds.
The struggle was that agent skills aren't flashcards. Flashcards have binary recall: you either remember it or you don't. Agent skills produce graded outcomes across multiple dimensions. A skill might execute technically but fail on a quality bar. It might succeed in narrow conditions and fail to generalize. Mapping that onto the FSRS retrieval signal required some honest thinking about what "recall" even means for a non-human learner.
The working answer: retrievability for an agent skill is the probability that, given a representative task from that skill's domain, the agent would meet the quality gate. That's measurable. It requires a test harness, but test harnesses were infrastructure I was already building anyway.
The Thing That Fell Out
What surprised me wasn't the scheduling logic. It was what became visible once the framework was in place.
When you model skill mastery with stability, difficulty, and retrievability, you immediately see which skills are silently at risk. Not from explicit failure signals, but from neglect. A skill can look fine on every observable metric and still be trending toward brittleness, because its retrievability has been quietly falling and no one has been scheduling reviews.
I had been building a fleet that learned forward beautifully and decayed sideways, invisibly.
The FSRS framing gave me a way to see the decay, schedule against it, and prioritize where to invest synthetic review cycles. High-difficulty skills with declining retrievability get scheduled first. High-stability skills that run constantly maintain themselves. The scheduler does the calculus.
There's a deeper principle here that I keep returning to. Memory science was developed for biological learners in biological brains. But the underlying dynamics that Ebbinghaus found, and that FSRS operationalizes, are properties of any learning system that acquires knowledge through experience and loses it through disuse. The biology is incidental. The curve is structural.
An agent fleet is a learning system. Skills are acquired. They can be lost. And the right response to that isn't to panic-retrain when something breaks. It's to schedule maintenance predictively, based on the real decay dynamics, before the failure surface appears.
The late-night realization that started all of this was watching one of my agents fail. What came out the other side is a scheduling primitive built on a century of memory research.
The agents still forget. But now I know when.