Shilong Liu published "A Taxonomy of Self-evolving Agents" on July 8, and it lands in a useful spot for TheGitReporter. Earlier today, the site treated Lilian Weng's harness engineering essay as a field note for practical self-improvement: the runtime around the model is becoming an object builders can improve. Liu's taxonomy keeps that frame, then adds a sharper question. Before calling an agent self-evolving, ask which part is allowed to evolve.
That sounds academic until it hits a repo. In the last week, TheGitReporter has covered Codex adding subagent delivery receipts, OpenWork turning team memory into a governed surface, Hermes making approval state thread-local, OpenClaw making audit trails a runtime contract, and OpenCode turning OpenAPI definitions into tool contracts. Those stories were not model-release stories. They were not pure product stories either. They were about the machinery that decides what the model can see, remember, call, delegate, approve, retry, and prove.
Liu's useful move is to stop treating all of that as one foggy "agent learns" bucket. His article separates three places where evolution can happen: the artifact, the harness, and the model. The split gives builders and reporters a better inspection habit. The question is not only whether the system improved. The question is where the loop closed.
The loop is the claim
A self-evolving claim should be boringly concrete. What was the target? What generated a candidate? What judged it? What memory preserved the result? What rule accepted or rejected the change? What was not allowed to change?
Artifact optimization is the easiest to see. A model-driven agent searches for a better output: a kernel, a proof, a robot policy, a paper draft, a UI change, a bug fix, a benchmark solution. The agent may become clever during the run, but the object being improved is outside the agent. The artifact changes.
Harness self-improvement is closer to the beat TheGitReporter has been covering. The model may stay fixed while the surrounding system changes: prompts, memory, tools, skills, routers, workflow graphs, subagent roles, evaluation gates, approval policies, context assembly, and recovery records. This is the layer Weng made vivid and the layer ordinary commits often expose. The harness changes.
Model learning is the harder public evidence problem. If weights update from weak signals, self-play, pseudo-labels, environment feedback, or test-time adaptation, the system may improve in a deeper way. But unless the training data, objective, update rule, evaluation, and failure cases are visible, source-first reporting has less to inspect. The model changes, but the receipts are often further from the public repo.
Those three loops can blur. A coding agent may search for a better artifact, then discover that it needs a better tool. A harness may add a memory rule that produces better artifacts. Better artifacts may become training data. The field will probably move toward systems where artifact, harness, and model improve together. That is exactly why the receipts matter before the vocabulary gets grand.
What our archive already caught
TheGitReporter's recent coverage reads like a set of small field receipts for Liu's middle layer.
Codex giving subagents delivery receipts was a delegation receipt story. It did not prove recursive self-improvement. It proved that parallel agent work was becoming easier to reconstruct after the fact. If future agents improve their own delegation patterns, those send and receive logs are the kind of harness memory the loop will need.
OpenWork's team memory story was a memory-governance receipt. It showed memory moving from vague retained context into schema, search, user scope, deletion, and no-secrets guidance. That matters because a self-evolving harness cannot safely learn from memory if memory is just a bag of assertions. It needs provenance, correction, and forgetting rules.
Hermes making approvals thread-local and OpenClaw adding audit ledgers point at the control boundary. A harness that can improve how it works should not also quietly rewrite who approved a tool call, which session owned the action, or which trace survived the run. Approval and audit are not decorative safeguards; they are the outside frame that lets improvement remain inspectable.
OpenCode's OpenAPI work shows another route. Tool contracts turn external APIs into more reliable agent surfaces. In Liu's taxonomy, a generated tool can become part of harness self-improvement, but only if the system can say where the tool came from, what schema it obeys, what caveat limits it, and how it performed on real tasks.
The older Agent Atlas chapters make the same point in slower form. Before the first model request, the runtime has already assembled instructions, tools, memory, permissions, and task state. When one agent becomes many, delegation becomes a lifecycle and lineage problem. Memory is not one thing, because summaries, retrieved docs, user preferences, thread history, caches, and durable artifacts obey different rules. Liu's taxonomy gives those distinctions a future tense.
Artifacts will be where the public notices first
The public may not care whether the loop improved an artifact, a harness, or a model. It will notice when agents start producing better things: faster code, cheaper kernels, stronger tests, cleaner migrations, safer patches, new hypotheses, new materials, better robot behaviors. Liu's article is right to keep artifact optimization in the frame because that is where the value becomes visible outside agent infrastructure teams.
For builders, artifact loops are attractive because the evaluator can be real. A benchmark runs. A unit test passes. A performance number changes. A kernel gets faster. A robot policy succeeds in simulation and then has to survive the messier world. The danger is that a loop closed on a narrow evaluator learns the evaluator. If the system optimizes for a benchmark, it may become a benchmark machine. If it optimizes for a flaky judge, it may become fluent in judge pleasing. If it optimizes for a brittle test suite, it may become very good at stepping around the real problem.
That is why the artifact loop needs a ledger. Not only the winning artifact, but failed candidates, rejected explanations, changed prompts, held-out tests, measurement noise, human overrides, and the rule that said stop. A timeline full of "agent discovered better X" posts will be exciting. The durable version will look more like engineering: candidate history, evaluation separation, regression records, and a maintainer who can explain why the result was kept.
The harness is where the power compounds
Harness loops are less glamorous and more dangerous. They are less glamorous because the artifact may look the same to the user. The system simply routes better, remembers better, retries better, delegates better, or asks for approval in a better place. They are more dangerous because the harness controls the terms of work. It can change what context is visible, which tool is selected, which subagent gets spawned, what counts as success, and how much evidence survives.
The best version is a disciplined software loop. Mine failures from real runs. Propose a harness edit. Test it on tasks that produced the failure. Test it on tasks it should not affect. Keep held-out cases outside the editing loop. Preserve the rejected edits. Make the diff reviewable. Let a human inspect the acceptance rule. That kind of self-improvement is modest, but it is real.
The worst version is self-justification. The agent rewrites its prompt, chooses its own evaluator, edits away the failure record, grants itself a broader tool surface, and returns with a success story. That is not evolution in a useful public-interest sense. It is an unreviewable system getting better at telling itself yes.
This is where the July 1 Codex usage story still matters. Background work became user work when auto-review, subagents, suggestions, retries, and usage displays blurred what the system was doing on the user's behalf. That was not a self-evolving-agent incident. It was a warning from the same layer. As harnesses become more active, accounting and consent have to become more explicit.
Model learning needs a different standard
The model-learning branch of Liu's taxonomy is the one TheGitReporter should treat most carefully. A public repo can show tool wiring, prompt changes, memory schemas, logs, tests, and API contracts. It usually cannot show what happened inside a closed model update. Even open model work can leave big gaps around data mixture, reward design, weak labels, contamination, forgetting, and evaluation scope.
That does not make model learning less important. It makes the evidence standard different. If the claim is that the model learned without gold answers, the receipts need to name the weak signal, the update path, the comparison point, the negative result, and the forgetting risk. If the claim is test-time adaptation, the receipt needs to show what state changes during inference, how long it persists, and what stops it from overfitting the immediate task. If the claim is continual learning, the receipt needs to show what older ability was protected while the new one was acquired.
Without that evidence, "self-evolving" becomes a vibes label. With it, the label becomes a useful map of accountability.
The next reporting question
Liu ends the taxonomy by asking practical questions: what evolves, what feedback drives it, and where the loop closes. That should become the reporting question for agent infrastructure.
When the loop closes on artifacts, ask for the artifact trail: candidates, evaluator, held-out tests, failed runs, and the acceptance rule. When it closes on the harness, ask for the harness diff: prompt, memory, tool, skill, router, workflow, permission, audit, or delegation change, plus what was kept outside the edit loop. When it closes on model learning, ask for the learning receipt: weak signal, update rule, persistence, regression protection, and evaluation boundary.
The forward-looking version is not that every agent will soon recursively improve itself into a science-fiction system. The grounded version is more interesting. Agent systems are starting to expose the exact places where improvement can become engineering: artifacts that can be measured, harnesses that can be diffed, and models that may learn from weaker signals if the field can prove what changed.
For TheGitReporter, that means the beat gets sharper. Commits are still the alert. Diffs still matter. But the story now asks which loop the diff belongs to. Is the project improving the thing the agent makes, the machinery the agent uses, or the model that drives it? The answer determines the evidence agent teams, maintainers, and operators need next.