A firm that deploys agents across many customers ends up holding an asset that none of those agents, taken individually, contains: a record of every way the work breaks. Each deployment teaches the shared infrastructure a new class of exception, a new document variant, a new write-back rule for some downstream system. Because the same infrastructure serves the next customer, that record carries forward, and the thing that compounds across deployments is not the code.
What actually accumulates across deployments
Start with what a single engagement produces. Flowscope observes how a business runs, redesigns the process, and ships an agent into production on the systems the business already uses. To do that, the agent has to handle the work as it actually arrives, which means handling the cases the documented process never mentions: the invoice from the one vendor who sends a scanned image instead of a PDF, the order that needs manual approval above a threshold, the field that has to be written back to an ERP in a format the ERP will accept. Each of these is a unit of context, small on its own but, collected across hundreds of deployments, describing the real distribution of how this category of work behaves rather than the idealized version on a process map.
That collection has a name in flowscope's stack: the exception-and-pattern library. It is the concrete artifact behind the abstract claim that context compounds. When a new customer comes on, the agent does not meet their document variability for the first time. It meets a distribution it has already seen most of, because the long tail of document variability is largely shared across customers in a way the customers themselves never realize. Two firms in unrelated industries receive remittance advices with the same dozen structural quirks, and the library already encodes how to read them.
The loop, stated as a mechanism
The flywheel is a feedback loop with four stages, and each is worth naming literally rather than gesturing at momentum. Observation feeds the library: every live deployment surfaces exceptions and variants that the agent infrastructure records, together with the resolution that worked. The library then raises capability, because a larger and better-curated set of handled exceptions means the agent resolves a higher fraction of cases without human escalation, on inputs it would previously have failed.
Higher capability lowers context-acquisition cost on the next customer. The expensive part of onboarding a new customer is learning their idiosyncrasies, so if most of those idiosyncrasies are already in the library, the marginal observation needed to reach production drops and the next deployment runs faster and cheaper. Cheaper deployments then fund more deployments: lower cost per engagement at constant or rising capability means more engagements are economically viable, which generates more observation, which feeds the library again.
That is the full cycle. Observe, accumulate, raise capability, lower acquisition cost, deploy more, observe more. The term flywheel is precise here because each turn of the loop makes the next turn easier with the same applied effort, which is the one place in this argument where the word earns its use as a defined mechanism rather than decoration.
Why context compounds and code does not
The obvious objection is that the agents themselves are software, software is the deliverable, so this is a software moat under a new label. The difference is the center of the argument. Code is copyable: a competitor who sees the output can reproduce the function, and the marginal cost of producing competent code is falling toward the cost of the model call that generates it, which is the subject of code was never the moat. A flywheel needs an input that gets more valuable as it accumulates and that a rival cannot acquire by copying the visible artifact. Code fails both conditions, because a copy of the code is as good as the original, and having more code does not make the next line cheaper to write in any compounding way.
The exception library passes both. It gets more valuable as it grows, because each added exception raises the fraction of real-world inputs the system resolves, and it cannot be acquired by copying anything visible, because it is not visible. It is the residue of having watched the work happen across many sites. A competitor can read flowscope's marketing and infer the categories of work it automates; they cannot read the specific resolution for the specific malformed input that one customer's upstream system produces every Tuesday, because that resolution was never written down anywhere a copy could reach. It was observed and recorded into the library.
Why it cannot simply be written down
This connects to the deeper reason documentation is not a substitute, which flowscope has argued in why documented processes rot. Polanyi's account of tacit knowledge holds that practitioners know more than they can state, so the experienced clerk handles the odd case correctly without being able to articulate the rule they followed. Nonaka and Takeuchi's SECI model, from their 1995 book The Knowledge-Creating Company, describes how organizations convert that tacit knowledge into explicit form, and theirs is the optimistic account, built on case studies of Japanese companies that ran the conversion deliberately and well. Polanyi's point is the reason the conversion still never completes: whatever the practitioner cannot state never reaches the page. The process map a customer hands over is the explicit residue, and it has already shed most of the exception-handling that makes the work actually function.
The consequence for the flywheel is direct. You cannot buy the accumulated context, because the people who hold it cannot fully sell it: they cannot write down what they do not know they know. You can only acquire it the way flowscope's infrastructure does, by observing the work in production and recording what resolved each case. That is why the library is the asset and the code is not. The library is the captured form of knowledge that resisted being captured by documentation, accumulated across more sites than any single firm's practitioners ever saw.
The counter-thesis, and where it bends
The strongest counter is that this is a horizontal claim and verticals will out-compound it. A firm focused on one industry, the argument runs, sees the same document types and the same exceptions repeatedly, so its library densifies faster within that industry than a horizontal firm's does across all of them. There is real force here, because within a single vertical a focused competitor will reach high coverage on that vertical's specific tail sooner.
Where it bends is the layer the flywheel actually runs on. The exception-handling and write-back machinery that turns an observed variant into a resolved case is not industry-specific. The mechanics of reading a malformed document, routing an over-threshold case for approval, and writing a value back into a system of record recur across verticals, which is why the same infrastructure scales the way services-as-software firms scale rather than the way a single-industry integration does. The vertical firm densifies one tail, while the horizontal firm densifies the shared mechanics under every tail, so each new vertical it enters starts from that base rather than from zero. The compounding is real in both cases. The question is whether you would rather own one industry's exceptions or the apparatus that resolves exceptions everywhere, and the apparatus is the larger and less copyable of the two.