Skip to main content

Self-Improving Agent Context

Agent context is what your agents know: the profile curated for each team, the memories mined from past runs, and the skills drafted from repeated work. It's the what of an agent, as distinct from the spec that defines how it works.

This is the loop that makes runs cheaper. An agent with no context has to rediscover your environment on every run, spending a dozen exploratory tool calls to learn what a previous run already established. Context converts that discovery into knowledge, so the next run reaches the same answer with far less work.

The loop is Onboard → Reflect → Dream.

1. Onboard: profiles curated for every team​

Each team gets an agent profile: the services it owns, the tools it uses, its conventions, and the context its agents should load before reasoning.

Onboarding is additive. Each team builds on the context the previous one created, so shared infrastructure, common integrations, and org-wide conventions carry over, and the second team is faster to onboard than the first while the tenth is faster still. One team onboards in hours and a whole org in days, rather than every team being a fresh project.

You can author profile context directly. See the Engineering Context Graph for what to write and Skills for how.

2. Reflect: memories mined from each run​

Every agent run is reflected on when it finishes. What worked and what failed is distilled into a memory for the next run.

Memories are reusable learnings drawn from past incidents. Once captured, they're recalled automatically when a relevant incident recurs, so a problem your team has seen before is resolved quickly rather than re-investigated from scratch. This directly lowers mean time to resolve (MTTR).

What reflection learns from​

Memories are learned automatically; you don't write them. Autoheal derives them from real signals in your runs:

  • Accepted root causes. A confirmed diagnosis becomes reusable knowledge for similar incidents.
  • Your guidance during investigations. Direction you give mid-investigation is carried forward.
  • Hard-won discoveries. A non-obvious cause that took significant effort to find is worth keeping so the next occurrence is quick.

A learned memory lands in a review queue by default, and Autoheal auto-accepts the ones it has strong grounds to trust, so in practice you review the judgment calls rather than every memory. To write reusable procedures yourself, use skills in the Engineering Context Graph.

Memory lifecycle​

Each memory holds one of five statuses.

StatusMeaning
PendingThe memory has been learned and is waiting for review. It is not recalled during investigations yet.
AppliedThe memory is live, and it is recalled automatically in relevant future investigations allowed by its ownership scope. A memory reaches this state either because you approved it or because it was auto-accepted.
DismissedYou declined the memory, optionally with a reason, and it won't be used.
Consolidated into skillYou folded an applied memory into a skill. It stays retrievable alongside applied memories, so nothing is lost by consolidating.
SupersededA newer memory replaced this one during deduplication, and the earlier version is archived automatically.

The Memories page shows a count of pending memories in the sidebar, and that queue is the only part that needs your attention.

When a memory skips review​

Autoheal auto-applies a pending memory when it has a concrete reason to trust it, which keeps the queue to the genuine judgment calls. A memory is auto-accepted when any of these holds:

ReasonCondition
Supported by multiple investigationsThe same finding recurred across enough near-duplicate investigations to clear your configured support threshold. This is empirical evidence, so it outranks every other signal.
Human user guidanceThe memory came from direction a person gave during an investigation.
Source hypothesis user acceptedThe memory came from a hypothesis someone explicitly accepted.
Debugging heuristicThe memory is a general debugging technique rather than a fact about one incident.
Integration relatedThe memory concerns a connected integration.

Each reason is separately configurable, so you can tighten or disable any of them, and the support threshold is a number you set.

Two behaviors are worth knowing. A memory the model judges obvious, incident-specific, or textbook is held for review rather than auto-applied under the weaker reasons above, though multi-investigation support still overrides that hold because it is empirical. Separately, an explicit "remember this" request from a person is exempt from those quality gates, so a memory you ask for is never dropped or held back on an obviousness judgment.

Memory ownership​

Each memory is owned either by one agent profile or by the whole tenant:

  • Profile-owned memories are available only to investigations using that exact profile.
  • Tenant-wide memories are available to every profile in the tenant.

When profile-scoped memory reads are enabled, the Memories page shows the owner on each memory. You can filter by an exact profile or by Tenant-wide, and move an active memory between those scopes. Moving a memory changes where it is available; it does not change its content or lifecycle state.

3. Dream: nightly skills and graph rebuild​

Where reflection works on a single run, dreaming works across all of them.

Each night Autoheal reviews the day's agent runs, finds diagnostic work that repeated across them, and drafts new skills, which are documented procedures the agents can follow directly next time. It also rebuilds the context graph, folding the day's new memories, skills, and discovered relationships into the structure future runs load from.

This is what makes runs cheaper as usage grows. A sequence of exploratory steps that three separate runs each worked out independently becomes one known procedure, and the fourth run follows it.

Unlike memories, drafted skills do need your approval. A skill is an authored procedure your agents will follow directly, so a proposed skill arrives as a change for an engineer to review and accept before any agent uses it.

How one engineer's input compounds​

The loop's real payoff is that knowledge stops being per-person and per-incident. One engineer's correction mid-investigation, or one agent's hard-won discovery, becomes a memory that night, possibly an approved skill by the next morning, and part of the context graph every future run reads.

Institutional knowledge accumulates in the system instead of being lost to turnover and context-switching, and each accumulation reduces the work the next run has to do. See Agent lifecycle management for how this combines with cost-optimized model routing.