01The shape we started from
Before v0.8.0, KAOS already had three persistence surfaces agents could write into: the skill library, cross-agent memory, and the shared log. Each one was well-designed on its own — FTS5 search, BM25 ranking, append-only durability. Each one worked.
But if you stepped back and asked what does the whole library know that none of its individual pieces know, the answer was: nothing. The library was a set of tables you wrote into. It had zero opinions about which of its own contents were good, which were noise, which were always used together. Nothing ranked skills by whether they actually worked. Nothing noticed that two skills were always applied in the same session. Nothing caught that the same error kept coming back across agents.
A brain isn't like that. A brain is a graph that rewires itself every time a neuron fires. What fires together wires together. What goes unused atrophies. What recurs gets reinforced. Crucially, that rewiring happens continuously, as a side effect of normal operation — no one runs a scheduled batch job to do it.
We wanted that layer.
02First question: does weighted ranking even help?
The naive move was to just use the counters we already had. Every skill already tracked use_count and success_count — we just never read them at query time. So: what if skills.search() ranked results by success rate multiplied by recency decay, not pure BM25?
Before writing any code: would that actually help? Not theoretically. Empirically. On a benchmark.
I built one: 10 retrieval queries, 20 skills arranged in twin pairs that share vocabulary so BM25 alone can't reliably disambiguate. Each query has one ground-truth correct skill and a plausible distractor. Then 80 training episodes with epsilon-greedy pick (ε=0.25, seed=42) — same seed for both runs. Zero planted outcomes. No pre-engineered winners. The only difference between runs is whether the rank mode is feedback-sensitive.
BM25 plateaus at 80%. Weighted reaches 90%. That's a real delta — not cherry-picked, not synthetic, reproducible by running uv run python demo_neuroplasticity_bench/run.py.
03But weighted search alone is too shallow
A +10pp win on a retrieval benchmark is nice. It's also just the tip. The bigger question: what if the library understood relationships, not just individual entries?
This is where Hebbian learning comes in. In biology: neurons that fire together wire together. In KAOS: skills that get used together in the same agent session should form an edge in a graph; memories that get retrieved together should link; and cross-modal — a skill the agent used should connect to every memory it retrieved.
Once you have that graph, skill_search("fraud") doesn't just return skills that mention fraud — it also surfaces feast-cold-start-fix because historical sessions that used fraud-detection skills also retrieved that memory entry. The graph emerges from usage. Nobody curates it by hand.
Same for failures. A fingerprint isn't just a stack-trace lookup — it carries a category (transient / config / code / infra / unknown), a root cause, and a suggested action. And critically: we track whether the suggested fix actually worked. A "known fix" that keeps failing after 5 attempts auto-downgrades so future agents stop applying broken suggestions. Plasticity applied to the fix itself.
Add one more layer: systemic alerts. If five agents in two minutes all hit "Connection refused: localhost:8000", the answer isn't "retry with backoff". The answer is your vLLM endpoint is down; stop spawning more agents. A sliding-window counter detects the pattern and raises an alert. Agents should check for active alerts before spawning — the whole point of failure intelligence is to prevent cascading thrash.
04How it costs nothing — the story of an embarrassing first try
Clever designs mean nothing if they're too slow. So I built a third benchmark: a microbenchmark that times every inline hook with plasticity ON and OFF, reports the delta.
The first implementation (v0.8.0) built the Hebbian graph synchronously. Every record_outcome triggered a query for every other skill the agent had used, then upserted an association edge for each pair. On a 100-skill library, that's N writes per outcome plus an extra COMMIT. On Windows where fsync is ~30 ms, that added up.
The fix was architectural, not an optimisation. Inline hooks stopped building the Hebbian graph. The raw telemetry (skill_uses, memory_hits) still writes in the caller's existing transaction — zero extra fsync. Graph construction moved to a single executemany that fires at agent completion.
This is actually how biological sleep consolidation works. Synaptic weights update continuously as neurons fire, but the structural rewiring — dendritic pruning, synaptic consolidation — happens offline, at scale, in bursts. The inline path is cheap; the structural path is batched and runs at natural checkpoints.
agent_complete is the batched graph rebuild — a single executemany with every association edge for the session. One extra fsync at completion is invisible next to the LLM call that preceded it.05Failures aren't patterns — they're diagnoses
The old failure feature was a grep index: "we've seen this stack trace before, here's the same stack trace from last time". Useful. Shallow.
v0.8.1 turns fingerprints into a triage system. Eight built-in heuristic diagnosers — pure Python, no LLM calls — cover the high-volume cases:
demo_failure_intelligence_bench/, each diagnosed by heuristic alone.Each category maps to a different action. A rate limit wants backoff. A 401 wants human action. A KeyError wants a code fix. A local ConnectionRefused wants the service started. KAOS can't fix any of them itself — but it can tell you which bucket you're in without you reading the stack trace, and if many agents hit the same thing at once, it can stop the cascade.
06It all ties together
The story I was telling in the first five chapters sounds like a bag of features — weighted search, Hebbian graph, failure diagnosis, systemic alerts. It's not a bag. It's a loop. Here's where the new layer sits in the stack:
skill_uses row. Every memory retrieval writes a memory_hits row. Every agent completion upserts an episode_signals row and rebuilds the association graph for that session. Every failure triggers diagnosis and checks for systemic patterns. Every 100 completions triggers consolidation that promotes hot memory to skills and prunes cold skills.
The feedback loop is closed. What flows out of the library as a search result came from what agents did before. What flows in as telemetry immediately starts reshaping future search results. There's no manual curation step. There's no "once a week, run the audit". It happens continuously, as a side effect of normal use.
That's the difference between a filing cabinet and a brain. The cabinet is passive — you put things in, you retrieve them, the cabinet has no opinion. The brain is a graph that changes its own structure in response to every signal that passes through it. KAOS v0.8.1 is the first version where the library is the second thing, not the first.
07The reality, measured
All three numbers live next to their source benchmarks in the repo. Reproducible. Auditable.
demo_neuroplasticity_bench/— retrieval accuracy gain (seed=42, deterministic)demo_failure_intelligence_bench/— 60/60 triage + systemic + fix-outcome validationsdemo_plasticity_overhead_bench/— per-op latency with auto ON/OFFdemo_arc_agi3_test/— 76/76 validations in an ARC-AGI-3-shaped workloaddemo_dream_test/— 45/45 dream-cycle use case
What I would not claim
- +10pp is a universal number. It's the specific gain on a specific benchmark designed to have disambiguation signal. A workload where BM25 already hits 100%, or where agents never report outcomes, shows less or nothing.
- The "policies" feature is scaffolding. The table fills up from repeated shared-log approvals, but nothing reads from it yet. That's M4. Today it's data, not a feature.
- Merge detection is crude. Jaccard on word-bags at a 0.65 threshold catches obvious duplicates, misses semantic ones. Never auto-applied. Always a proposal.
- Heuristic diagnosers cover the common cases. Exotic errors stay "unknown" until you register a custom diagnoser or add an LLM-backed one.
- Zero gain without feedback. If your agents never call
record_outcome, the whole mechanism has no signal to learn from. It's not a passive benefit.
What's next
M4 is the active feedback loop: the router picks models by per-task-class success history; the intake step (kaos run --ask) prunes questions against the cluster context the graph has learned; the wave coordinator reads the association graph to bundle skills per wave; the meta-harness proposer seeds its prompts with dream-identified strong tool sequences. Each one uses the library's opinions to change how agents are spawned, not just what they retrieve. Separate decision. Ship M4 when there's clear demand.
Until then: git pull origin main && uv sync && uv run python demo_neuroplasticity_bench/run.py. See the 80→90% in your own terminal.
/papers/kaos-neuroplasticity-whitepaper.html.
+10pp retrieval · +15 µs hot-path overhead · 45/45 dream use case · 60/60 failure intelligence · 76/76 ARC-AGI-3 · 423 unit tests. All reproducible. Run them yourself.