Agent autonomy is an illusion: you're still acting as its loop

In a forwarded live demo, Anthropic's Cat Wu starts from an empty terminal and builds a Claude Code setup in 10 minutes. Her judgment is blunt: Prompting is basically over. 95% of engineers are already running self-improvement loops; the next step is graphs.

That kind of statement easily turns into a slogan. What's actually useful is m4lka's article, which breaks the agent system into 7 layers: Harness, Loops, Graphs. The opening line is sharp: your agent is not autonomous; you are its loop. It writes, you read; it says done, you check; it breaks something, you explain; then you keep typing.

Most so-called autonomous setups are really one person secretly filling three roles: giving the model a place to work, telling it whether it's right, and deciding what to do next. Those three roles are called harness, loop, and graph. Treating them as a menu gets messy. They're more like a ladder: each step up is needed because the layer below breaks in a predictable place.

Layer 0 is chat. Paste a bug report, the model suggests a fix, you copy it into the editor, run tests, and paste the errors back. The model is a smart function; you are the entire program. One Q&A is fine; repeated labor is a disaster.

Layer 1 is the harness, which gives the agent hands. Shell, files, test runner, git, browser. The cleanest way to tell: remove the model from the architecture diagram, and everything left is the harness. More tools isn't better. Ten narrow, clear tools beat forty overlapping ones. Give the agent the minimum environment it needs to complete the task.

Layer 2 is still the harness, adding memory and walls. Memory goes outside the model: use git commit as a checkpoint, pass artifacts by reference, and don't stuff entire logs back into context. Context is RAM; the harness is the hard drive. The model forgets; files don't. Walls are constraints that still hold even when the model makes a mistake: least privilege, isolated worktree or sandbox, command allowlist, token and time budgets. Asking it not to touch migrations is a wish; its not having that permission is a wall.

Layer 3 is the loop, and the core is the check. A loop has four steps: produce a result, check it, correct it, repeat. Everyone focuses on the repetition, but what really determines quality is the check. Without a check that can fail, repetition just repeats mistakes. The strength of a check is determined by the weakest evidence it accepts. If the loop accepts "the model says it's done," that's self-reporting. When writing a check for a bug fix, look at the first line: a test that passes before the fix proves nothing. The check must be able to go red, and you'd better see it go red once with your own eyes.

Layer 4 is making feedback converge. A verdict only says it's wrong. Feedback should say where it went wrong, in what way, and what you've already tried. The simplest structure is the gap between expected and actual: EXPECTED and SAW turn a red light into direction; FENCE confines the next attempt to one file; DEAD ENDS remembers dead ends so attempt 3 doesn't quietly turn back into attempt 1. The loop also needs an exit. If the same result appears twice in a row, the agent is no longer learning from the loop. Increasing the number of tries won't help; what's missing is information it can't see, or the task itself is asking the wrong question.

Layer 5 is the graph, the shape of the work. Nodes and dependencies. Many arrows are habits, not dependencies. Do an early-start test for each arrow: if B starts before A finishes, what breaks? If the answer is nothing, the arrow is a habit. audit billing can happen before the fix lands; opening a PR cannot. Each worker needs its own room. Four agents crammed into one shared context barely count as a team: it's more like one agent wearing four hats, where the first opinion written down becomes everyone's opinion. For steps where code can produce the same answer—such as merging, sorting, deduplicating, counting—don't hand them to the model.

Layer 6 manages gates and the return path. Results that pass a gate must be frozen, made read-only, and downstream must not be able to reopen them. On failure, rerun only the failed node with feedback, and keep passed results unchanged. Every time you rerun good work, you give it a new chance to break. Put gates where work leaves a node; don't pile them up at the end. Judge risk by undo cost: if it's wrong, how much does it cost to roll back? The model saying "this touches auth" is just a label. Whether auth needs one approval or two should be written into code before the run. You are the most expensive and slowest part, so you should only stand where errors cannot be undone.

Layer 7 is where the system learns. The lesson should land at whichever layer the failure belongs to. Put a lesson in the wrong layer and it becomes a suggestion. "Be careful not to duplicate work" in a prompt is a hope; in a splitter, it is structure. Don't learn by feeding last week's entire logs into next week. Feed one rule. The test is simple: the same kind of failure no longer charges you twice.

Someone in the comments added a sharp point. David Andriani said self-improvement loops also need a scoreboard. If no one defines what "better" means, the agent will become very efficient at wandering around. This is especially true for Layer 7.

m4lka's short version can be remembered as: the harness gives the agent capability, the loop makes it honest, the graph makes it organized, and learning makes it better than yesterday. Layers can't be skipped. Ten agents without checks won't give you ten times the output; they'll only give you ten times the cleanup. The goal is simple too: make the system need you to show up once in the right place; don't expect the agent to be completely independent of you.

Original links: fomoebka's tweet, m4lka's article.