Swarms, Models, and Waves
Creating a Rational AI Stack for Adaptive Agile
Article 2 of 3: From World Models to Operational Architecture
"If companies do not develop a core business process they can protect, they will become the equivalent of herders managing someone else's agentic platform. If the procedural models, the agent orchestration, and the data all live within vendor platforms, organizations lose the ability to differentiate, adapt, or even understand their own operations."
"A world model of your product maps all the information and behaviors of that product! Lightweight local AI agents can coordinate through signals in the model data rather than through direct vendor frameworks. How you control your AI story now will define the choices you have in the near future."
1. Where the 'Adaptive AI' post left off
The first article in this series introduced world models as a way to think about AI adoption without repeating the mistakes of early Agile. We argue that role clarity, data pipelines, and trust-building matter more than tool selection, and that organizations need shared representations of how intent, roles, data, and validation interact across the product development cycle.
That article focused on why world models are necessary and how to begin implementing them through incremental role-based changes. This article asks a harder question: what does the technical and organizational architecture look like when world models become operational?
The answer requires thinking about three interconnected concepts: models that represent your business processes, swarms of agents that operate within those models, and waves that synchronize how information propagates through the system. Together, these form what we can call a rational AI stack.
Few AI offerings do more than promise more productivity. There is strong incentive for Vendors to own the model and data architecture. Now is the time for business to pivot towards adaptive agile. Rational and useful AI stacks are emergent when product models, functional team models, and information models become the basis of product development.
Notes:
- These articles present a systems approach that benefits from the increasing body of knowledge documenting how companies are using AI to enhance product development. This discussion does not re-invent the concepts of digital twins, simulation, or agentic managerialism... but provides a framework to make them work for you now.
- The AI technical stack is evolving quickly. Abstractions used in these articles represent agentic patterns that amplify data-focused agile practices. My focus is on the 'people' process stack!
2. The Current AI Integration Problem
2.1 The Hammer Problem
Depending on your source of information, AI is either taking over the world or generating profound resentment. In the trenches, there are solid steps toward integrating AI with agile product development. But the dominant approach from vendors is to treat AI as a hammer and every feature as a nail.
Consider Microsoft’s approach with Copilot: it appears like an unexpected guest in every application you open. Not every role needs the hammer of AI summaries, insights, and generative output. The AI-everywhere approach has created fatigue and resentment about screen real estate, a lurking fear about oversharing private information, and diminishing trust in the tools people depend on for their work.
2.2 The Vendor Incentive Mismatch
AI adoption in the enterprise appears critical to consume enough tokens to support current massive CapEx investments. Even averaging between “we will build it and they will come” and “demand will far outstrip our supply,” most companies are fielding AI tools, and accept that vendors have bet their future on expanded token use. AI-washing already provides CEOs leverage to rationalize massive capital investments and layoffs.
Vendors need to (re)build trust within the Enterprise hierarchy. They also need to approach their market from their customer's perspective using insight and empathy. Users are not resisting AI because they fear change; they are resisting because the current integration model disrupts workflows rather than enhancing them.
2.3 What Needs to Change
For AI to succeed in the enterprise market, vendors must embed AI tools into current workflows, not bolt them on as separate features. For enterprises to succeed with AI, vendors must provide world-model based architectures that serve as the skeleton for workflow-oriented and outcome-focused enterprise tools.
3. From World Models to Procedural Models
3.1 World Models Need Operational Detail
My first article described world models at a conceptual level: shared representations of intent, roles, and data flows that adapt as AI changes the economics of production. But a world model that lives only as a concept or a diagram on a wall does not help coordinate actual work. It needs to become real and computational.
A world model for a product organization can encompass everything associated with the entire business and product lifecycle. For humans alone, maintaining this level of comprehensive representation is not a reasonable expectation. But with AI, it is not just a possibility but a requirement. The model needs to know the org chart, who needs what information and when, and potentially specific strengths and communication preferences for teams and individuals.
It’s a useful concept to consider that people, teams, and AI agents all have their own perspective, or frame of reference. Products, services, and companies also have their own frames of reverence. From the perspective of a product under development, there are human intents and requirements towards which to aspire, and AI agents that iteratively guide the way towards those goals. This view of human intent made real is the AI way.
3.2 Procedural Models as the Operational Layer
The operational form of a world model is what we can call a procedural model: a representation of all possible paths through product features and product development roles, including changes to process, state, status, and phase. The paths often travelled establish maps we can use for optimization.
The first map is a procedural model of all possible paths through product features. Information that represents the product, and how it behaves accumulates as core data - the intellectual property of a business.
The second map is a procedural model of all possible paths through product development: roles, process, accountability, lifecycles, finance, marketing, sales, etc. Information that represents the company also accumulates as core data.
The third map is a procedural model of changes to the core data storage. This represents evolution of architecture and data storage from the perspective of the company.
3.3 The Data Starting Point
A practical concern: we may not be able to port existing data into these models, and so organizations should consider starting fresh. The accumulated data debt from years of Agile’s “low marginal value of documentation” philosophy means that much of what exists is incomplete, inconsistent, or stale. Starting anew with intentional data capture, guided by the procedural model’s structure, will produce better results than attempting to clean and migrate legacy information.
4. Agents as Roles: Swarms Within the Model
4.1 The Myth of the Solo AI Builder
There is a concept with long philosophical roots that knowledge is created by individuals alone at their desks producing intellectual masterpieces from whole cloth. The history of industry and startups reinforces this theme: the “few” come up with the big ideas and then companies form to commercialize products. In the rearview mirror, most of these prime movers stood apart with luck, timing, and original thinking that extended a movement already in place. Consider our current crop of tech billionaires: It often feels like genius has left the building.
Much of the current AI hype revels in the idea that a single developer can, through AI agents, divine requirements, implement features, validate workflows, and deploy a product. That a single product manager can engage agents to design, stand up a proof of concept for stakeholder review, and with a sleight of hand replace that developer.
This approach recreates the productivity cliffs and issues that drove the initial adoption of agile. The goal of Adaptive Agile is to graft the hype of AI back to the reality of how people work together. Solo AI-augmented heroics produce demos, not products. Products require coordinated roles, and the AI agents that support those roles need the same coordination.
4.2 Agent Swarms Recapitulate Team Structure
The development of agent swarms and agent teams is recreating the relationships between roles similar to the world models described so far. This is not a coincidence. Effective agent architectures mirror effective team architectures because both are solving the same coordination problem: how to break complex work into specialized concerns and then reintegrate the results.
A swarm of agents operating within a procedural model can take on roles that can be automated, with the human role updated at the right time for a coordinated release. The underlying data paths accrue information as agents operate, and people in their roles consume and contribute to it. This is how AI tools integrate with current roles: not as standalone features, but as participants in a larger coordinated system that provides context and handles the tedious work people generally avoid.
4.3 Operational Coordination with Human Judgment
This is “operational coordination” with humans now operating at the higher level. Agents handle routine state transitions, data transformations, and cross-role communication. Humans provide what agents cannot: clarity of intent, domain judgment, strategic prioritization, and the ability to recognize when the model itself needs to change.
The distinction matters. AI does not have domain experience, intuition, or wisdom to divine human intent, ask the right questions, or reward innovation. Agents within a procedural model execute; humans direct. The procedural model makes the boundaries between these responsibilities explicit.
4.4 Agentic Stigmergy (synergy) and Emergent Behavior
As agentic teams and swarms are deployed now (early 2026), the novel concept is agent-to-agent communication. This is a fundamentally flawed approach, but a necessary step in evolution. A more sustainable approach is to have agents that perform tasks where the business process and product maps provide the local framework, and an agent can read, compute, and write to a local environment. This can scale as an agent can be called to resolve procedural changes made elsewhere in a map. Unplanned recursion can be managed by synchronization.
We know there will be emergent behavior when teams of agents perform actions and can update one another. We might call this 'agentic stigmergy.' Borrowing from the biological concept where organisms coordinate through environmental signals rather than direct communication. Agents operating within a shared procedural model leave traces in the data that inform other agents’ behavior, just as ants leave pheromone trails that coordinate colony activity. The idea of agents working in a native data environment may have security relevance. It might be easier to find maladaptive behavioral patterns in common data maps rathr than hidden data caches managed by agents granted agency with persistent memory.
On the more speculative side, we can consider agent teams as more similar to superorganisms than to simple swarm intelligence. A superorganism is a colony that functions as a unified entity, with specialized roles and emergent capabilities that no individual member possesses. Agent teams operating within a well-structured procedural model may exhibit similar properties: collective intelligence that exceeds the sum of individual agent capabilities.
5. Waves: Time and Synchronization in Procedural Models
5.1 The Problem of Propagation Time
An important concept related to procedural state changes is time. If a change needs to propagate through a model, it takes a minimum amount of time. If there are dependencies or computations that take place at any node on the procedural graph, that will inform how long information takes to find equilibrium throughout the model.
This is not merely a technical constraint; it is a fundamental design consideration. When an agent updates a product requirement, that change must propagate to design specifications, implementation plans, test cases, deployment configurations, and documentation. Each propagation step may involve computation, validation, or human review. The total time to equilibrium determines how quickly the system can respond to change.
5.2 Waves as Synchronization Cycles
This brings up the concept of waves or cycles, similar to how brainwaves synchronize neural activity, to synchronize agentic behavior within the procedural model. A wave represents a propagation cycle: a change enters the model, ripples through dependent nodes, triggers validations and updates, and eventually reaches a new equilibrium state. That equilibrium state can represent a product release or market opportunity.
Different types of changes create waves at different frequencies. A minor bug fix might propagate through the model in minutes, affecting only a few nodes. A major feature change might take days to fully propagate as it touches requirements, design, implementation, testing, documentation, and deployment across multiple teams. Understanding wave dynamics helps teams anticipate how long changes will take to stabilize and plan accordingly.
5.3 Machine Time vs. People Time
The distinction between machine time and people time is critical for wave design. An agent can update a test suite in seconds; a human reviewing the implications of a requirement change for regulatory compliance may need hours or days. The procedural model must account for both, ensuring that machine-speed propagation does not outrun human-speed judgment at critical decision points.
[Placeholder: Detailed example from LastPass or other case study: updating a feature’s behavior up and down the stack with a procedural model, showing the difference in diffusion time based on “people time” vs. “machine time” at each procedural node.]
6. The Rational AI Stack
6.1 Assembling the Pieces
The three concepts developed in this article, procedural models, agent swarms, and propagation waves combine into what we can call a rational AI stack. “Rational” because it is grounded in the actual structure of how work is done, rather than in the aspiration that AI will simply make everything faster.
At the foundation are procedural models that represent both product behavior and development process. Operating within those models are agent swarms that handle automatable tasks while humans retain judgment and direction. Synchronizing the system are waves that manage how changes propagate and when human review is required.
6.2 AI as Business Simulation
Taken together, this stack enables a powerful shift in how organizations relate to AI. AI becomes a simulation of the business that accumulates context larger than any person can hold at once, and provides guidance toward turning intent into product with human ingenuity, experience, and direction.
This is fundamentally different from the current model of AI as a productivity tool bolted onto individual applications. It is AI as organizational infrastructure, a living representation of how the business operates that improves through use and adapts as the business evolves.
7. The Sovereignty Question
There is a strategic imperative embedded in this architecture. Vendors need to avoid the crash that took out previous infrastructure investments... with the best example the telecom bubble and bust in the early 2000's. For any realistic return on the significant Capex investments, Vendoros are betting they can share or own some aspect of their customers computation and data.
If companies do not develop a core business process they can protect, they will become the equivalent of herders managing someone else’s agents. When the procedural model, the agent orchestration, and the data all live within vendor platforms, organizations lose the ability to differentiate, adapt, or even understand their own operations.
The rational AI stack must be, at its core, something the organization owns and evolves. Vendors provide tools and infrastructure. The business process models that together are the corporate world model made operational belong to the organization.
8. Models Adapt: From Agile to Adaptive Agile
8.1 Superorganisms Evolve
Models and superorganisms adapt over time, with a nod toward evolution. In a procedural model this includes the nodes (roles, both human and agent) and the edges (data flows, handoffs, dependencies). The move to Agile represented one such adaptation in how product development was organized. The move to Adaptive Agile is another.
The difference is that Adaptive Agile builds-in the expectation of continuous change. The procedural model is not a fixed architecture to be designed once and maintained; it is a living system that evolves as AI capabilities improve, as team dynamics shift, and as business requirements change.
8.2 A Cautionary Note on Speed Without Structure
To close with a pointed example: one former xAI employee described writing code so fast there was no time to document the work. This implies a core failure in how AI is being used to develop AI. Agentic development systems should begin with the concept of teams with roles that include documentation and testing. Speed without structure produces technical debt at machine velocity and technical debt, as twenty years of Agile taught us, is the silent killer of productivity.
9. What Comes Next
This article moves us from the conceptual framework of world models to the operational architecture of procedural models, agent swarms, and propagation waves. We argue that the current vendor approach of AI-as-hammer fails because it ignores the underlying structure that differentiates how work is done over time. A rational AI stack must be grounded in that structure.
The third and final article in this series will address implementation: how organizations begin building procedural models from their existing processes, how to structure agent teams that complement human roles, and how to measure whether the system is producing better outcomes. We will also address the cultural and organizational changes required to move from traditional Agile to Adaptive Agile, and the realistic timelines for doing so.
Draft Notes
• Placeholder needed: Section 4.2 - add a concrete example of an agent swarm operating within a procedural model. For now use the “one-touch approach."
• Disambiguate: everywhere - figure out how to introduce the multiway graph 'node' and 'edges' concepts without pain."