The Aeon Self-Healing Loop: How an AI Agent Repairs Itself

Every scheduled AI agent eventually meets the same problem. A skill that worked last month starts producing garbage this month, silently. The API it called changed shape. The prompt drifted out of context. The output that used to be crisp is now hedged, generic, and forgettable. Nothing crashes. The Actions log stays green. And the daily brief the agent has been sending for six weeks quietly turned into wallpaper.

The operator finds out when they finally read one carefully and notice it's worse than the one from July. By then the drift is a habit and the trust is spent.

aeon's answer to this is a loop that runs alongside the skills themselves. It scores outputs, files issues when quality drops, patches skills that keep failing, and - when a skill can't be measured because the framework doesn't have a way to check it - writes the missing evaluation itself.

This is the self-healing loop. Five layers. Two of them do the scoring. Two of them do the repair. One glues the whole thing together.

The first layer is the scorer. Every skill output - the actual Markdown the skill produced - gets sent to Claude Haiku with a rubric derived from the skill's stated goal. Haiku returns a score from 1 to 5, plus a one-line rationale explaining why.

The score gets appended to a 30-run rolling history for that skill. That history is the base signal. A skill that scored 4.2 average last week and 3.1 this week hasn't broken - it's degraded. That degradation is the earliest signal a human would ever notice, and the loop notices it before a human would.

Two design choices here matter.

The scorer is Haiku, not Opus. The scoring pass has to be cheap and consistent, not brilliant. Haiku is fast enough to run on every skill output without doubling the run cost, and its scoring stays stable enough across runs to make deltas trustworthy.

The rubric is per-skill, not global. A morning brief scores well on different axes than a security digest. Each skill's rubric lives in its SKILL.md alongside the instructions. The scorer reads both.

The second layer is heartbeat. It runs once a day and reads the last 24 hours of skill runs from GitHub Actions. For each skill, it computes:

• Success rate. Ran or crashed.
• Score trend. Rolling average vs. the last 30 runs.
• Silence. When was the last successful run.

Findings get bucketed. A skill that succeeded but scored 2 or lower gets flagged as a quality regression. A skill that hasn't run when it should have gets flagged as silent. A skill that crashed three times running gets flagged as broken. A skill whose score is trending down over a two-week window gets flagged as drifting.

The output is an issue-tracker file in memory/issues/. Each finding becomes an ISS-{NNN}.md with structured frontmatter - id, title, status, severity, category, detected_by, affected skills, root cause, fix PR. Health skills file issues; repair skills close them. Nothing else touches the issue folder.

The notify rule is the same as every other aeon scanner: silence on a clean day. If nothing regressed, nothing crashed, and nothing went silent, heartbeat writes a log entry and does not ping the operator. Notification is for signal.

The third layer is the interesting one. skill-repair reads the open issues, focuses on skills that have failed three times in a row on the same category of error, and attempts a fix.

The fix pattern varies by category.

• API-change error - the skill was calling an endpoint that now returns a different shape - gets a proposed rewrite of the parsing step, tested against the actual response the skill last received.
• Prompt-bug - the skill's instructions produced worse output over the last 30 runs - gets a targeted rewrite of the section of the SKILL.md that Haiku's rationales identified as the weak spot.
• Missing-secret error - the skill declared a key that isn't set - gets flagged as a config issue, not code-patched.
• Permanent-limitation error - the sandbox can't do what the skill asked - gets marked wontfix with an explanation.

Every proposed fix goes through the normal PR flow. skill-repair opens a branch, edits the file, commits with a message explaining the diagnosis and the change, and pushes. The PR sits in the fork's normal review queue. Auto-merge is not on by default; the operator sees the diff before it lands.

When the fix merges, the corresponding issue in memory/issues/ gets closed and moved to the resolved section of INDEX.md. The failure count on the skill resets. If the fix works, the score trend recovers within a few runs. If it doesn't, heartbeat picks it up again.

Two skills sit above the loop.

skill-evals runs when a skill's rubric doesn't cover a metric the operator actually cares about. Say the morning brief has a "reads well in the first 30 seconds" property that nobody wrote a rubric for. skill-evals synthesizes an eval - a small set of inputs, expected properties, and pass criteria - and runs it against recent outputs. If the skill fails the synthesized eval, heartbeat gets a new signal to pick up.

self-review runs on the whole system. Once a week, it reads the issue index, the resolved-issue log, and the last N days of scoring history, and writes a report on the health of the fork - which skills are drifting, which have plateaued, which have improved after a repair. This report is the audit trail on the loop itself. Did the loop actually help? What patterns are recurring? Are there skills that keep drifting the same way - maybe they need a bigger rewrite than a patch?

The report goes to articles/ like any other long-form output. If you're running aeon on a public fork, it's readable by anyone who wants to see how the fork is doing.

The critical property of the loop is that most of the cycle runs without an operator in the middle. Haiku scores. Heartbeat files. Skill-repair patches. Skill-evals synthesizes. Self-review reports. The operator's touch point is one place: the PR queue.

That's on purpose. The whole aeon thesis is that you configure the agent once and forget about it. Building a self-healing loop that pages you every time it detects a regression would violate that thesis. Building one that fixes what it can, files issues on what it can't, and reports weekly on the whole thing preserves it.

The operator opens their inbox once a week. There's a PR from skill-repair fixing a skill they might not have realized was broken. There's a note from self-review saying which skills improved. There's an INDEX.md they can browse if they want to see what's open. And that's the whole management interface.

• Silent drift. A skill that goes from 4.2 to 3.6 to 3.1 over three weeks is a signal no human would spot. heartbeat spots it on day one of the trend.
• Broken skills nobody noticed. A skill that failed three times running while everything else stayed green would sit in the queue until the operator randomly clicked into that skill's Actions history. skill-repair opens a PR the same day.
• Category regressions. A pattern where every skill of a given kind - say, every content-generation skill - starts dropping in quality at the same time is a signal about the environment (a model update, a prompt template change, a shared prompt fragment that drifted) rather than any one skill. self-review surfaces that pattern in the weekly report.

Most agent frameworks stop at "run the skill, log the output." aeon's bet is that a scheduled agent that isn't scoring itself will drift silently, and drift silently kills trust faster than any single failure does.

Five layers is a lot. In practice, four of them are invisible on any given day. Heartbeat runs, everything's fine, nothing happens. Haiku scores each output, the numbers stay stable, nothing happens. Skill-repair scans the queue, no skill has crossed the three-failure threshold, nothing happens.

Then, one Tuesday, an upstream API changes shape. A skill fails. Fails again. Fails a third time. skill-repair opens a PR. The operator merges it. The skill runs green the next morning.

The trust in the framework survives.

The loop ships with aeon - fork it, enable the health skills, and it starts scoring from the first run.

Set up Aeon. Free, MIT-licensed, and it runs on your own GitHub account.