Is the Loop Really the Right Unit of Company Design?
Why workflows, value streams, capabilities, projects, networks, and executable loops reveal different truths about an AI-native organization
In a large open-world game, the surrounding world had to appear alive while the player moved through it at speed. Pedestrians, vehicles, and interactive objects needed to respond at the right moment, but no individual actor could afford to understand the whole world. Each one received enough local context to behave plausibly inside a bounded range. Shared systems carried movement, collision, animation, spawning, gameplay, and performance across the wider experience.
A character could select the logically correct behavior and still look absurd because the animation arrived late, another actor blocked the path, the collision system disagreed, or the performance budget collapsed under the combined load. The visible intelligence did not belong to one behavior loop. It emerged from several kinds of structure working together.
That experience is one reason I became attracted to loops as an organizational design object. A loop seems to offer what a conventional workflow often lacks: sensing, interpretation, decision, action, verification, and learning connected across repeated work. It appears dynamic where the org chart is static and consequential where a task list is merely active.
I pushed that idea too far.
An earlier version of The Executable Company treated the loop as the primary unit of AI-native organization design. The claim was elegant, memorable, and too broad. A company contains recurring work, movement toward value, enduring capabilities, temporary change, relationships, formal authority, identity, conflict, and institutional purpose. Calling all of these loops does not integrate them. It erases distinctions the design needs.
The previous issue argued that one consequential operation is the safest construction method for serious AI transformation. This issue asks a harder question about the language underneath that method: when does a loop reveal an executable responsibility, and when does it flatten the company into a diagram that is too neat to be true?
Why the loop is so attractive now
The current agent conversation gives the loop unusual prominence. OpenAI's practical guide to building agents describes an agent run as a loop that continues until an exit condition is reached. Anthropic's guidance on effective agents distinguishes predefined workflows from agents that dynamically direct their own process and tool use. These are useful engineering distinctions. They help a team decide how software should progress through a task.
The organizational conversation is moving in a similar direction. Microsoft's 2026 Work Trend Index describes the strongest firms as learning systems in which work produces signals and those signals reshape future work. It asks who reviews agent performance, who has authority to update the workflows agents run, and how a local win becomes shared organizational knowledge. The report is based on Microsoft telemetry and a large survey of AI users, with several results explicitly described as associations rather than causal effects. Even with that boundary, the direction is important: organizations are being asked to learn from execution rather than merely deploy more tools.
But an agent loop, a workflow, and an organizational learning system are not the same object.
The agent loop concerns the computational actor's progress: what it observes, which tool it calls, what state changes, and whether a stopping condition has been met. The organizational responsibility concerns what happens across customers, employees, policies, commitments, authority, resources, and time. The company must also preserve capabilities, relationships, legitimacy, and options that may not appear inside the immediate run.
A technical loop can finish while the organization fails. A support agent can resolve a ticket while the customer remains harmed. A deployment agent can complete a rollout while a slower signal reveals that trust, accessibility, or product quality has deteriorated. A planning agent can produce an internally coherent answer while the people needed to execute it no longer possess the capability, capacity, or authority the plan assumes.
The loop is therefore not wrong. It is incomplete in a specific way: it sees returned evidence and repeated action well, but it does not automatically reveal the institution surrounding them.
One responsibility, six lenses
The same responsibility can look very different depending on the question being asked.
A workflow or process shows how recurring work progresses through events, decisions, handoffs, exceptions, and completion. BPMN is already capable of representing branches, gateways, transactions, and interruptions. A workflow does not become intelligent merely because someone redraws it as a circle.
A value stream follows the material and information required to create value and makes waiting, rework, and local optimization visible. Lean practice defines a value stream broadly enough to include both value-creating and non-value-creating activity from origin toward the customer. That lens is powerful when the problem is flow, but customer flow alone may miss authority, affected parties who are not customers, or the capability the company is consuming to create the result.
A capability asks what the company must remain able to do, regardless of the current org chart, project, software product, or named individual. The Open Group's business capability and value-stream guides exist because process, capability, organization, and value are related but not interchangeable. A capability view can reveal that a company is borrowing an essential ability from one experienced person even when the workflow appears stable.
A project organizes temporary change toward a unique result. The Project Management Institute defines a project as a temporary endeavor rather than a permanent operating structure. That distinction matters because the team that builds an AI-enabled operation is not necessarily the team, capability, authority, or funding model that must sustain it after launch.
A network reveals who depends on whom, where information and trust travel, and where informal power or brokerage sits. Organizational network analysis studies actors and the ties through which advice, support, information, and influence move. This lens can expose the person everybody calls, the community whose response determines legitimacy, or the specialist whose absence makes an apparently automated operation impossible.
An executable loop asks a narrower question: how does observed consequence govern later recurring execution?
| Lens | Primary question | What it may miss alone |
|---|---|---|
| Workflow or process | How does recurring work progress? | Whether completion produced the intended consequence or changed later behavior |
| Value stream | Where does value flow, wait, or accumulate rework? | Authority, legitimacy, learning level, and non-customer affected parties |
| Capability | What must the company remain able to do? | The live path through which one consequence is produced and learned from |
| Project | How is temporary change delivered? | The persistent operation after delivery |
| Network | How do relationship, dependency, trust, and power operate? | Exact execution and verification state |
| Executable loop | How does observed consequence change later bounded execution? | The wider institution, capability system, culture, and value architecture |
Table 1. One responsibility, six organizational lenses. Each reveals a different question and a different blind spot.
No row wins. Each lens reveals a different failure.
A game team responding to player reports needs several of them at once. Workflow shows how a signal travels through community, support, design, engineering, quality, release, and operations. Value stream reveals waiting and rework. Capability asks whether the studio can still diagnose and change the game rather than merely route tickets. Network shows which communities, platform partners, and specialists influence the decision. The loop asks whether the released change produced its intended consequence and what later work should change because of it.
The loop earns no credit for redrawing the other five as a circle. Its distinct commitment is that recurring responsibility remains open until consequence can be observed and allowed to change what happens next.
Figure 1. One responsibility, six lenses. The right unit depends on the problem the organization needs to see.
The agent loop sits inside the organizational operation
The distinction becomes clearer when the clocks are different.
An agent may run for seconds or minutes. It retrieves context, reasons, calls tools, reads the result, and stops. The surrounding operation may take hours or days because evidence must be reviewed, a commitment negotiated, a payment settled, a build verified, or an affected person given a meaningful chance to respond. The company may discover the real consequence weeks or months later through customer trust, capability loss, employee behavior, regulatory attention, or a changed market.
The fastest loop usually produces the most immediate data, so it is easy to let that loop define success. Yet the evidence that matters most may arrive later. Design has to state which slower signals can reopen a faster declaration of completion.
This is why responsibility must be designed before automation. The World Economic Forum's 2026 agent authorization playbook proposes deployment-level profiles that make delegated capability, authority, constraints, and monitoring explicit. That is useful because an agent loop does not create its own legitimate boundary. It inherits purpose, representation, authority, and stopping conditions from the organizational operation around it.
A refund agent may end when an approval is issued. The operation may remain open until settlement, customer confirmation, reconciliation, and remedy are complete. A code agent may end when a change is merged. The operation may remain open through deployment, observed behavior, rollback conditions, user impact, and later maintenance. A hiring agent may end when a recommendation is produced. The institutional responsibility includes evidence quality, decision authority, fairness, contestability, communication, and the capability the company needs to retain.
Planning the steps does not make the agent owner of the outcome.
Figure 2. The agent loop is one computational participant inside a slower organizational responsibility and a wider living institution.
The loop earns a narrower role
A loop becomes an executable organizational design object only when four conditions hold.
First, there is a bounded consequence rather than a broad domain or isolated task. “Run customer support” is too broad. “Classify this message” is too small. A bounded consequence might be to turn a customer problem that cannot be resolved in the ordinary path into an owned resolution whose outcome is confirmed and whose evidence changes later handling where warranted.
Second, the consequence can be observed with warranted evidence. Completion events are not enough. The design has to name what evidence can close the responsibility, who may judge it, when it becomes available, and what later evidence can reopen the conclusion.
Third, returned evidence can change later execution. Feedback that produces another dashboard, transcript, or retrospective is not yet organizational learning. Learning occurs when a threshold, routing rule, policy, evaluation case, capability investment, authority envelope, or operating assumption changes.
Fourth, responsibility, authority, persistence, and the ability to stop are traceable. Someone can explain who defines the purpose, who may act, who is affected, who can interrupt the operation, what state persists across cycles, and how the organization returns to a known-good path.
If any of these conditions are missing, the loop may still be useful as a software mechanism or visual metaphor. It has not yet earned the stronger organizational claim.
This narrower definition also protects a distinction that Chris Argyris made long before agentic software. Double-loop learning is not simply more feedback inside the same process. It questions the governing variables behind action. An automated system can optimize execution inside a declared objective. It cannot determine by mechanism alone when that objective should be challenged, whose interpretation should prevail, or whether people with power will permit the question to be asked.
Reflection is an institutional capacity. It is not a larger automated loop.
Use the smallest set of lenses that keeps the design honest
There is an obvious objection to this argument. Leaders do not need six competing diagrams every time they change a workflow. A plural set of lenses can become analysis paralysis, professional territory protection, or an excuse to avoid choosing an operating unit at all. A loop is attractive partly because it gives a team one thing to build.
That objection is right. The answer is not to require every lens at equal depth.
Begin with the consequence and select the primary lens that reveals the current problem. Use a workflow when sequence and exception handling are unclear. Use a value stream when delay and rework dominate. Use a capability view when the organization is losing or borrowing an enduring ability. Use a project when the challenge is temporary change. Use a network when trust, dependency, brokerage, or informal power determines the result. Add an executable loop when verified consequence should govern later recurring execution.
Then run three cross-checks before granting the chosen lens too much authority.
Capability: What must remain possible after this operation is faster or more automated?
Power and relationship: Who can now see, decide, interrupt, contest, or disappear from the work?
Consequence: What evidence outside the immediate activity can prove success, reveal transferred burden, or reopen the result?
This is a minimum lens stack, not a complete model of the company. It gives the team one primary object while preventing that object from quietly redefining everything around it.
The human middleware identified in an earlier issue is a useful test. If the person everyone calls is carrying state, commitments, relationships, capability, and informal authority, no single workflow diagram will explain their role. If a loop removes their coordination work but also removes the only place where conflicting realities were reconciled, the organization has not become more executable. It has made the missing institution harder to see.
A company designed now would use workflows where sequence matters, value streams where flow matters, capabilities where enduring ability matters, projects where temporary change matters, networks where relationship and power matter, and loops where verified consequence should govern later recurring execution.
The loop is not the company.
It is a lens for bounded adaptive execution. That is enough to make it valuable, and narrow enough to keep it honest.
What recurring responsibility inside your organization is currently being described through the wrong lens? I am especially interested in examples where a workflow looked complete, a local loop looked successful, or an agent run finished, while capability, relationship, authority, or the real consequence remained unresolved. Please describe the pattern rather than confidential company, customer, employee, product, or system details.
Dogu Taskiran