“Agent-first” usually gets used to mean a company where software does the work. That is the least interesting part of it. What agents can do is a capability question, and capability is improving on its own schedule without our help. The design question, the one that decides whether such a business holds together, is narrower: what does a person still have to look at, and how often?
The useful observation is that the constraint does not disappear when production becomes cheap. It relocates. A business arranged around where it relocates to is agent-first. A business arranged only around the cheap production ends up with an expensive queue.
The bottleneck moves
Suppose agents produce work at some rate, a fraction of it needs a person to look before it goes out, and looking takes a while. The capacity of the whole operation is then bounded by:
Human hours over review load. Agent throughput does not appear.
Where \(H\) is the hours a person has, \(f\) is the share of output needing their eyes, and \(t\) is how long each look takes. The rate at which agents generate work is absent from the right-hand side, which is the entire point. Once production has stopped being the constraint, making it cheaper again buys nothing at all. Three levers remain: hours, share and duration. Hours are the one that does not scale.
This is why “we can generate a thousand of these a day” is rarely the good news it sounds like. If each of the thousand needs four minutes of judgment, the operation ships about a hundred and twenty and the other eight hundred and eighty accumulate. That is not a transitional state on the way to something better. It is the steady state.
Approve classes, not instances
The first real lever is \(f\), and the way to move it is not to review faster. It is to change what the unit of approval is.
If every output is approved individually then \(f = 1\) by construction, and nothing done to \(t\) will save you. If instead a person approves a kind of output once, and agents produce instances inside it, then \(f\) collapses toward the rate at which new kinds appear rather than the rate at which instances do. A template, a policy, a set of bounds: approval becomes a fixed cost paid per class instead of a variable cost paid per unit.
This is the same move as deciding a product is finished, an open-ended obligation converted into a bounded one. It fails the same way too, quietly, when new kinds keep getting introduced because nobody wants to be the one who says no to a reasonable request.
Checks beat instructions
The second lever is \(t\), and the reframing that helps is this: most review time is not spent judging. It is spent verifying. Confirming a claim is true, a number matches, a link resolves, a name is spelled the way the customer spells it. Verification is the part a person is worst at and least needed for.
An instruction not to invent facts reduces invented facts. A check that rejects any output containing a fact absent from the source eliminates them. The first is a prompt; the second is a program, and only the second lets you stop reading. Anything expressible as a check should be one, because each check removes a whole category of thing a person has to hold in their head while looking. What is left over is judgment: taste, tone, whether this should exist at all. That is the part worth spending scarce hours on.
Cheap mistakes, not correct ones
The third lever is the one reached for last: lower the stakes rather than raise the accuracy.
Review exists in proportion to what a mistake costs. An action that can be undone in a click, that reaches one customer rather than ten thousand, that is staged before it is live, and that leaves a record of what happened and when, does not need the same gate as one that cannot be taken back. Reversibility is a design property, and it is usually cheaper to build than the accuracy that would justify skipping the gate without it.
The corollary deserves saying plainly. The genuinely irreversible actions stay gated permanently, however good the agents become: money leaving, contracts signed, messages sent to strangers, data deleted. Not because the agent will fail, but because the cost of the one time it does is unrecoverable, and the arithmetic on rare catastrophic events gets worse with volume, not better.
What does not get cheaper
None of this touches the parts of a business that were expensive before agents and remain so afterwards. Distribution is still rationed: inboxes, app stores and search results have gatekeepers who noticed that production got cheap and tightened accordingly. Trust is still earned slowly and lost quickly. Permission, meaning the legal right to contact someone, hold their data, or operate in their market, is still granted by institutions that do not care how the work was produced.
And liability still attaches to a person. An agent-first business is not an unowned one; something has to be a real entity, in a real jurisdiction, that can be invoiced and sued. That is clarifying rather than limiting. It keeps the question honest. Not what can be automated, but what one is willing to put a name to at volume.
How we build them at Flits
Flits is a software lab that keeps what it builds. The products and ventures in the portfolio were developed here rather than assembled from outside, which makes the arithmetic above operational rather than theoretical. Every product added is one more thing that has to keep running without much standing behind it, and how many can exist at once is precisely the question above.
So the pattern is applied fairly literally. What gets approved are classes rather than instances: a template, a tone of voice, the claims a product is permitted to make, the range a price is allowed to move within. Agents produce the instances inside those bounds, and take most of the work that keeps a product alive after it ships. Where an output can be checked by a program it is, and the check is the gate rather than someone reading the result. What reaches a person is the residue that needs taste, or that costs too much to get wrong.
Everything irreversible stays with the principal. Money leaving, anything signed, anything said to a stranger under the Flits name, anything touching a customer's data. Those are not bottlenecks to be engineered away. They are most of the reason there is a company here rather than a script.
What we are building now is run this way from the first day rather than automated afterwards, which in practice means deciding what the classes are before there is any volume to review. That is slower at the start, and it is the only version that holds up later. New ventures get announced when they are ready.
The shape of it
An agent-first business is not fewer people doing more. It is a business deliberately arranged so that its human capacity goes to classes rather than instances, to judgment rather than verification, and to the small set of actions that genuinely cannot be undone. Everything else is either checked by a program or cheap enough to get wrong.
Arranged the other way, with agents everywhere and a person reviewing every result, you have not automated a business. You have automated your way into a queue, and hired yourself to work it.