From Process to Flywheel

For decades, process management has meant drawing a straight line from start to finish. Map the steps. Automate where possible. Optimize the happy path. Ship it. Move on.

That mental model was built for a world in which computers could only execute deterministic logic. A rules engine was roughly as good on day 1,000 as it was on day 1 unless humans stopped, analyzed what had happened, rewrote the rules, and shipped an expensive update. There was no native feedback loop. The human at the beginning and end of every process was, for all practical purposes, invisible to the system.

The result is well documented: only a limited share of work was automatable. The rest stayed locked inside applications, spreadsheets, email threads, and the heads of the people who knew how things actually worked.

We have written extensively about why that model is broken, or at least incomplete. But today we want to address something deeper: the straight line itself is the wrong shape.

Processes Are Not Straight Lines

The implicit assumption behind every traditional workflow builder is that the process is a solved problem. You define it once, deploy it, and run it, hopefully forever. Change is treated as an exception. An expensive, project-gated exception.

That assumption was never really true. It was simply the best abstraction our tooling could support.

The companies that consistently win do not treat their processes as fixed. They treat them as living systems that evolve with every execution. Jeff Bezos captured this with his famous “it is always Day 1” principle: the belief that the process is never finished. SpaceX is perhaps the clearest operational example. Every Falcon 9 launch is not just a mission. It is also a data point that feeds back into how the next launch is designed, tested, and executed.

Agile development and Kanban already acknowledged that we needed to stop pretending everything could be predefined. But those ideas were mostly applied to software development. What happens when we apply the same thinking to operational processes, such as how an insurance claim is handled, how a logistics exception is resolved, or how a compliance review is conducted?

The Flywheel

The answer is what we call the flywheel. Instead of a straight line, think of an infinity loop: one side resolves the case in front of you, the other improves the system that will resolve the next one.

Case resolution -> Trace and outcome -> Learning -> System update -> Better next case

It may look like a small conceptual shift. In practice, it changes how work is designed, measured, and improved.

A straight-line process optimizes for throughput. A flywheel optimizes for time to improvement. The former asks, “How fast can we complete this case?” The latter asks, “How fast can we make the next case better than this one?”

This distinction matters because improvement compounds. If every cycle through the flywheel makes the process even slightly better, more accurate, faster, cheaper, or more resilient, the cumulative effect over hundreds or thousands of cases is enormous. At enterprise scale, where a single process may handle tens of thousands of cases per month, this compounding is the difference between incremental efficiency and structural advantage.

There is, of course, always a ceiling imposed by the complexity of the real world. During our time at Hyperscience, we saw this clearly in document-heavy back-office operations. A model could reach very high accuracy, yet automation rates would still depend on the variance of the incoming work. When a new document type or channel was introduced, performance could drop immediately, not because the system was broken, but because reality had changed. The only durable answer was to capture the new data, retrain, validate, and redeploy. The work of improvement never ended.

That is the real point: operations are never “done.” Asking when an operational system is finished is like asking when FedEx’s logistics network is finished. Real-world processes live inside a changing environment. They absorb new variance, new rules, new edge cases, and new expectations. The winning system is not the one that assumes stability. It is the one that learns fastest.

Two dotted loops joined at a shared learning point: an execution loop that resolves the current case and an iteration loop that improves the next run — The flywheel is not just a loop of work. It is a loop of work, feedback, and adaptation, where every run can make the next one better.

Why Now

The flywheel is not a new concept. What is new is that we finally have the technology to make it practical.

Machine learning showed us the pattern early. At Hyperscience, where several of our team members worked previously, the cycle was clear: take real-world data, train a model, deploy it, catch deviations, retrain, redeploy. The product did not just do the work. It constantly tried to do the work better. That infinity loop of execution and learning was the product.

Large language models take this further. They let us build an AI flywheel of case resolution: resolve the case, capture the trace, route feedback to the right owners, improve the system, and feed that improvement into the next case. Because agents operate in natural language, that feedback loop becomes accessible to the people closest to the work — the domain experts who actually understand what “better” means in the context of a specific process. An operations lead does not need to retrain a neural network. They adjust a procedure, refine an instruction, or provide feedback on an agent’s output — and the system learns.

This is fundamentally different from traditional workflow builders. In a visual workflow builder, complexity grows until it exceeds human capacity to manage. We have all seen the diagrams: a simple flow becomes a sprawling web of branches, conditions, and error handlers that nobody dares to touch. Testing it is impractical. Iterating on it is expensive. Replacing the person who built it is a crisis.

A simple workflow diagram: start, capture, validate, a decision with approve and reject branches, and a rework loop back to validate — At first, a workflow looks perfectly manageable: a start, a few steps, one or two decisions, and an end. This is exactly why workflow builders feel so intuitive at the beginning.

What a Flywheel Looks Like in Practice

