LangChain Breaks Down Self-Improving Agents: The Triple Evolution of Models, Harnesses, and Context

In a recent share, the LangChain team put forward a core proposition that runs through their product roadmap: building AI agents that can improve themselves over time. Although fully automated self-improvement is still seen as a distant "north star," this path is profoundly shaping how LangChain thinks about agent architecture, data infrastructure, and evaluation systems.

Three Improvable Dimensions of Agents

Before discussing "self-improvement," LangChain first breaks down what constitutes an agent. They believe an agent consists of three parts: the model, the harness, and the context.

The model is the agent's core reasoning engine, responsible for all decisions; the harness is the system built around the model that determines what the model can see, executes the actions the model decides on, observes and validates results, and persists data—LangChain's deep agent, Claude Code, and Codex all belong to this layer; context is the text, files, knowledge, and tools introduced to the model.

These three layers correspond precisely to three improvement paths: updating model weights, modifying harness code or prompts, and optimizing context content. The driving mechanism for improvement can also be layered—from fully manual work led by AI engineers, to human-in-the-loop approval of proposals from background processes, to the ideal of full automation.

Model Improvement: SFT Is Mature, RL Has a Higher Ceiling

On the model dimension, LangChain observes two mainstream paths. Supervised fine-tuning (SFT) is suited for narrowly defined tasks such as classification, extraction, and summarization; the process is to collect traces, filter high-quality samples, and train the model. According to the share, LangChain recently launched a LangSmith fine-tuning feature (presented as a CLI) that interacts with LangSmith to pull trajectory data, filter and format it, and then hand it off to model providers such as Fireworks or BaseShift that offer hosted SFT APIs.

For the core models that drive agents, more complex tasks are beginning to shift toward reinforcement learning (RL). RL does not simply feed trajectories; instead, it gives the agent a batch of tasks to roll out, scores them in real time, backpropagates updates, and then continues rolling out. LangChain points out that SFT has many hosted options available, while RL currently lacks a truly excellent hosted solution, with significantly higher complexity and cost—but also a higher ceiling. Either way, model updates are almost always initiated by humans, because data preparation and training decisions are currently difficult to fully automate.

The core difference between supervised fine-tuning (SFT) and reinforcement learning (RL) lies in the source of the learning signal. SFT is "imitation learning": given an input and a human-annotated ideal output, the model is trained with cross-entropy loss to replicate that output—essentially teaching the model what the "standard answer" looks like. RL, by contrast, provides only the task and a reward function, letting the model sample multiple trajectories (rollouts) on its own and, based on each trajectory's score (such as whether the task was completed or the answer was correct), using policy-gradient-style algorithms to increase the probability of high-scoring behaviors. SFT's bottleneck is that annotated data cannot cover states the model has never seen, and the model learns the annotator's biases; RL allows the model to surpass the demonstration data through exploration, hence the higher ceiling. But RL requires automatable reward signals, substantial sampling compute, and stable training infrastructure, making its engineering complexity far higher than SFT—which is also why hosted RL services are scarce.

Rollout and backpropagation: In agent RL, a single rollout means letting the model fully execute a task in the environment (possibly involving multiple rounds of tool calls), recording the entire trajectory and its reward; these trajectories are then used to compute policy gradients and backpropagate to update the model parameters, before entering the next round of sampling. Because the model's behavior changes after each update, old trajectories may become invalid, so the "sample—update" loop must be repeated—this is also the key reason RL is so costly.

Harness Improvement: From Code Review to Automated PRs

The harness is essentially code and logic; the way to improve it is to examine traces, identify problems, and modify code, prompts, or tools. Because such changes affect all users, human-in-the-loop review is usually required. LangChain's attempt is LangSmith Engine—a background agent running on traces that clusters issues, proposes fixes, submits PRs, and adds tests and evaluation data points. It is itself nothing more than a deep agent in a sandbox, equipped with CLI connections and specialized sub-agents and skills.

You may not have noticed that the "automation" of this process currently remains at the proposal stage, with the approval step kept in human hands—this is also the pragmatic attitude LangChain repeatedly emphasizes: first get the loop running, then gradually hand over control.

Context Improvement: The Easiest but Most Domain-Knowledge-Dependent

Context is just text, and updating it has the lowest cost, so memory that evolves over time can be maintained at different levels—the core agent, the user, the organization, and so on. LangChain cites two external cases: the data analysis agent Hacks built a unified context layer, with a background review agent analyzing interactions, identifying context gaps, and proposing fixes; the marketing agent Profound continuously synthesizes data into brand-level records and collects personal memories generated from interactions. LangChain's own open-source project Open Wiki follows a similar approach—it analyzes code repositories to generate a knowledge base, reads traces from Codex or Claude Code, locates bottlenecks, and feeds them back into the knowledge base.

