Skip to content

Self-Evolution Is a Data Problem

Published: at 03:10 AM

Table of contents

Open Table of contents

The loop everyone draws

Self-evolving agents. Every pitch has the same loop: act, observe, learn, update. The agent runs, sees what happened, patches itself.

Most teams build one box: act.

The loop isn’t blocked on intelligence. Models can already critique their own transcripts, rewrite their own prompts, patch their own tools. It’s blocked on observe — there’s nothing to observe. The agent ran, something happened, nobody wrote it down.

The loop everyone draws — act, observe, learn, update; only act gets built, observe is where it breaks

No signal, no evolution

Nothing improves without a signal. Gradient descent has loss. Evolution has selection. RL has reward.

A self-improving agent has operational data — or it has nothing. What ran. What failed. What the human corrected. What it cost. That’s the loss function. Without it the agent isn’t plateaued; it’s blind. Improvement without signal is drift.

So the build order inverts: data first, agent second.

Observability first

Instrument everything. Every prompt, tool call, retry, human override. Structured and queryable — traces, not prose logs.

The bar: any episode replayable from its record alone. Can’t replay it? You didn’t record it.

My Dwarf Fortress agent got this for free — gamelog.txt logs every event since the fortress was founded. Production systems have no gamelog. You build one.

Centralize the fleet

The DevOps half.

Single-tenant delivery: every customer gets their own instance. N customers, N deployments — deploy by hand and it’s N snowflakes. Different versions, different configs, logs dying on local disks in different formats. The data exists. Unusable.

Scattered data is no data.

This is why DevOps matters here — and not for the usual reason. Not to ship faster: to make the fleet emit comparable data. One pipeline, one config source, one telemetry schema, every instance reporting home. A fleet you can’t manage centrally is a fleet you can’t learn from.

The same fleet two ways — hand-deployed snowflakes with logs dying locally, vs one pipeline, one schema, one telemetry store

The pipeline is a data source too. Deploys, config diffs, rollbacks, incidents — same store. The agent failure at 3am correlates with the config change at 2am. Dark pipeline, invisible correlation.

Then the loop closes

With data in place, self-evolution is engineering, not research:

Mine. Cluster failures across the fleet. The eval set writes itself — real traces, not imagined cases.

Propose. Human corrections are labeled examples. Enough of them is a prompt patch.

Replay. Run the patched agent against recorded episodes. No staging theater.

Ship. Watch. Same pipeline as any deploy, judged by the same telemetry. Keep or roll back.

The loop closed — mine, propose, replay, ship, watch, cycling back as new traces

One customer’s failure becomes every customer’s regression test. That’s what centralization buys.

The agent improving itself is just another deploy.

Data first

Everyone asks: which model, which framework, which harness. Later questions.

The first question: when the agent fails, who writes it down?

Each failure is signal. Only if you recorded it.