At Interloom, we organize our own operations around flywheels. Here are two concrete examples from our team.

The Customer Success Flywheel

When a customer interacts with an AI agent during a case and something goes wrong — or right — the feedback triggers a set of interconnected loops:

Forward engineering loop. Our customer success team receives the feedback alongside the full execution context: the procedure, the stage, the agent’s actions, the tool calls, and the customer’s response. If the issue sits in the operational logic, they review the procedure instructions and optimize them directly by adjusting language, reordering steps, adding guardrails, and clarifying handoffs. The improved procedure is live for the next case.
Tool and integration loop. Sometimes debugging shows that the agent did something wrong, but the root cause is not the instruction itself. The issue sits in a tool, an integration, an API contract, or the way a capability is exposed. In that case, the invocation trace becomes a concrete feedback item for the responsible owner. An agent can inspect the trace, reproduce the failure, check the integration and API calls, draft a fix, test it against historical cases to avoid regressions, and ship a pull request for review and deployment.
AI optimization loop. If the problem sits in the model behavior, the prompt architecture, or the agent policy rather than the procedure or the tool, our AI team uses the same trace to create a reproducible scenario. They evaluate it with graders, tune the agent configuration — model selection, prompt structure, tool access, and control logic — and validate the fix against the broader suite before deployment.

Once a fix ships, forward engineering closes the loop with the customer and monitors the next cases. That is the organizational point: only the customer’s domain experts can say whether an underwriting decision was actually good or bad. Forward engineers can judge procedures and prompts. AI teams can judge model behavior and agent policies. Integration owners can judge tools, APIs, and reliability. Designing the organization as a set of linked flywheels lets each group stay vertically specialized while the system as a whole gets better one turn at a time.

The Integration Flywheel

When an agent encounters an error from an external system — a failed API call, an unexpected response format, or a timeout — the system routes the exception to the responsible integration owner. An AI agent can immediately draft a fix as a pull request. The integration manager reviews it, tests it against the last thousand cases plus the new scenario, and deploys. No project plan. No sprint planning. The integration improves within the same day, and every subsequent case benefits.

The Organization as a Network of Flywheels

In many ways, designing those flywheels, and defining how they hand work off to one another, is the new clockwork of the organization. The real design challenge is not a single process map. It is how you weave multiple flywheels together so that feedback in one area improves outcomes in another. In that sense, the flywheel becomes an operational expression of what Jim Collins called the economic engine of a company, extended down into everyday execution.

Once you start seeing flywheels, you see them everywhere. Customer success feeds into AI improvement. AI improvement feeds into better integrations. Better integrations reduce exceptions. Fewer exceptions free up customer success to focus on harder problems.

The organization is not a hierarchy of departments executing fixed processes. It is a network of interconnected flywheels, each turning at its own cadence, each reinforcing the others.

Four dotted flywheel circles for customer success, AI optimization, integrations, and ops, touching at marked handoff points — Each flywheel has its own improvement loop, but the compounding value comes from the handoffs between them: shared context, routed feedback, and faster iteration across the whole system.

This maps directly to what Bret Taylor, CEO of Sierra and former co-CEO of Salesforce, has articulated: a company is nothing more than a collection of its processes. We would extend that: a company is a collection of its flywheels. And its operational excellence is measured by how fast those flywheels turn.

The broader organizational consequence of this deserves its own essay. If you want the full argument for why AI can take over parts of organizational coordination, why specialists remain vertical, why outcome ownership remains horizontal, and why the right analogy is closer to Google Maps than to a static workflow, read The Use of Knowledge in Organizations.

For this essay, the important point is narrower: once coordination becomes more dynamic, the process itself cannot remain a rigid line. The process needs to learn. That is the core shift from process to flywheel, and it is what we are building Interloom around.

Why Workflow Builders Cannot Get You There

Traditional workflow builders fail at this not because they lack features, but because their fundamental abstraction is wrong. They model processes as directed graphs — nodes and edges, conditions and branches. This works beautifully for simple, stable processes. But the moment a real-world process reaches production complexity, the graph becomes unmanageable.

An accounts payable workflow with dozens of stations and crossing dashed connections spread across capture, matching, controls, exceptions, and outcomes stages — The problem is not that enterprise operations need more boxes and arrows. It is that real work contains more variation than any person can continuously reason about as a static graph.

This is not so different from traffic. You can govern a road network with fixed rules, static signs, and a traffic plan drawn in advance. That works up to a point. But once the environment becomes dynamic enough, no human operator can continuously optimize all routes in real time. Modern navigation systems changed the game by turning traffic management into a live coordination problem: ingest signals, update guidance, and improve outcomes continuously.

We believe back-office operations are heading in the same direction. The orchestration layer will not just route tickets or automate steps. It will treat domain experts, software systems, and AI agents as first-class participants and learn the best assignment of work one case at a time.