LangChain believes the common foundation of all three paths is traces and evals. The hardest part of the improvement loop is often not the technical implementation, but deciding "what to remember, what not to remember, and how to remember it"—which is highly dependent on the specific domain and prompt design.

Traces: A New Kind of Data for the Agent Era

LangChain clearly defines the hierarchy of traces: a single model or tool call is a run, a sequence of runs forms a trace, multiple traces form a thread, and a trajectory is a standardized view of a thread. The key is that whether fine-tuning a model or debugging code with a coding agent, precise inputs, outputs, and event sequences are required.

They view traces as a new kind of data that exposes semantic-level failures invisible to traditional logs—logic errors hidden in the conversation context. This is precisely why LangChain built SmithDB: a database purpose-built for agent observability, whose AI filters allow trajectories to be filtered by semantic questions, with the underlying layer scoring each entry to determine whether it meets the criteria.

SmithDB's AI filters solve the problem of "semantic queries" that traditional databases struggle to answer: for example, "find all trajectories where the agent misunderstood the user's intent." Traditional approaches can only filter by keywords or metadata, whereas AI filters invoke a model to score each trajectory or judge whether it meets the semantic criteria, then return matching results. The cost is that query cost grows linearly with data volume, so it is usually combined with coarse-grained pre-filtering (time, tool type, error code) to narrow the candidate set. This pattern of "using a model to query data produced by models" is a key step in turning unstructured interaction logs into searchable assets.

The difference between trajectory and trace: A trace is the raw event sequence (model calls, tool calls, inputs and outputs), while a trajectory is a standardized and enriched view, typically supplemented with task goals, final results, rewards, or evaluation labels, making it directly consumable for training and evaluation. Transforming raw traces into trajectories is itself a data engineering step that requires domain knowledge.

Evals: The Product Requirements Document of the AI Era

LangChain sums up the role of evals in one sentence: "evals are the new PRD." In AI, there are too many edge cases, and the best way to describe "what is good" is often the evaluation set itself—including what should be responded to and what should not. Building evals has three difficulties: coming up with real inputs (users ask unexpected questions, which is why traces are crucial), defining the criteria for a good answer (exact match, positive and negative criteria, tool-call order, final environment state), and setting up simulated environments to avoid evaluations impacting production systems.

Finding errors is also layered: examining production traces relies on problems having already occurred, while manual testing by domain experts is costly. LangChain's red team testing attempts to proactively discover problems—for example, by sending two semantically similar queries; if the responses differ semantically, one of them must be wrong, thereby anchoring the correct answer. Such methods cannot be performed in real time while the agent is running, but they provide reference points.

Simulation environments are indispensable when evaluating agents, because an agent's actions change external state (writing to databases, sending emails, calling paid APIs). Calling real systems directly during evaluation can both pollute production data and make evaluations non-reproducible. Simulation environments provide sandboxed tool implementations and resettable initial states, allowing the same evaluation case to be run repeatedly and results compared. The challenge is that the simulator must be realistic enough to reflect real failure modes, yet lightweight enough to support high-frequency regression testing. Common practices include recording real tool responses for replay, or writing state-machine-based mocks for critical dependencies.

The Improvement Flywheel and the North Star

Connecting the above steps yields a high-level abstraction: run the agent → obtain feedback (from humans or evaluators) → dig into traces → convert into eval data points → propose changes (model weights, harness code, or context) → verify improvement without regression. The ultimate form of this flywheel is the agent itself discovering errors, creating evaluation points, and proposing and generating fixes—LangChain admits this remains a north star vision full of details, but it is precisely what guides today's engineering investment.

For teams building agents, the practical value of this share lies in providing an actionable checklist: Does your model choice match task complexity? Does the harness have execution environments, context management, and human-in-the-loop capabilities? Is the context layer continuously accumulating rather than being injected once? Do traces and evals form the data foundation of the improvement loop? The answers to these four questions essentially determine whether an agent can move beyond "one-time delivery" toward continuous evolution.

One-line Summary

LangChain proposes a three-dimensional path for agent self-improvement and a trace-and-evals data flywheel.

Paragraph Summary

The LangChain team shared a roadmap for building self-improving AI agents. They break an agent down into three layers—model, harness, and context—corresponding to three improvement paths: SFT suits narrow tasks and has mature hosting options, while RL has a higher ceiling but greater complexity; harness improvement involves a background agent clustering trace issues and submitting PRs, with approval still in human hands; context improvement has the lowest cost but is highly domain-knowledge-dependent. The common foundation of all three paths is traces and evals—traces are defined as a new kind of data composed of runs, threads, and trajectories that can expose semantic-level failures, giving rise to SmithDB; evals are regarded as the product requirements document of the AI era, with difficulties in enumerating real inputs, defining good-answer criteria, and building simulation environments. The ultimate goal is to let agents autonomously complete the full flywheel of discovering errors, creating evaluation points, and proposing fixes.