The System That Proposes Its Own Next Hire
A company's machinery should not just run and remember. It should notice its own gaps and propose the fix, for a human to approve.
Founder, Task Machine
A company's operating setup is built once and then slowly falls out of step with reality. New kinds of requests arrive. New failure modes appear. A process that fit the work last quarter fits it a little less now. In most companies someone eventually notices and redesigns the process, usually late, usually after the mismatch has already cost something. The redesign is a separate, occasional, effortful act, disconnected from the daily running, because noticing what needs to change is itself work that nobody quite owns.
Agents make the running of the work cheap and constant. The interesting question is whether they can make the improvement of the work cheap and constant too. Not a system that only executes, and not one that merely remembers what it has done, but one that notices where it falls short and proposes how to close the gap.
A system has to keep up with its world
There is a law that explains why this is not optional. In 1956 the cyberneticist W. Ross Ashby stated what he called the law of requisite variety: only variety can absorb variety. For one system to control another, it needs at least as many distinct responses as the other has distinct disturbances. A regulator with fewer moves than the world it faces will eventually meet a situation it has no answer for, and lose control at exactly that point.
A company is a regulator, and its environment throws an ever-widening range of situations at it. A fixed set of agents, routines, and rules has fixed variety. The world's variety does not hold still. So a company whose machinery cannot grow its own range of responses is not stable. It is slowly being out-varied, and the only question is when a situation it was never designed for arrives. Staying viable means continuously generating new capability to match new demands.
Improvement built into operation
The second half of the answer comes from the factory floor. Toyota's production system is famous for the andon cord that stops the line on a defect. The part that matters more is what the stop feeds. A stoppage is not just a fix. It triggers a small investigation that changes the system so the defect cannot recur, and the change becomes the new standard. Improvement is not a quarterly project handed to a separate team. It is built into operation, surfaced continuously by the people closest to the work, and folded back into how the work is done. That is the whole idea of kaizen: the operation improves itself, a little, all the time.
Put the two together. Ashby says the machinery must keep growing its variety. Kaizen says the sustainable way to do that is to let the operation itself surface the improvements, continuously, and standardize the ones that hold. In an agent-native company, the frontline that notices the gap is the running machinery itself.
The signals are already there
The running of the work already produces the signals. They are usually thrown away.
Every exception the system cannot resolve is evidence of a situation it was not designed for. Every failure caught more than once is a check that is missing. Every time a human answers the same question the same way, a decision is being made by hand that should be a rule. Every time agents reach for a capability the company does not have, the roster is a person short. None of this requires new instrumentation. It is a byproduct of doing the work, and in most systems it evaporates into logs and chat threads, exactly like the prompts that never became playbooks.
The move is to treat those signals as a to-do list for the design of the company, and to turn them into concrete proposals.
| Signal in the running work | What it reveals | The proposal |
|---|---|---|
| A recurring exception nothing resolves | A missing capability or rule | Add the rule, or a new agent for it |
| The same failure caught repeatedly | A missing check | Create a verifier for it |
| A human answering identically, again and again | A decision that should be policy | Turn the answer into a standing rule |
| Agents reaching for a capability they lack | The roster is under-varied | Propose a new agent |
| One routine straining across two cases | An overloaded workflow | Split it in two |
Proposals, not autonomy
The word doing the work here is propose. A system that quietly rewired itself whenever it sensed a gap would be generating variety that no one governs, which is the opposite of control, not the fulfillment of it. The proposal is the point where a human stays in charge of the growth. The machinery drafts the change, with the evidence that prompted it, and a person approves it, edits it, or turns it down. Approved changes fold back into the standard so the same gap does not return next week. Rejected ones are themselves a signal about where the standard actually sits.
This is also the sharp line between a system that improves and one that merely remembers. An agent that accumulates memories and skills gets better at what it already does. It improves the performer. Proposals improve the machinery: the routines, the checks, the routing, the roster. A company that only remembers becomes a better-practiced version of the company it already was. A company that proposes becomes a better-designed one.
What it does not solve
A proposing system can propose badly. Left undisciplined it will generate too many low-value changes, and proposal spam is just attention debt wearing a helpful face. So proposals need the same evidence bar as everything else: a gap seen enough times to be real, not once, and a human approval that is genuine judgment rather than a reflex. The value is in the ones you decline as much as the ones you accept.
There is also a ceiling. The machinery can only propose what its own operation reveals, which is the local, operational layer: a missing check, an overloaded routine, a capability the work keeps needing. It cannot propose a change of strategy, a shift in values, or a decision to stop doing the thing entirely. Those come from people looking at the company from outside its runs. The system proposes how to do the work better. It does not decide what the work should be.
Better designed, not just better remembered
Task Machine is built to turn the signals its operation produces into proposals you approve. When work keeps needing a capability the company lacks, it can propose a new agent. When an agent's instructions should change, it drafts the change and routes it to you. When the evidence supports more independence, it proposes a step up in autonomy. You approve the redesign, and the company becomes better designed on the evidence of its own runs, rather than only better remembered.
That is the quiet turn underneath everything else in this series. A company built this way does not just run without you in the loop for every task. It gets better at running, continuously, while you stay the one who decides what better means. It is how the leverage compounds instead of plateauing. Continue with The Age of Organizational Leverage.