The Agent That Learns Its Own Rules of Thumb

Watch a senior engineer walk into an incident. They don't rederive distributed systems from first principles at 3 a.m. They reach for compressed experience: check the last deploy first. Don't trust a single dashboard. If the queue is backed up, look at the consumer before the producer.

None of that came from one place. Some of it was taught — a mentor, a postmortem, somebody else's hard-won write-up. Some of it was lived — the outage they caused themselves in 2019. And none of it became useful the moment it happened. It became useful after reflection: what actually worked, what failed, and — critically — under which conditions. The result is a rule of thumb. Not a law. A procedure with a scope, a cost, and a set of warning signs, quietly revised every time reality disagrees with it.

That loop — absorb external experience, combine it with your own, reflect it into a reusable procedure, deploy it on the next similar task, revise it as the environment shifts — is how humans get good at recurring work in every domain: packing for a trip, preparing difficult feedback, running an incident. It's also the single most valuable thing today's AI agents systematically throw away.

A skill is a rule of thumb, written down

In Agent Harness Core, a skill is exactly that human artifact, made machine-operable: a versioned piece of procedural memory. Not more prompt text. Not a transcript excerpt. Not a fact. A reusable way to perform a competence role — diagnose, plan, execute, verify, deliver — with explicit activation boundaries, required inputs and tools, expected effects, evidence, cost, and revision identity.

The definition matters because the failure mode is so common. Most "agent learning" schemes today either stuff every lesson into an ever-growing system prompt, or vector-search old transcripts and hope similarity equals relevance. Both confuse having had an experience with having learned from it. A rule of thumb is not the memory of the outage; it's the compressed, conditioned procedure the outage taught you.

Getting this right starts with putting each kind of information where it belongs — because the subtlest corruption in a learning system is one observation silently becoming policy:

Your hotel booking is task data. Your packing checklist is a skill. The difference sounds pedantic until an agent promotes the wrong one — and a one-off observation about a single interaction starts steering every future conversation.

Why your agent forgets everything it learns

Here's the uncomfortable fact about the current generation of agents: the model can't keep what the agent learns. Weights are frozen at training time. Context is rented by the turn and evaporates at session end. An agent can execute a brilliant recovery procedure on Tuesday and have no trace of it on Wednesday — not because it's stupid, but because there is no place for the lesson to live.

So the capability asset has to live outside the model — in durable, versioned, auditable structure the harness owns. That's the same conclusion this project keeps arriving at from different directions, and it completes a picture:

• Continuity memory — the virtual session keeps one task coherent across compaction, rollover, and restarts.
• Reasoning memory — the RLM design gives one turn bounded depth over evidence too large for a prompt.
• Procedural memory — skills carry capability across tasks: what this agent has learned to do well, and under which conditions.

The model stays powerful but interchangeable. The accumulated skill library is the part that's genuinely yours — an individual capability asset that survives every model swap.

That's the strategic point hiding inside the architecture. Frontier models are converging commodities; you will change providers, versions, and routing over the life of a deployment — this harness treats that as one /model command. What cannot be swapped in from a vendor is the procedural memory your agent earned on your tasks, in your environment, against your verifiers. A static agent rents all of its competence. An adaptive one owns a compounding share of it.

The loop: from episode to asset

So how does an episode become an asset without the system lying to itself? The loop keeps distinct facts distinct — because the seductive shortcut, counting how often a skill gets used, measures popularity, not capability:

Three details in that loop carry most of the engineering weight:

• Being selected is not success evidence. A skill being surfaced, read, followed, and causally useful are four different facts. The receipts keep them separate, and a multi-skill task doesn't hand every selected skill equal credit.
• A correction is a diagnosis problem. When the user pushes back, was it bad retrieval, a defective procedure, a composition conflict, an obsolete tool contract — or a one-off fact that should never become a skill at all? Attribution before mutation.
• Zero skills is a correct answer. The retrieval question is never "which skill resembles this message?" but "which competence role, if any, is unresolved?" Often the honest answer is none — and a system that can't abstain will pave every task with plausible-looking irrelevance.

Decision science, not vibes

Everything above could still degenerate into a self-congratulating journal. The discipline that prevents it comes from decision science: treat every learning action — disclose a fragment, update a belief, promote a revision — as a decision under uncertainty with a quantified objective.

# the objective the whole ecosystem maximizes
net skill value =
    expected task-outcome improvement
  − context & retrieval cost
  − latency & tool cost
  − interference & conflict cost
  − evaluation & maintenance cost
  − safety & external-effect risk   # hard constraint — no score offsets it

A fragment is disclosed only while its expected marginal value stays positive — then retrieval stops. This is the opposite of showing the model an ever-growing catalog and hoping attention sorts it out. And the same calculus governs the other side of the loop:

