Building Adaptive AI Agents: DeepLearning.AI's new course
An internal agent should not have to start from scratch in every new chat. DeepLearning.AI's course on adaptive agents lays out a practical method: capture traces, approve reusable skills, structure knowledge, and leave model weights until last.
On Monday, an internal agent answers an expense claim. It discovers that the valid policy is not in the attached PDF but in a version posted to the intranet three months earlier, finds it and gets the answer right. On Tuesday another colleague asks the same question in a new chat. The agent starts again from the wrong PDF, and someone has to correct it again.
That scenario comes almost word for word from Building Adaptive AI Agents, DeepLearning.AI's new course. Its example is a coding agent that repeats the same testing mistake, but the problem is broader: what an agent retains between one conversation and the next, whether it writes Python, handles expenses or drafts a contract.
Without a way to retain and reuse what it learns, the agent pays the same learning cost every day. The cost is just scattered across hundreds of chats instead of appearing on an invoice.
Three levels, not one
The course ranks three ways of improving an agent by cost. The first two work on the context the agent reads before replying, the token space: reusable procedures and a better structure for finding knowledge. The third changes the model's weights, the weight space, and should come later.
Start at the lightest level that solves the problem.
Skills
Rewrite a procedure
Knowledge graph
Add nodes and relationships
Fine-tuning
Train model behaviour
The first two levels can change in minutes: write a file or add a node to a graph. The third needs training and dedicated hardware, and has to be repeated when the underlying policy changes. Starting with model weights to teach a new company rule means choosing the most expensive layer.
From traces to an approved procedure
The first level is called skill induction. Conversations, tool calls, errors and corrections are recorded; a model then condenses them into a short procedure for the next time the same kind of request arrives.
Human review decides whether that procedure becomes behaviour. Once a skill is approved, the agent retrieves it for similar requests until someone changes it. If a bad skill gets through, the mistake is repeated on every use.
Every approved skill should have an owner and a written rationale, including rejected ones. Without that context the system cannot improve a proposal; it can only submit it again.
Finding the right knowledge
The second level is the organisation of the knowledge an agent consults. The course shows it on a codebase, but the pattern is familiar: as a knowledge base grows, finding the document to start from can take more work than writing the answer. Keyword search finds the term it was given and leaves out related documents that do not contain it.
The proposed answer is a graph of relationships between documents: what refers to what, what changes together, what depends on what. In code those links are imports, function calls and changes in the same commit. In a company they are linked policies, procedures that change together and contracts referring to the same supplier.
Retrieval happens in two steps. It first finds the node semantically closest to the question, then traverses the graph with a ranking algorithm similar to PageRank. That avoids treating everything one hop away as equally relevant.
| Keyword search | Knowledge graph | |
|---|---|---|
| Finds related material that is not named | No | Yes |
| Cost of adding a new document | Low | Almost zero |
| Needs near-duplicates removed | — | Yes, or the graph gets noisy |
| Result on tested multi-hop tasks | Misses the right node | Finds it |
In the course benchmarks, the graph cut task time by 11–18%, steps to the first correct change by 7–36%, and tokens by 3–16% on Django and HTTPie repositories. Those percentages do not transfer automatically to a company, but they show why a flat index stops being enough when the relationships are part of the problem.
When to touch model weights
The third level changes model weights. A base model has already absorbed a vast amount of text; for a policy or piece of knowledge that changes often, rewriting its weights is usually more expensive than supplying it as context at the right time.
Fine-tuning makes sense for different jobs: making a refusal reliable, or adapting the format and tone of a response. LoRA, the most common technique, freezes the original weights and trains two small matrices. It changes roughly 1% of the parameters.
Training too many parameters risks catastrophic forgetting: the model loses part of what it knew because its original weights are overwritten. Cost rises with model size. In the course, an adapter for 600 million parameters trains in an hour; the equivalent exercise on a frontier model would take hundreds or thousands of compute hours.
In production, a router can send a technical request to the base model and a tone-sensitive request to the relevant adapter, without asking the user to choose.
Why this applies to any internal agent
The course uses coding agents because public benchmarks and open-source code exist there. The three levels apply elsewhere too. An agent answering HR policy questions, drafting contracts or routing support tickets has traces to learn from and documents that can be organised as a graph.
For an internal agent, the practical starting point is to decide which corrections become reusable procedures, who approves them and where the agent searches for knowledge. Fine-tuning remains a specific choice for behaviour and format, not the normal way to update a rule that will change in three months.