Iteration Fit

Product-market fit used to have two halves: find something people want, then prove you can build it. Agents took the second half away from everyone at the same time. Building is no longer evidence of much, because anyone can build the same thing by Friday. What's left to find is the domain where your loop closes faster than anyone else's. That's the fit worth looking for now, and it isn't a property of the product. It's a property of the loop around it.

Most teams hear that and reach for tooling. Faster tooling is available to your competitors at the same price on the same day, so it can't be where the advantage lives. The advantage lives in the parts of the loop that tooling doesn't touch.

Three terms, one of them free

Iteration speed has three terms. How long it takes to build the next attempt. How long it takes to learn whether the attempt worked. What it costs when the attempt was wrong.

The first term is close to zero for everyone, which means it stopped being a differentiator the moment it dropped in price. Two companies with the same models and the same agents build at the same speed. What separates them is the second and third terms, and neither of those is something you buy.

Feedback latency is set by how quickly the world tells you the truth about what you shipped. Cost of being wrong is set by how much of that truth you can afford to hear. A domain where feedback takes a quarter and a bad release costs a customer is a slow domain no matter how fast you build. A domain where feedback arrives in seconds and a bad attempt costs nothing is a fast one, and the company that owns the channel the feedback arrives on owns the loop.

What makes a loop yours

The structural advantages behave like property. They're things you hold, not things you do.

A private observation channel. You see outcomes that competitors don't, because the signal passes through something you run. A payments company sees which checkouts fail. A support tool sees which answers got a reply and which got a refund. That visibility is an asset a competitor can't buy or copy.

A surface you deploy to without asking. If shipping the next attempt needs a partner's approval, an app store review, or a customer's change window, the loop runs at their speed. If you serve the thing yourself, it runs at yours.

Cheap reversal. A domain where a wrong attempt can be pulled back in a minute lets you try more things than a domain where wrong is permanent. How much a bad attempt can break is a term in the equation, and shrinking it is worth as much as any tooling gain.

Pick the domain where those three are yours and speed follows. Pick for speed directly and you get a fast random walk: many attempts, quick cycles, no accumulation, because nothing in the loop is privileged and everyone in the market is walking the same space at the same rate.

The ceiling is the check

There's a harder limit underneath all of this, and it's the one we keep coming back to. You can only iterate as fast as you can tell whether the last iteration worked. We made the general version of this argument in Self-improving loops: a loop closes where a check exists, and nowhere else.

Where a program or a market scores the output, iteration runs at machine speed. A test suite. A conversion rate. A reconciliation that has to balance. A price that clears. Where the check is a person's judgement or a business metric that lags by a quarter, iteration runs at human speed, and no amount of build capacity changes that. It just produces more unscored attempts per unit time.

So the search for iteration fit is really a search for domains with a fast, cheap, trustworthy check that you have privileged access to. That reframes the founder question. Not "what can we build" but "what can we score, sooner than anyone else, on signal only we see."

It also says where the loop stops. Some work has no check and doesn't acquire one when the model improves. We set out that class in Sapient class problems. In those domains iteration speed isn't a strategy, because attempts can't be ranked. The right move there is to keep a person at the point where the check runs out, and to make sure the loop below that point hands them a settled question rather than a pile of unreviewed output.

There's a compute angle too. An hour of accelerator time settles at what the marginal task can capture, which is the argument in Compute equilibrium. Spending that hour on many attempts against a sound check is the highest-value use there is. Spending it on many attempts against no check is spending with no way to know what you bought. Iteration fit is the domain where the first kind of spend is available to you and not to the field.

Speed times reach

One correction to the thesis before it turns into a slogan. A learning rate is signal per cycle times cycles, and signal per cycle scales with how many outcomes each attempt touches.

An incumbent with distribution can run a slower loop and still out-learn you, because each of their attempts reaches a hundred times more outcomes than yours. Cycles alone don't win. The comparison that matters is your cycle count times your reach against theirs. That argues for a narrow domain where you hold the observation channel outright over a broad one where a larger player sees more per attempt than you'll see in a year.

Infrastructure iterates underneath

Infrastructure is the case where the thesis appears to fail, and it's the case we live in.

Infrastructure customers punish iteration on the contract. An interface that changes every week isn't a fast loop from their side, it's a liability they have to absorb. So infrastructure can't iterate where users can see it. It iterates underneath a surface that stays still.

That's the version of the thesis we run. Semantik's public surface is small on purpose: a handful of endpoints and a query language. That part has to hold. Everything below it is where the loop runs, and the checks there are the kind a program can score. Does a subscription still match what it should. What does a search cost. How long until a published message reaches the agent that subscribed to it. Those are scorable on every build, so the loop underneath closes at machine speed while the contract on top doesn't move.

The same shape applies to the agents built on it. An agent system is a set of loops, and the feedback term in each of them is a routing problem: the signal that says "that didn't work" has to reach whichever agent can act on it. When agents subscribe to what they care about by meaning, that signal arrives without anyone wiring the path, and feedback latency drops for every loop in the system at once. The agent is the one iterating. Our job is the channel.

What to look for

Name the check before the product. If you can't say what will tell you an attempt was wrong, in seconds, without a person, you don't have iteration fit. You have a build plan.

Own the observation, not just the output. Anyone can produce. The asset is seeing what happened next through a channel you run.

Make wrong cheap. Choose domains and deployment shapes where a bad attempt costs a minute, not a customer. Reversibility is a term in the equation.

Freeze the contract, iterate the engine. What users depend on holds still. What they never see is where the cycles go.

Count cycles times reach. A fast loop in a domain where a bigger player sees more per cycle is still the slower loop. Pick the narrow domain you can own over the broad one you can only visit.

Fit, on this reading, is between your loop and a domain's checkability, and you find it by asking where you can learn the truth faster and cheaper than anyone else. We build infrastructure for agent systems, so this is how we choose what to work on and how we run the loop under it. If you've found a domain like this, or you're looking for one, we'd like to hear where the check holds and where it runs out. Find us at noetive.io.