• Contextual beliefs, not a leaderboard. There is no globally best skill. The system keeps separate, uncertainty-aware beliefs per skill revision: applicability (does it fit this role, here?), reliability (does it work when applied?), contribution (did it move the final outcome?), cost, and freshness. Hierarchical Bayesian updating lets sparse contexts borrow cautious priors from related roles — without collapsing into a popularity score. Weak or shared evidence produces a weak update, deliberately.
• Cost-aware evaluation. Reflection is only worth running if evaluation costs less than the regret it prevents. So evidence climbs a ladder — deterministic checks (schemas, effects, tests, invariants) → statistical checks (repetition, calibration, drift) → a bounded cheap model → a stronger specialist → operator review — escalating only when uncertainty or impact justifies the spend. The model that performed the task is not automatically its own judge.
• Frozen metrics, falsifiable claims. Baselines, task slices, and observation windows are fixed before results are inspected. If a new router selects fewer skills but total outcome-plus-cost doesn't improve, it is not better. If a rewritten skill reads cleaner but loses a rare critical capability in replay, it is not an improvement. Activity — proposals filed, files patched, library growth — earns nothing.

Measure capability, not churn. A learning system that grades itself on how much it learns will learn a great deal of nothing.

Rules of thumb expire

Here is where the human analogy earns its keep one more time. Every experienced practitioner has watched a trusted rule of thumb quietly go stale: the vendor changed the API, the team changed the process, the environment moved. The skill of being skilled is knowing when your procedure's evidence no longer describes the world.

So freshness is a first-class belief, not an afterthought. Evidence decays; an environment change — a tool version bump, a provider swap, a policy update — lowers confidence in affected skills and triggers revalidation instead of blind replay. An adaptive library isn't one that grows monotonically. It's one whose confidence tracks reality: procedures get revised, split into variants, quarantined, or retired, each with a receipt saying why.

This is also why consolidation is relationship-first, not similarity-first. Two procedures that look alike may be genuinely equivalent (merge candidates), or one may subsume the other while the cheaper specialist stays valuable, or they may be complementary roles that should compose rather than merge, or variants that preserve a tool, context, or risk distinction that matters. A smaller catalog is not automatically better — the goal is lower total disclosure cost without losing the low-frequency capability that saves you twice a year.

The same loop, outside software

Because skills are procedural rather than domain-bound, the loop applies to any recurring situation an agent helps with:

• Life. Combine public travel guidance with observed packing mistakes, accessibility needs, and timing outcomes into a reusable trip-preparation procedure. The current booking stays task data; only the reusable flow becomes a skill.
• Interpersonal work. Preparing difficult feedback can join communication frameworks with which revisions the user actually accepted — learning a scoped preparation procedure without inferring private psychology or universalizing one interaction.
• Professional operations. An incident-response skill joins vendor docs, prior failure modes, and post-incident review; a tool-version change drops confidence and forces revalidation instead of replaying an obsolete runbook.

In every case the pattern is identical: external knowledge and individual experience combine, but only reusable procedural structure is promoted into the asset.

What organic growth is not

"Self-improving agent" is doing a lot of unearned work in 2026 pitch decks, so let's be precise about the boundary. In this project, organic growth means versioned procedural assets, evidence-aware role and residency changes, and independently evaluated promotion with exact rollback. It does not mean:

• rewriting policy from one successful task;
• equating popularity with quality;
• merging skills because they look similar;
• the task model approving its own permanent change.

Learning is a behavioral deployment, and it ships like one: propose → evaluate independently on held-out cases → shadow-compare → promote to one narrow, reversible, low-risk cohort → observe → widen only with evidence — with a tested downgrade at every boundary. Skill author, evaluator, and promoter don't self-attest the same change. Autonomy is earned one risk class at a time, which is the only way "autonomous" and "auditable" fit in the same sentence.

That ledger is the same discipline as the rest of this project: in a year when anyone can generate a beautiful learning-loop diagram in an afternoon, the diagram is worthless. What's worth something is whether each box points at code, a receipt, or an honest "not yet."

From static tool to compounding asset

Put the pieces together and the product thesis is simple. The industry keeps trying to make agents better by making models bigger — renting more intelligence per turn. Adaptive skill intelligence works the other axis: keep the model interchangeable, and make the agent around it accumulate. Every task leaves receipts. Receipts become attributed evidence. Evidence becomes revised procedure. Procedure compounds into an individual capability asset that no other deployment has — because no other deployment lived your tasks.

An agent that merely executes is a tool: identical on day one and day four hundred. An agent that reflects — under evidence governance, with quantified trade-offs, receipts, and rollback — is something closer to an organism: it metabolizes experience into capability, and it gets measurably better at being yours.

And yes — an essay about agents learning rules of thumb was drafted in pair with an AI that has opinions about rules of thumb. Welcome to 2026.

Agent Harness Core: a self-hosted AI agent runtime in Rust. Six dependencies. No async runtime. 1,200+ tests without a model call. Every step gated, every step receipted. Pre-release, Windows-first, dual-licensed MIT/Apache-2.0.