Learning

Learning carries the benefit of experience into future tasks. The revision loop in Feedback helps an agent correct its current answer, but a new task can repeat the same mistake. The correction may exist only in a conversation that the next model call never sees. For the system to learn from that correction, something it uses on later tasks must change.

A saved procedure is one way to make that change. The next agent can load instructions that explain how to avoid the mistake, without reading the conversation in which someone discovered it. A successful answer can also become an example for similar tasks. Memory gives these lessons somewhere to persist; learning connects the experience to what the system does differently next time.

The Learning Loop

The simplest learning loop turns a useful correction into instructions for later work. In the citation example from Feedback, the agent corrects a claim after a reviewer points out that its source does not support it. The same checking procedure could help with future research answers. Preserving that procedure as a skill gives later agents a way to use the lesson.

The skill needs to explain what to do with the evidence. “Be more accurate” gives the agent little guidance. A file such as skills/source-backed-research/SKILL.md can describe the actual check and include the distinction that the original answer missed:

---
name: source-backed-research
description: Writing factual answers from retrieved sources.
---

For each claim drawn from a source, keep the supporting passage
with its citation. Check that the passage supports what the
claim says, including its dates and qualifications.

A source announcing a release next month does not support a
claim that the product is available now. If support is missing,
look for more evidence or state what remains uncertain.

Saving the file supplies only part of the loop. A later call must receive its contents. In a workflow dedicated to source-based research, the application can load the skill directly, as below. An agent that handles many kinds of work can instead see a catalog of skill names and descriptions, then choose which files to read. Both arrangements connect the saved procedure to a new context.

import { readFile } from "node:fs/promises"

// A tested procedure saved from earlier experience.
const procedure = await readFile(
  "skills/source-backed-research/SKILL.md",
  "utf8",
)

// A new task, without the old conversation.
const answer = await callModel({
  instructions: procedure,
  input: { task, sources },
})

Learning from examples

An example can demonstrate how to handle a case without spelling out every instruction. A corrected answer can become a few-shot example: a sample input and desired output supplied alongside a new task. Keeping the original question and relevant source passages with the answer lets the model see how the answer follows from the evidence. A polished answer alone may teach a writing style while hiding the reasoning that made it correct.

Selecting these examples is a memory problem. A useful match shares the difficulty the agent needs help with, which may differ from the topic of the question. An example that handles conflicting sources can help with another subject where sources disagree. Retrieving several answers about the same product may add facts without demonstrating how to resolve that disagreement.

A lesson also needs a scope. An explicit preference for short weekly updates belongs with that user's weekly updates; a one-time request to shorten an answer does not establish a preference for every future conversation. Keeping the correction and the circumstances behind it helps the system decide where it applies. The record below illustrates one way to keep that scope and evidence with a proposed rule. A skill file can carry the same information in ordinary prose.

Changes to the harness

The harness is the software around the model. It determines what information reaches each call and what happens to the result, so a recurring error may require a change there. In the citation example, instructions to check release status will do little if an earlier extraction step has already removed the dates and qualifications from every source.

An improved extraction step could preserve availability: "announced" | "released" | "unknown" alongside the supporting passage. Later calls would then receive the distinction they previously lacked. The field does not prove that the classification is right; the passage makes it possible to check. The lasting improvement comes from preserving evidence before another answer needs it.

Other parts of the harness can change in response to experience:

• Retrieval: a search that repeatedly misses relevant documents can lead to better indexing or a different ranking method.
• Routing: tasks that need calculations can go through a code-execution step after direct answers prove unreliable.
• Tool implementations: an overwritten document can reveal the need for a save that writes only if the stored version still matches the version the agent read. The check and write happen as one operation.

Model training

All the changes so far can work while the model's weights stay fixed. Ordinary inference uses the parameters the model already has; correcting an answer in a conversation does not itself update those parameters. A later call benefits because the application supplies different information or runs different code.

Training provides another place for experience to go. Fine-tuning updates model parameters using training examples. A collection of successful task inputs and outputs can therefore serve different purposes: the application can retrieve selected examples into context, or a training process can use them to change the model. Context examples are easy to inspect and replace. Training can reduce the need to restate a behavior on every call, but takes a separate update process and does not guarantee that the model learns the intended lesson.

Automated reflection

A developer who reads an agent's failures and improves its skill file is already completing a learning loop for the system. The same work can become an agent task. A reflection job can examine saved attempts and their evaluations, identify a recurring problem, and propose a change to the relevant skill or tool. A heartbeat can schedule this review periodically, using the trigger and context-reconstruction mechanisms from Autonomy.

The reflection call needs evidence of what happened. The final answer and a low score may not reveal whether the agent lacked a source or ignored a source it had. The task, tool results, and evaluator's findings help distinguish those causes. Useful reflection produces a specific proposed change with the observations that support it. A fluent explanation of a failure is still a hypothesis about its cause.

Testing a lesson

A change that fixes one answer can make other answers worse. A rule inferred from a missing citation might demand citations even for a task that only asks the agent to rewrite supplied text. Evaluation checks whether the proposed lesson helps where it should and leaves other useful behavior intact:

• The original failure checks whether the change addresses the problem that prompted it.
• Previously successful tasks check for regressions, including within the same kind of work.
• Held-out tasks test the change on cases that were not used to write or refine it. Once a case guides an edit, it no longer serves as an independent check.

Comparing the old and new procedure on the same tasks makes the effect easier to judge. Keeping the model and other settings fixed helps separate the proposed change from other causes of improvement. Because model outputs vary, a single better answer may not settle the comparison. The reliability measurements from Evaluation apply here too.

Accumulated lessons

Using a tested lesson requires an actual update: the application must load the revised skill or run the changed code. Keeping the previous version makes it possible to undo a change if later results expose a problem the tests missed. A version identifier also lets us connect a result to the procedure that produced it.

As lessons accumulate, the context limit returns. Loading every instruction into every task fills the window with irrelevant advice, and old rules can conflict with new ones. A skill catalog lets the model choose a relevant procedure without reading the whole collection. Updating an existing skill keeps related guidance together; replacing an obsolete instruction prevents two versions from competing in the same context. The system can keep the old evidence in its history without continuing to use the old rule.

Learning systems

Evaluation, feedback, and learning connect at the same piece of work. Evaluation identifies an unsupported claim. Feedback helps the agent correct that answer. Learning uses the discovery to improve the procedure or information available to later tasks. Each connection has to exist in the program; storing a trace or writing a reflection does not create the next connection automatically.

The book began with a model call that receives task information through a finite context window. That constraint keeps returning as we build larger systems. Dividing work among agents gives each one a focused context, but creates a need to share results through messages and artifacts. Continuing work across separate runs requires stored state and a way to reconstruct it. Learning makes those stores and procedures subject to improvement through experience.

These elements give us a way to reason about designs that have yet to become familiar patterns. A new arrangement of agents still has to get the right information to each decision and turn the decisions into useful work. Once those connections are visible, we can explain why a design works, locate what it is missing, and build the structures the task actually needs.