Self-Improving Agents
A DIY agent platform decays. Prompts drift as your stack moves, nobody measures whether accuracy dropped, and token bills only go up. Autoheal is built so the opposite happens: agents get more accurate and cheaper the more you use them.
That happens on two independent loops, each closing on its own.
| Loop | What improves | Cycle | Outcome |
|---|---|---|---|
| Agent spec | The agent's definition: instructions, tools, model routing | Run Private Evals → Update → Test & Rollout | Accuracy rises with usage |
| Agent context | The knowledge agents reason over: profiles, memories, skills | Onboard → Reflect → Dream | Cost falls with usage |
The distinction is worth holding onto: the spec is how the agent works, and the context is what it knows. They improve separately, on different rhythms, and each has its own review gate.
Loop 1: Your agent spec improves
Autoheal measures its agents like production systems rather than assuming a prompt that worked last quarter still works today.
- Run private evals. Every run is scored on two axes: trajectory (how the agent worked, meaning the path it took) and artifact (what it produced, meaning whether the conclusion was right and evidence-backed). Evals run inside your environment and score every run, not a sample.
- Update. When scores drop, Autoheal proposes an update to the agent definition. The regression is what triggers the proposal, so drift surfaces as a concrete change to review rather than a slow decline nobody notices.
- Test & rollout. A proposed update is replayed against past runs from your own environment and run in shadow alongside the live agent before it takes over. You see the before-and-after on real cases, then approve.
Because agent specs are versioned, reviewed, and benchmarked, your platform engineers become AI-skilled by managing agents as code, applying the same review discipline they already use for services.
See Agent Spec for the eval rubrics, golden datasets, shadow runs, and the rollout gate.
Loop 2: Your agent context improves
The second loop makes each run cheaper by reducing how much work it takes to reach the same answer.
- Onboard. Each team gets a curated agent profile covering the services it owns, its tools, and its conventions. Onboarding is additive: each team builds on the context the last one created, so a rollout takes hours rather than restarting from zero.
- Reflect. Every run is reflected on when it finishes. What worked and what failed is distilled into a memory for the next run.
- Dream. Each night Autoheal reviews the day's runs, drafts new skills from diagnostic work that repeated, and rebuilds the context graph. Drafted skills always go to an engineer for approval.
The effect compounds: one engineer's input, or one agent's discovery, becomes institutional knowledge available to every future run. Work that once took a dozen exploratory tool calls becomes a known procedure.
See Agent Context for profiles, the memory lifecycle, and how dreaming drafts skills.
Why two loops, not one
Accuracy and cost pull in opposite directions if you only have one dial. More thorough reasoning is more accurate and more expensive; cheaper runs are usually worse. Separating the loops means each is optimized on its own terms, so the spec loop pushes accuracy up while the context loop pushes cost down, and neither is traded against the other.
You stay in control
Autoheal proposes; your team decides. Both loops end in a human gate:
- Spec updates are benchmarked against past runs and shadow-tested, then need engineer approval before rollout.
- Skills drafted by dreaming are proposed as changes for an engineer to approve before any agent follows them.
Memories carry a lighter gate. A learned memory waits for review by default, but Autoheal auto-accepts the ones it has concrete grounds to trust, including a finding that recurred across enough investigations to clear your support threshold, so the queue holds the judgment calls rather than everything an agent learned.
Nothing is applied to your systems automatically. See Sovereignty & Deployment for the authorization boundaries and approval policies that enforce this.