Self-Improving Loops

A company is a set of loops. Something comes in from the world, someone decides what to do about it, the work happens, and what was learned feeds the next pass. That was true before software and it's true now. What's changed is how much of each loop you can hand to an agent, and the honest answer is: exactly as much as you can check.

That's the whole argument. A loop closes where a check exists. Where no check exists, the loop doesn't close no matter how much compute you point at it, and the fastest way to build a company that decays is to close a loop around a scorer that isn't measuring the thing you care about.

The shape we inherited

Org charts were designed for a world where information moved at the speed of a person. Nested layers, consistent spans of control, orders down and reports up. Most of the structure exists to move information between people who can't all hold the system in their heads at once, and to decide who's allowed to act on it.

Agents change the cost of both. Moving information is close to free. Acting on it is close to free. What is not free, and never becomes free, is knowing whether the action was right.

So the reorganization worth doing isn't flattening for its own sake. It's moving the structure off "who reports to whom" and onto "what gets checked, by what, before it counts."

The co-pilot ceiling

The common move is to keep the structure and give everyone a faster tool. Output per person goes up by some percentage. Meetings still happen. Approvals still queue. That's a real gain and it's also a ceiling, because the constraint was never how fast each seat produced. It was how work got specified, checked, and remembered between seats.

An agent that writes more code inside a process that couldn't check the last batch produces more unreviewed work, which is a cost, not a gain. We wrote about that shape in Software refineries: factories that made building nearly free, then found that removing review had quietly removed the only thing telling them what they'd made.

What a loop is made of

Five parts, and only one of them is interesting now.

A sensor layer taking in signal: tickets, telemetry, cancellations, code changes, conversations. A policy layer saying what may be done without asking, what needs permission, what must be recorded. A tool layer of deterministic calls the system can make. A check that scores the result against a stated criterion. A learning step that feeds what happened back to the top.

Sensors, tools, and policies are engineering. They're work, but they're the kind of work that finishes. The check is the part that decides whether the loop is an improvement engine or a machine for producing confident output nobody can vouch for.

A check is real when it scores an observable outcome against a criterion you stated in advance, cheaply enough to run every time, through a channel nobody is gaming. Tests that fail when the behavior is wrong. A reconciliation that has to balance. A canary that catches the regression before customers do. When you have one of those, hand the loop over and let it run.

Where the loop stops

Some work has no check, and it doesn't acquire one when the model improves. We set this out in Sapient class problems: the goal is contested, the alternative outcome never happened, someone gains by misleading you, or the act of deciding changes what you were deciding about. None of those is a tooling gap. More attempts don't help when nothing can score them.

Two failures follow from ignoring this, and both are common.

Closing a loop around a proxy. Response time is checkable, resolution isn't, so the support loop optimizes response time and customers leave anyway. The loop improves. The company doesn't. If your criterion is a proxy, say so out loud and cap how much authority the loop gets on it.

Grinding on the uncheckable. An agent with no way to tell a scorable problem from an unscorable one either loops forever or produces a polished answer to a question nothing could have falsified. Knowing where verification runs out is a capability the system needs about itself, not just a note in your runbook.

Principles

Close loops around checks, not around tasks. Before automating a step, name what will tell you it went wrong. If nothing will, you're not automating, you're delegating without oversight. That's still a choice you can make, but make it knowingly and bound it.

Select, don't commission. Internal software is the clearest case. Most of your dashboards, back-office tools, and operations glue are not novel, and having an agent write each one fresh gives you a pile of artifacts that all need reviewing. Prefer what's already known to work, with the evidence attached, over what was made to order this morning. This is the refinery argument applied inside the building.

Keep the specification, treat the implementation as replaceable. What your systems must do, must never do, and would trade away, is the durable asset. The code satisfying it is not. Write the intent down properly, keep it current, and let the implementation be regenerated or reselected as the catalog and the models move. Drift between what you meant and what runs is the tax you stop paying.

Make the record reachable by meaning, not just stored. Recording everything and searching by keyword gives you an archive. What a loop needs is the ability to notice that a support ticket, a churn event, and a code change from three weeks ago are about the same thing, even though nobody used the same words. That's the point of semantic analysis, and it's the difference between a company that has its history and a company that can act on it.

Let coordination happen by meaning instead of by routing. The coordination work an org chart does is mostly deciding who needs to hear what. When your agents subscribe to what they care about and the relevant messages arrive without anyone wiring the path, that work shrinks. Fewer layers is the consequence, not the goal, and it's worth being careful here: layers also carry accountability, and accountability is exactly the thing you can't automate away.

Spend compute where a check exists. Compute is a budget, not a slogan. Its price settles at what the least valuable job running on it can capture, which means the cheap elastic capacity that made speculative work look free is getting repriced as demand for it grows. Many attempts against a sound check is what compute is for and it's worth paying for. Many attempts against no check is spending without a way to know what you bought.

Where people stay

At the edge of verification, which is a more precise version of "at the edge of the company."

Deciding what's worth building. Setting the criterion that everything downstream optimizes. Judging a call against the path you didn't take. Reading a counterparty who's reading you. Making the decision that changes the room by being made. Owning an outcome you can't prove was right until much later. These stay because no check exists, not because we haven't automated them yet.

The reason to run a company this way isn't headcount. It's that a machine that settles everything checkable makes the questions that reach a person the ones that actually needed a person, arriving with the answerable parts already answered. That's the division of labor the org chart was always reaching for. The difference is that the line is now visible, and it's drawn by what can be verified rather than by who reports to whom.

We build infrastructure for agent systems, so this is the shape we're building for and the way we run. If you're closing loops like this, we'd like to hear where they hold and where they break. Find us at noetive.io.