That was one of the core reasons we decided to start from first principles with a new workspace and platform designed around these concepts. Over time, many of today’s software categories — ticketing, orchestration, automation, and process mining, which Gartner groups under BOAT — will look less like separate products and more like capabilities of a single orchestration layer for case resolution. When the work is repetitive but unstructured, the system needs shared context more than it needs yet another silo.

We made a deliberate decision early on at Interloom: we would not build another workflow builder. Instead, we designed procedures as natural-language definitions that any domain expert can write and iterate on. A procedure is a sequence of stages, each with clear instructions and completion criteria. No visual spaghetti. No branching logic that requires a developer to debug. Language is enough to express objectives, resolve blockers, and signal outcomes.

The power of this approach is not just simplicity — it is iterability. When the unit of process definition is natural language, the feedback loop closes faster. An expert reviews a case outcome, updates an instruction, and the next case runs differently. The flywheel turns.

From Rigid Deployment to Continuous Improvement

The traditional enterprise automation paradigm looks something like this:

Spend 6 to 18 months defining and implementing a process
Deploy it
Discover it does not match reality
Spend another 6 to 18 months on change management
Repeat

This is why change management is an industry unto itself. This is why decision makers who have tried to transform operations know the pain of replacing one rigid system with another. And this is why, as we discussed in Adaptive Software for Rapid Change, operational teams end up as the glue — manually bridging the gap between what the software can do and what the business actually needs.

The flywheel approach inverts this. You start small. You deploy a procedure that handles the core case. The first execution generates feedback. The second execution is already better. Within weeks, not months, the process has adapted to the real world because the real world is feeding directly into the process definition. And it keeps adapting with every change that hits it.

This is also why we believe in keeping an expert in the loop. Someone still needs to judge whether the system is tracking reality correctly, just as document experts had to verify and redirect models when new data distributions appeared. AI accelerates iteration. It does not remove the need for grounded operational judgment.

This is also why we believe the most important KPI for any organization adopting AI is not “largest use case automated” but time to iteration — how quickly you can improve any given process by even a small increment. The organizations that optimize for iteration speed will compound their way to operational excellence. The ones that optimize for the single big deployment will keep running into the same wall.

Rethinking How Organizations Are Built

The implications go beyond tooling. If the fundamental unit of operational excellence is the flywheel, then organizations need to be structured around flywheels, not around static process ownership. The key management question becomes: what outcome signals do we capture from each case, who owns them, and what improvement loop do they trigger?

As we wrote in AI-Native Organizations, the arrival of AI agents demands a rethinking of how specialization, coordination, and leadership work. Flywheels are the operational manifestation of that rethinking. Each flywheel has an owner — the expert who is accountable for its improvement velocity. Each flywheel has participants — humans and agents who execute within it. And each flywheel has interfaces — the points where it connects to and reinforces other flywheels.

Jack Dorsey recently published a timely piece on the emerging persona types in AI-augmented organizations. His framework identifies three roles that map naturally to the flywheel model: the human in the loop who executes within the process, the expert in the flywheel who owns the iteration cycle, and the skill coach who optimizes individual capabilities for both humans and agents. We have been designing Interloom around this very thesis for more than 2 years — and seeing it articulated from outside our own walls reinforces our conviction that the shift from static hierarchies to dynamic, flywheel-oriented teams is not a niche prediction but an emerging consensus.

We fundamentally believe that superior outcomes require experts. The vision of fully autonomous AI running entire business functions remains distant, and perhaps undesirable. The world is inherently more complex than our models pretend. Much of that complexity is solved daily by front-line workers who deal with the edge cases no system anticipated. The flywheel honors that reality by keeping experts at the center of the improvement loop while using AI to accelerate it.

What Is Coming Next

We are building Interloom to be the platform that makes flywheels practical for complex back-office operations. This means:

Procedures that are written in natural language and iterable by domain experts
Grading and evaluation built into the platform, so every case execution produces structured quality signals that feed the flywheel — a capability we have recently shipped
Agent feedback loops that connect case outcomes to prompt optimization, tool configuration, and model selection
Cross-flywheel visibility that shows how improvements in one area propagate through connected flywheels

We are also developing an internal assistant designed to help managers set up their organizations around AI-native processes that iterate fast and build these flywheels from the start — a capability we are excited to share more about soon.

The shift from process to flywheel is not just a product feature. It is a way of thinking about organizations. It is the recognition that in a world where AI makes iteration cheap, the companies that learn fastest will win. Not the ones with the most complex workflows. Not the ones with the largest automation budgets. The ones whose flywheels turn the fastest.

This post builds on ideas from our earlier writing on adaptive automation, AI-native organizations, and adaptive software for rapid change. For a deeper look at the platform concepts referenced here — cases, procedures, stages, and actors — see our core concepts documentation.