A Self-Improving Company Is a Loop You Can Trust
The self-improving company is the right idea. Without verifiers, ownership, and durable history, the loop drifts instead of improving.
Founder, Task Machine
Most attempts to build an AI-native company still bolt agents onto the old shape of the org. A person requests something, an agent does it, the person checks the result, and next week the same request starts from nothing. The engine is faster, but the vehicle is the one that needed a human in every seat.
A recent Y Combinator talk, How to Build a Self-Improving Company with AI, names the alternative plainly. Stop using agents to make individuals twenty percent faster. Extract the domain knowledge trapped in people's heads, Slack threads, and Notion docs, make it legible, and run the business through recursive loops that keep improving while the team is asleep. That argument is correct. The load-bearing word is "loop." A loop that changes your company overnight is either the most useful thing you ship this year or the fastest way to wake up to damage you cannot trace back to a decision.
The self-improving loop has five layers
The talk breaks a self-improving function into five layers that run with minimal human intervention:
| Layer | What it does | What teams tend to skip |
|---|---|---|
| Sensor | Gathers real signal: tickets, emails, telemetry, cancellations | Recording the signal durably instead of reacting to it once |
| Policy / decision | Decides what runs alone and what needs a human | Writing the boundary down so it is enforceable, not a habit |
| Tool | Calls deterministic APIs, queries data, runs code | Nothing, usually. Everyone gets this one right |
| Quality gate | Applies checks, safety filters, and human review for risky steps | Almost all of it |
| Learning | Reads failures, makes a fix, feeds it back to the top | Making the fix inspectable and owned |
The sensor and tool layers are the parts most builders already have. Data comes in, an agent calls something, output goes out. The two layers that decide whether the loop compounds or corrodes are the quality gate and the learning layer, and those are the two that get hand-waved in almost every demo.
A loop without a gate is faster drift
The talk's centerpiece example is a self-fixing database agent. A monitoring agent watches every failed query, works out what is missing, writes a code fix, opens a merge request, has another agent review it, and deploys overnight. By morning the query that failed yesterday runs. It is a genuinely good illustration of the loop closing on itself.
It is also the example that shows exactly what the gate is for. For that overnight fix to be an improvement rather than a liability, several things have to be true at once, and none of them are automatic:
- The failure has to be recorded as a durable fact, not noticed and forgotten.
- The fix has to be checked against something other than the agent's own confidence that it worked.
- Someone has to own the outcome, so a bad change has a name attached to it.
- The whole run has to leave a trail you can read the next morning without archaeology.
Take those away and "self-improving" becomes indistinguishable from "silently rewriting itself." The loop still runs every night. You just lose the ability to tell an improvement from a regression until a customer finds it for you. Most business work makes this worse, because it has no compiler. A weekly investor update, a support escalation, a competitor summary, an outreach sequence: none of them pass or fail on their own. The learning layer has nothing objective to learn from unless you build the check.
What the learning layer actually needs
The learning layer is where the talk is most exciting and most under-specified. "Analyze failures, make a fix, feed it back" only produces a better company if each of those steps leaves something behind. In practice a learning loop that does not drift needs five records, not one:
| Requirement | Why the loop needs it | What happens without it |
|---|---|---|
| Durable failure record | The learning layer has a concrete input | The loop optimizes vibes, not evidence |
| Explicit verifier | A fix is trusted because it was checked, not asserted | Confident-but-wrong changes ship unnoticed |
| Named owner | A bad outcome is accountable to a person or agent | Nobody can say why the company changed |
| Policy boundary | Some fixes deploy alone, some wait for approval | Every change carries maximum blast radius |
| Readable history | You can improve the loop itself later | The system becomes a black box that edits itself |
This is the difference between a company that self-improves and a company that self-modifies. Both change while you sleep. Only one of them lets you understand the change in the morning and correct the loop when it learns the wrong lesson.
Where the humans actually sit
The talk ends on the right image: humans move to the perimeter of the machine and act as the interface between the AI brain and reality. They step in for the volatile, high-stakes, and human-to-human work that models should not own. That is the correct destination, and it depends entirely on the quality gate existing. Humans can only sit at the perimeter if the loop knows how to reach them at the exact moments that need judgment, and only at those moments.
One failure mode is a human who has to watch every step, which turns delegation back into supervision with extra latency. The other is a human who sees nothing until the damage is done. The workable version routes a small number of real decisions to a person: approve this output, answer this question, review this failed check, decide whether to retry, accept or reject this proposed change. Attention is the scarce resource in a self-improving company. The loop's job is to spend it only where it changes an outcome.
How Task Machine structures the loop
Task Machine is built as this loop with the gate as a first-class part, not an afterthought. Something happens in your workspace, an agent runs on a connected machine to handle it, and what the agent does lands back as durable records that can set the next run in motion. Work produces work, and the records are the point.
Mapped onto the talk's five layers, using only what runs today:
| Layer | In Task Machine |
|---|---|
| Sensor | Triggers: a chat message, a comment that tags an agent, an assignment, a schedule firing, a team lead's heartbeat, a recheck on blocked work, or a workflow node. Connectors give agents external tools through the Model Context Protocol. |
| Policy / decision | Per-agent autonomy levels, workspace roles and permissions, and a review level (Routine, Standard, Elevated, Critical) scored per task from blast radius, novelty, sensitivity, and reversibility. |
| Tool | The tama CLI, through which an agent makes durable changes instead of narrating them, plus connectors for outside services. |
| Quality gate | Verifiers and review gates. A task can carry a reviewer, agent or human, and finish is held until the deliverable is judged against acceptance criteria. Critical work routes to a person. |
| Learning | Agents write to a bounded memory, propose new tasks, workflows, and playbooks rather than applying changes silently, and every turn is held to leaving a trace so a stuck agent is never mistaken for a quiet one. |
Two design choices are where Task Machine diverges from the talk on purpose. First, an agent does not silently rewrite and deploy the company. When it wants to change how work runs, it proposes, and the proposal is a record you accept or reject from your inbox. Second, the moments that need you arrive in one place. Approvals, questions, failed verifications, and proposed changes flow to the inbox, so the human perimeter is a short list of decisions rather than a live stream to babysit. Budgets cap the spend before a run starts, so an overnight loop cannot quietly burn through money while you sleep, which is the other way self-improvement goes wrong.
This is a deliberately less magical picture than an agent that ships code to production unattended. The overnight self-fixing loop is a fine aspiration, and the pieces that make it safe are the boring ones: a recorded failure, an explicit verifier, an owner, a boundary, and a history. Task Machine is opinionated that those come first.
If you are building a company that should improve while you sleep, and you want the loop to be one you can inspect the next morning, join the private beta on the waitlist.