Ask a large language model a question and it gives you an answer. Ask it the same question next week and you get roughly the same answer — no better, no worse. The model doesn't remember last week, doesn't know your codebase has moved on, and has no mechanism for noticing that the advice it just gave contradicts a decision your team made three commits ago. This is the quiet ceiling most teams hit with AI: agents that are useful on any given day but never actually get better at your work.
There is a way past that plateau, and it doesn't require a bigger model. It requires giving your agents something they normally never get — a night shift. This article describes an approach we run in production: a team of specialist agents that, on a schedule and mostly while nobody is watching, re-read their own instructions, study the code they're responsible for, surface the debt and the opportunities they find, and propose improvements to themselves for a human to approve. Where the idea comes from, how the core loop works, how you keep it from becoming an expensive mess, and why the gains compound.
Agents that don't get better
The default way to use an LLM is stateless and reactive. A prompt goes in, an answer comes out, the context is thrown away. That's fine for a one-off, but it has three structural problems the moment you try to make an agent a durable part of a team.
Context rot. An agent is only as good as the context it's given. Codebases move every day; the instructions rarely do. Within weeks an agent's mental model is quietly out of date — it references a module that was renamed, a convention that was dropped, a service that no longer exists.
Instruction drift. When you do maintain an agent's instructions by hand, they drift the other way: they accumulate rules for situations that no longer occur, contradict each other, and grow a long tail of guidance nobody has re-read in months. Nobody owns the job of noticing.
No compounding. Most damning of all, nothing accumulates. Every session starts from zero. A human teammate who reviewed your payments module last month carries that context into this month; a stateless agent re-derives it, badly, every single time. You get a brilliant intern with total amnesia — and no amount of prompt engineering fixes amnesia.
The fix isn't a smarter model. It's a practice: a repeatable, scheduled routine that turns one-off answers into a body of knowledge that grows.
Give the team a night shift
The core idea is simple to state: let the agents work while you don't — not on your production code, but on their own understanding of it. Every night a scheduler wakes a few agents in turn. Each one re-reads the definition of its own role, samples the part of the codebase it's responsible for, and writes down what it learned: what to watch for, what looks wrong, what it would ask before touching anything. Crucially, it also flags where its own instructions no longer match reality, and drafts a proposed fix. By morning you have a stack of short, concrete notes and a handful of proposed self-improvements waiting for review.
We call this dreaming, and the name isn't just marketing — it points straight at where the idea comes from.
Where the idea comes from
The insight that intelligence improves offline — during downtime, without new input from the world — is old, and it arrives from several directions at once.
From neuroscience. The brain doesn't only learn while awake. During sleep it replays the day's experience, consolidates what mattered into long-term memory, and prunes the rest. Learning is not just acquisition; it is consolidation, and consolidation happens when the system is "offline".
From reinforcement learning. The same principle shows up as experience replay: an agent stores its experiences and learns from them again later, off-line, decoupled from acting. A whole line of "world-model" agents takes this further — they learn a compressed model of their environment and then improve by imagining rollouts inside it, literally learning from dreams rather than from fresh interaction.
From LLM agents. The most useful recent thread is self-reflection: agents that critique their own output, keep a running memory of what worked, and feed those reflections into the next attempt. Related work gives long-lived agents a memory stream they periodically summarize into higher-level reflections, and skill libraries that grow over time, so an agent gets more capable the longer it runs.
From software engineering. None of this survives contact with production without the other half of the lineage — the operational discipline of cron jobs, continuous integration, and the SRE playbook (rotations, timeouts, observability), plus the docs-as-code and infrastructure-as-code habit of keeping the source of truth in version control. The approach here is essentially agents-as-code: the agents themselves are files in your repository, and improving one is a reviewed change like any other.
A name for the missing piece. Andrej Karpathy has put the same intuition in sharp terms. In a 2025 conversation he observed that humans, during sleep, distill the day's context into the weights of the brain — and that today's models have no equivalent distillation phase, which is why he counts continual learning and persistent memory among the missing pieces that make agents collapse under real work. Separately he sketched a paradigm he named system prompt learning: instead of changing weights by gradient descent, a model should learn the way a person keeps notes — in effect writing a book for itself on how to solve problems, and improving it by edits. The approach in this article is a concrete, human-gated realization of exactly that: the agent's instructions are the book, self-study is the note-taking, and an evolution proposal is an edit.
Put the two halves together — "systems improve offline by replaying and consolidating experience" from the science, and "automate it safely, keep everything in version control, keep a human in the loop" from engineering — and you get the practice this article is about.
The self-study loop
Everything rests on one core cycle, run per agent. It is deliberately small and bounded; the goal is a finished note every night, not a perfect map of the repository.
1. Re-read the role. The agent starts by reading its own definition — what it's for and how it should behave. This is the anchor; everything else is measured against it.
2. Sample the code, on a budget. It then looks at the part of the system it owns: the manifest files that reveal the stack, a directory listing, a few files its own instructions mention by name. The budget is strict on purpose — a handful of reads, not an exhaustive crawl. A short, accurate note beats a long investigation that never finishes, and a tight budget keeps each run cheap and fast.
3. Write a learning note. The output is a short markdown note: the agent's role in one sentence, a watchlist of three to five concrete things to check in this repository (not generic advice), and one clarifying question it would ask a human before a non-trivial change. This is the consolidation step — the "what I learned today".
4. Detect drift. While reading, the agent compares its instructions against what it actually finds. A file the instructions reference is gone. A rule describes a flow that no longer exists. A guard-rail is missing. The mismatch itself is the finding — and the agent is explicitly told not to go and fix it, only to record it.
5. Propose an evolution. When the mismatch is structural — not a typo, but a real misalignment worth reviewing — the agent writes a separate evolution proposal: what's wrong, a specific change to its own definition, and the rationale. This is the self-improvement step, and it is the most important design decision in the whole approach: the agent proposes, a human disposes. It is learning by edits, not gradient descent — Karpathy's system prompt learning — with a person holding the pen. The agent never edits its own instructions directly. A person reviews the proposal and applies it in a couple of minutes, or rejects it.
Run this loop nightly across a team and the agents' instructions stop rotting. They track the codebase instead of falling behind it — because the thing best placed to notice that an instruction is stale is the agent reading both the instruction and the code at the same time.
One pattern, many lenses
Once you have a safe way to run a bounded agent on a schedule and collect its output as an artifact, self-study is just the first application. The same machinery points at other questions by swapping the prompt.
Tech-debt discovery. A weekly scan reads the repo the way a senior engineer would on a bad day — grepping for TODO/FIXME/HACK, finding files that churn suspiciously often, skipped tests, thousand-line files, duplicated logic — and files the top handful as concrete, bounded, worth-doing items. Not a linter's ten thousand nits; five things actually worth a day of someone's time.
Product-idea generation. Another lens reads the same code and asks what's missing — features the architecture makes cheap, gaps a user would feel — and files them as reviewable ideas, one click from becoming a ticket in your tracker.
Operational loops. Another documents the recurring processes a team runs — CI/CD, release, on-call, retros — as living descriptions: trigger, steps, failure modes, where to look first when it breaks.
Knowledge-base health. Another keeps the project's own documentation honest, flagging where the written wiki has drifted from the code.
The unifying idea: each lens is a narrow, scheduled, bounded agent whose only job is to notice and record, never to change code. The variety comes from the question, not from new machinery.
Fairness and guardrails
Running agents unattended, on a schedule, spawning real model calls that cost real money — that is exactly the kind of automation that becomes a horror story if you build it naively. The discipline that prevents it is borrowed wholesale from operations.
Rotation. You rarely want to run every agent every night — it's slow and expensive. Instead agents sit in a rotation and the scheduler picks the top few: new agents first, then whichever were studied longest ago, with a priority tier to bump the ones that matter most. Every agent gets its turn, none is starved, and the important ones come around more often. It's the same fairness logic as an on-call rota.
Concurrency limits. A global cap means that even if a dozen agents are due, only one or two run at once. The machine stays responsive and the cost stays predictable.
Timeouts and a watchdog. Every session is bounded in wall-clock time. A watchdog watches the output; if a run goes quiet for too long, it's killed. Self-study is for short review sessions by design — it is not a place to hide long, open-ended tasks.
Reconciliation. Processes die badly sometimes. A reconciler sweeps periodically and closes any session whose process is gone but whose record still says "running", so the books always balance.
None of this is exotic. It is the boring operational layer — schedules, quotas, timeouts, health checks — that turns a pile of scripts into something you can actually leave running.
Directed work: orchestration and quality gates
Self-study and the scanners are autonomous and background: nobody asked for anything in particular, the agents just keep the knowledge base fresh. The mirror image is directed and foreground: you have a specific goal and you want a team to execute it. The same agents can be driven that way too.
Here a supervisor takes a free-form goal — "design and implement feature X in module Y" — and decomposes it into subagents, fanning the work out and gathering it back. For anything non-trivial the run is structured as a cascade: a pipeline of phases with a quality gate between each one.
A typical cascade runs contract → design → implementation → review → QA. Between phases sits a gate that returns one of three verdicts: approve (move on), return to stage (not good enough, iterate), or reject (stop the run). The gates are the whole point. Left to run straight through, a shaky contract poisons the design, which poisons the implementation, and you discover all of it at QA. Gates catch the problem at the boundary where it's cheapest to fix, and they make the run's quality legible: you can see exactly where it stalled and why.
This is the same instinct as staged CI pipelines and design-review checkpoints, applied to a team of agents instead of a team of people.
Artifacts as the interface
There's a thread running through everything above that's easy to miss and worth making explicit: every agent's output is a plain file in your repository. A learning note, an evolution proposal, a debt item, an idea, a loop, a plan — each is markdown with a little structured frontmatter, written into a normal folder, committed to git.
That single choice buys a lot.
Durability and audit. The output outlives the session. Six months later you can read why an agent flagged something, diff how its understanding changed, and trace a line back to the night it was written.
Portability. Markdown-plus-frontmatter is tied to no vendor, model, or dashboard. Swap the model, change the runner, drop the tooling entirely — the artifacts are still just files you own.
The human stays in the loop by default. Because the output is a file and self-modification is a proposal, review is a normal part of the workflow — a diff, a pull request, an approve button — not a special escape hatch. The agents generate; people decide.
Tool-agnostic composition. Anything that reads files can build on top: a dashboard to browse the notes, a one-click "turn this idea into a ticket", a metric over how much debt is open. The artifacts are the stable interface; everything else is optional.
Why it works
Pulling it together, the approach earns its keep for a few connected reasons.
It compounds. A single nightly note is nearly worthless. Three hundred of them, accumulated and consolidated over a year, are a living knowledge base about your system that nobody had to sit down and write. Small, boring increments are exactly the ones that compound — because they actually happen.
It fights drift at the source. The thing best positioned to notice that an instruction has gone stale is an agent reading that instruction and the current code in the same breath. Self-study puts drift-detection where the information is, instead of hoping a human remembers to audit.
It's cheap where it should be. Bounded, short, off-peak runs cost little individually. You spend idle time and small change to keep a large surface warm.
It's governed and observable. Rotation, quotas, timeouts, and an artifact per run mean this isn't a black box of opaque automation. You can see what ran, what it produced, and what it cost — and turn any of it off.
Concerns stay separated. The agents' "brains" live with the code they reason about; the scheduler and orchestrator are a thin control layer on top. Neither owns the other, so you can change either independently — and the same control layer drives one project or fifty.
Trade-offs, and when not to bother
This is not free, and it's the wrong tool for some jobs. Being honest about that is part of the pitch.
It needs review discipline. The human gate is a feature, but it's also a standing obligation. If nobody reviews the proposals, they pile up and the loop's value leaks away. The approach assumes a team that will spend a few minutes a day saying yes or no.
It costs tokens. Modest per run, real in aggregate. Rotation and concurrency limits exist precisely to keep this bounded, but it is a line item, and on a tiny or throwaway project it won't pay for itself.
The output is nondeterministic. Two nights, two slightly different notes. That's fine for discovery and consolidation — the point is to surface things for a human — but it means you shouldn't wire an agent's raw output straight into anything that demands determinism.
It rewards good hygiene. The agents are only as good as the roles you write for them and the folders you let them write to. Garbage-in still applies; the loop makes a well-defined agent better, not a vague one coherent.
If your project is small, short-lived, or fully understood by one person who lives in it every day — skip it. The approach earns out on systems large enough, long-lived enough, and shared across enough people that nobody holds the whole thing in their head. That is exactly where knowledge rots, and exactly where a night shift pays.
How to start small
You don't adopt any of this wholesale. The minimum viable version is almost embarrassingly small, and that's the point.
Start with one agent, one note, one habit. Write a single agent definition for a part of your system you care about. Have it produce one self-study note — by hand, on a timer, however you like. Read the note the next morning. If the watchlist is useful and the drift it flags is real, you have validated the whole idea on a shoestring.
Then add the loop: run it on a schedule. Then add the gate: let it propose changes to its own definition, and get in the habit of approving or rejecting them. Then add a second agent and a second lens — debt, then ideas. Every step is independently useful; none requires the next. By the time you have a full team on a nightly rota with orchestration and gates, each piece will have earned its place.
The shift in mindset is the whole thing: stop treating AI as a vending machine you hit when you need an answer, and start treating it as a team that gets a little better every night — while you sleep.
Frequently asked questions
- What are self-improving AI agent teams?
- A team of specialist AI agents that live beside a codebase and run on a schedule, mostly overnight. Each agent periodically re-reads its own instructions, studies the code it is responsible for, and writes down what it learned — surfacing tech debt, ideas, and proposed fixes to its own instructions for a human to approve. The aim is agents that get better at your specific work over time instead of plateauing.
- What is the self-study loop?
- It is a small nightly cycle run per agent: the agent re-reads its own role, samples the codebase within a strict budget, writes a short learning note with a watchlist and a clarifying question, and detects drift between its instructions and the actual code. Only when the mismatch is structural does it draft a proposed edit to its own definition for a human to review.
- Do the agents rewrite their own instructions automatically?
- No. An agent only proposes a change; a human reviews it and applies or rejects it. This "agent proposes, a human disposes" gate is what makes the approach safe to run unattended — a bad proposal costs nothing, while a good one has already done the hard part of spotting the drift and writing the patch.
- Where does the "dreaming" idea come from?
- From several directions at once: sleep-based memory consolidation in neuroscience, experience replay and "world-model" agents in reinforcement learning, and self-reflection agents that keep a memory of what worked — combined with the operational discipline of scheduling, rotation, and version control. Andrej Karpathy has framed the same intuitions, noting that today's models lack a sleep-like distillation phase, and describing "system prompt learning," where a model improves by editing its own notes rather than by gradient descent.
- When is this approach worth adopting, and when not?
- It pays off on codebases that are large, long-lived, and shared across enough people that nobody holds the whole thing in their head — exactly where knowledge goes stale. Skip it for tiny or throwaway projects: it costs tokens and requires the discipline to actually review the proposals. The recommended way in is to start small — one agent, one nightly note, and one review habit — then grow.