Self-improvement, with direction.

Hello from Corduroy Labs.

We let the agent get better at its job this week, but on a leash. Every improvement it wants to make to itself arrives in our inbox as a draft. To accept, we reply with a single line. To reject, the same. Anything we ignore expires.

An agent that improves itself silently is exactly the kind of agent we did not want to build. So we did not.

Two pieces of work made that possible. One is defensive: the agent now checks its own claims against the world before it shows them to us. One is generative: the agent now proposes, in plain language, what it thinks it should learn next. Together they answer a question we had been circling: where does direction come from when the agent improves itself?

When the agent gets it wrong

Earlier this week, the daily report told us three things were broken on our public sites. We trusted it and started fixing them. Two of the three were never broken.

The agent had been reading our web access logs and inferring that certain files were missing because nobody had asked for them recently. Absence in a log is not absence in the world. Files can be perfectly served and still rarely requested. The agent was confident, and the agent was wrong.

You cannot prompt your way out of a category of mistake. The fix is to give the agent a way to check itself against the world before it tells us anything.

So we added a small step. Every time the agent claims something is missing, the same process walks down its own list of claims, requests each one from the live site, and looks at what comes back. If the file is actually there, the claim gets dropped quietly. If something is genuinely broken, it stays. This is what we mean when we say verify the terrain, not the map.

We kept the dropped claims visible. The next day's report shows what was filtered and why. Quiet filtering is its own kind of error.

The agent proposes, the operator decides

Once the agent could check its own claims, the next question arrived on its own. If the agent can verify what it tells us, can it also propose what it should learn next?

It can. And now it does.

Once a day, the agent reads a couple of weeks of our shipped work — the daily reports it has written, the change notes from our infrastructure, the dated folders where we commit operational scripts. It looks for patterns: a reusable workflow we kept re-deriving from memory, a check we wrote three times for three different sites. When it finds one, it writes a draft of a small reference document and saves it to our shared vault.

The draft is just a file in a folder until we say so. The agent does not install anything. Ever. The closest it gets is a small section in the next morning's report that lists every pending draft, in plain language, with a short identifier next to each one. To accept, we reply approve and the identifier. To reject, decline. Anything we ignore expires after two weeks.

We chose email because the operator's inbox is already where the agent's work ends up for review. The path the agent uses to reach us should be the same path we use to reach it.

Tomorrow's report will include two pending drafts: a search-engine and crawler-hygiene checklist we have rebuilt from memory across three sites, and the verifier pattern itself. The agent noticed both on its own. We will get to decide whether either is worth keeping.

Every proposal, every approval, every decline goes into an append-only log. The agent's case for itself is preserved even when we say no.

Standing on open shoulders

We did not write any of this week's plumbing from scratch.

The pattern for how an agent should think about its own work — how it breaks a job into small pieces, writes the plan down before touching anything, and stops to check itself between steps — is published, public, and free to read. We adopted four pieces of community work this week and gave the agent permission to use them: writing-plans, executing-plans, and writing-skills from the obra/superpowers project, and skill-creator from the team at Anthropic. The agent reads them the same way it reads any of its other reference documents.

This is the part of the lab we want to be loudest about. The default assumption with new AI infrastructure is that everyone builds their own behind a closed door, and the result is a thousand subtly different agents doing the same job badly. The agents worth working with will be the ones that read each other's homework. We are going to keep adopting in public whenever someone has already done the careful work, and contributing back when we get there first.

The proposal-and-approval loop on top of these four skills is ours. The skills underneath are not, and we would rather say that plainly than pretend otherwise.

Direction comes from the operator

The interesting design choice was not whether the agent should improve itself. It was where direction comes from when it does.

Two failure modes were obvious. An agent that improves itself silently: over time we would lose the ability to disagree, because we would no longer know what it had changed. An agent that asks permission for every small decision: over time we would lose the value of having an agent at all.

The middle path is the one we landed on. The agent does the proposing. The operator does the directing. Proposals are cheap, so the agent can make many of them. Direction is scarce, so we concentrate it where it matters: the moment a new reference document is about to enter the agent's working memory.

An agent with the ability to improve but not the authority to direct is a more useful collaborator than one that does either alone. The boundary is what makes it trustworthy.

Quiet engineering, again

None of this week's work is dramatic. A verifier is a function call. A proposal is a markdown file. An approval is two words in an email.

But the working condition shifts. The agent can be wrong without misleading us. The agent can want more without taking more. The operator stays the source of direction without becoming the bottleneck on every small decision.

It is worth saying what this is not. It is not an agent that writes code or ships features on its own. It does not modify its own runtime or edit its own permissions. It writes drafts of small reference documents and waits to be told whether they are worth keeping. The work is structural, observable, and slow on purpose.

The first three updates in this series were about giving the agent somewhere to work, boundaries it can be trusted inside, and a shared workspace where the operator can sit next to it. This one is about how the agent gets better inside those boundaries — without ever crossing them.

It is, as usual, quiet work. Most of it will never be visible to anyone except us.

That is still the point.

Cheers,
Corduroy Labs
Truckee, California