Teaching agents to learn

Scheduled reflection turns past work into operating context for the next run.

Jack Dorsey and Roelof Botha recently described the role of a company world model in From Hierarchy to Intelligence:

“For the first time, a system can maintain a continuously updated model of an entire business and use it to coordinate work.”

I agree with that thesis. An agent system needs a working model of its own operations: which sources it trusts, how projects relate, why a decision was made and what a failure taught us. That model has to improve as the system is used. Transcripts, decisions and code provide the raw material, but the lessons still have to become part of the context future agents receive.

I had made a related point in Subjective Truth, while calling back to a Dave Thomas talk about expertise:

“Dave asserts that expertise cannot be boiled down to rules because we lose the original context for the rule in the process. Truth, he says, is contextual.”

That is the learning problem here. An instruction without the experience behind it can be applied confidently in exactly the wrong situation.

This may be why the Agentic Context Engineering paper stuck with me. It treats context as an evolving playbook and separates generation, reflection and curation. An agent session leaves evidence behind. Reflection proposes what the system might learn from it, while curation decides what deserves to persist, where it belongs and which sources should travel with it.

I built that cycle into Voxelbox, the local agent system I use across my projects. Meaningful sessions leave summaries behind. A nightly review filters noise, compares new observations with existing memory and extracts candidate lessons. Another pass revisits recent memory and reinforces connections that keep recurring. Consolidation can turn a stable pattern into an operating note or a linked memory page. Narrow lessons stay with the project that produced them. Patterns supported across several projects can become shared context.

Yesterday morning, one of those scheduled reviews read the previous day's activity and separated substantive work from duplicate logs and background jobs. It explained why the memory replay process had failed: a list of connections had been passed to a tool as text. The code was already fixed, so the review preserved why it failed and the boundary the next implementation needed to respect.

These ideas are rooted in the way humans dream and process experience. A scheduled review happens after the system has stopped trying to produce an answer. It can revisit what happened, connect events that were separate during execution and notice things an agent misses while it is focused on finishing the task.

That reminds me a little of playing football. We spent just as many hours in the film room as we did on the field, slowing the game down to see what we missed and what we should carry into the next one. This “dreaming” process gives the agents some of the same space to reflect.

Curation has to remain conservative. Models are very good at turning one event into a plausible general rule, and repeated behavior is not necessarily correct behavior. Some review passes should produce nothing. Future agents should receive the correction and enough of the original experience to understand when it applies.

AI/MLEngineering