World Models in Product Development

or How to Stop Worrying and Love AI

Article 1 of 3: From Agile to World Models

Introduction: The Pattern We've Seen Before

Companies are spending more than $500 billion on AI this year. Software development teams question whether they need project managers when AI can ideate, develop requirements, and iterate with the team. Applications can be created from whole cloth and deployed by developers alone.

In the wider corporate world, AI prompts in browsers and applications are available to automate clerical tasks as well as the operational tasks that once defined project management. However, 95% of these business-focused AI projects deliver no return on investment, and an increasing number of investors and analysts are demanding 'show us the money'!

A very similar pattern happened before - with Agile - and we spent twenty years figuring things out through trial, error, and painful transformation. The difference is that AI adoption is measured in months and years, not decades. Delay will have existential costs.

The Central Challenge

AI adoption requires the same fundamental shift Agile needed: role clarity combined with reliable data pipelines. But this time we're armed with experience, and we can't afford another generation of costly mistakes.

The solution lies in world models‚ co-evolving representations of intent, roles, and data that adapt as AI changes where bottlenecks emerge in the product development cycle. This isn't a new framework to learn. It's an evolution of the roles you already have, informed by a decade of experience moving product development teams toward the processes needed to successfully adopt AI.

The Core Problem: Why AI Projects Are Failing

The Numbers Tell a Story

Initial enthusiasm for AI tools leads to high usage rates that fall off quickly and precipitously. Companies introduce AI programs and see short-term productivity increases followed by rapid decreases. The pattern is consistent across industries and use cases.

Three Root Causes

1. The Trust Gap

AI is running into serious hurdles even in the world of developers. There is a cost when tools don't provide a reliable user experience. When AI tools break, are inconsistent, or return too much slop, no amount of prompt engineering or agentic magic will overcome lagging trust and the high costs of engagement.

Questions plague adoption:

• What can we safely enter into context windows?
• How do we validate AI outputs in high-stakes domains like legal, medical, and financial services?
• What accountability frameworks apply when AI produces errors?

The slop problem creates a vicious cycle: when AI breaks or produces inconsistent results, developer collaboration suffers, and impressive solo accomplishments may not scale to teams. No amount of technical sophistication can recover from broken trust.

2. Data Fragmentation

Many organizations are finding that their internal data is too fragmented or messy for AI to use reliably. Connecting AI with legacy infrastructure is often more expensive than the AI software itself.

This problem has deep roots in Agile philosophy. Agile conditioned us to maximize work for short-term investment, creating a lossy approach to information and documentation. The marginal value of documentation was deemed low, and capturing the intent behind why changes were made was considered even lower. Product managers focused on the next release rather than the past.

The result: data wastelands. "A wiki is where information goes to die."

AI tools are particularly good at creating value from data. Given the product development philosophy influenced by Agile, there should be little surprise that AI is not attracting paying customers. Without data, there is no value proposition.

3. Role Confusion

Outside of software development, AI diffusion is not delivering on the promise to provide systemic core business value. Experience is sparse on how to calculate ROI. Staff require guidance toward cultural adaptation as well as coaching and clarity about their roles along the way.

The fundamental questions remain unanswered:

• Where does AI fit in existing workflows?
• Who can direct and oversee AI operations?
• How do we address fears about job displacement?
• What happens when AI lowers the cost of cognitive tasks but creates new bottlenecks in human review?

CEOs adopt AI-first initiatives with savvy investor outreach but unclear expectations. The force to conform is strong, especially with actions that create soundbites to please investors. "Reduced unnecessary headcount by adopting AI" is currently in vogue, even when the productivity gains don't materialize.

Why This Feels Familiar

These challenges mirror exactly what we experienced during early Agile adoption:

• Trust issues with new tools and processes
• Data infrastructure problems
• Role confusion and cultural resistance
• CEO pressure for quick wins to demonstrate value to investors

We've seen this all before. The question is whether we've learned enough to avoid repeating the same mistakes.

What Agile Taught Us: The Evolution from Iteration to Data-First

The Agile Philosophy and Its Blindspot

All flavors of Agile evolved to protect the most expensive and time-consuming aspects of product development‚ generally building and testing a product. Agile introduced team-based rituals to factor product requirements into smaller parts and then apply a dynamic "measure twice, cut once" approach to implementation.

What Agile Optimized For:

• Protecting expensive resources: development time and testing cycles
• Adapting requirements within sprints based on feedback
• Team collaboration and iterative delivery

What Agile Deprioritized:

• Documentation ("low marginal value")
• Capturing intent behind decisions ("even lower value")
• Data versioning and curation
• Cross-functional knowledge sharing beyond immediate sprint needs

By design, feature requirements and use cases evolved within sprints, and it took tremendous work to coordinate and sequence integration, validation, and documentation. Market pressures drove teams to spend time on work that provided immediate value in support of sprint goals.

Agile never solved the core challenge of curating and versioning data related to the product development cycle. Good GitFlow and DevOps mitigated this data loss to some extent, but even the clear benefits of automation weren't enough to support maintaining test cases over time.

The Inflection Point: When Automation Changed Everything

Prior to AI, the previous "big shift" was toward automation. QA morphed into Test Automation, which became part of automated DevOps pipelines with change control and deployment. This introduced one problem that ruled them all: automation requires clear requirements against which to test.

The Challenges That Emerged (circa 2010-2021):

Teams from startups to global power companies had to adjust to a much faster develop-and-deploy cycle. Just-in-time changes made during refinement, in-sprint, and in feature branches required integration with other teams' work.

Prior to automation, the relatively slow manual merge process provided time for PM review, "enough" testing, and multiple attempts at deployment‚ ideally with some trailing initiative to create documentation and occasionally give Customer Support insights into changes and issues.

With automation, that buffer disappeared. The costs of production suddenly valued accurate data and documentation. To support automation, Agile teams had to spend time on work that provided longer-term value: versioned requirements, documentation, and validated test coverage.

The Failed First Response

Very few focused on how role-based tribal knowledge, experience, and wisdom were the key to successful digital transformation. The initial response was to include everyone: Agile teams adjusted by including members from design teams as well as customer support, finance, and marketing. Stakeholders were invited into the fold.

Why It Failed:

This helped surface a few issues but more generally increased overhead, slowed development, and made it more difficult for team members to understand what was going on. People are not very good at understanding their own roles in complex systems.

The Solution That Worked: Role-Based Sources of Truth

The next iteration of data-first Agile resolved most of the problems. Representatives from Product Management, Design, Development, Validation, Deployment, and other stakeholders were still included in teams‚ but they were now accountable for being the sources of truth for their respective roles.

Team Contracts with SLAs:

• If a requirement was unclear or inconsistent, the design team was required to solve the problem
• Changes were reflected in versioned design specifications and integration tests
• Documentation was updated before a change was considered done
• Customer support and marketing were involved in the business decision to deploy features

Each Role as Source of Truth:

• Product Management: Requirements and business context
• Design: User flows and specifications
• Development: Implementation and technical decisions
• Validation: Test coverage and acceptance criteria
• Deployment: Release management and infrastructure

Building Trust Through Success

The companies that successfully incorporated automation and DevOps pipelines focused on working with the people in each role. They understood what each role needed to gain trust in the rest of the system and, just as importantly, secured critical buy-in for taking on a few small tasks and processes in addition to existing responsibilities.

A problem with this type of distributed model to increase productivity is that everyone has to trust that it works. The most effective way to build trust moving to a data-focused Agile process is success.

The Timeline:

In general, it took three to six months for teams to look back and wonder how they did things any other way. Successful feature launches involved Marketing and Finance. Customer Service had the new user flows and issues in hand prior to release. Documentation always reflected the current version.

Stakeholders provided more autonomy. Customers were happier. CEOs were rewarded by investors.

Key Lessons for AI Adoption

1. Role clarity matters more than tools - The best AI won't fix unclear responsibilities
2. Data pipelines require buy-in from everyone - One broken link breaks the chain
3. Trust takes time but not decades - 3-6 months for process adoption, 2-3 years for full cultural change
4. Success breeds adoption - Small wins matter more than grand visions
5. Incremental role changes work better than wholesale transformation

Why AI Is Different (And Why the Fundamentals Remain the Same)

The Accelerated Timeline

Agile adoption played out over twenty-plus years across industries, with each organization learning painful lessons independently. Digital transformations were decades-long journeys, with shiny new approaches emerging every few years to encourage CEO engagement and cajole the laggards.

AI adoption is happening at a fundamentally different pace. The growing pains and failures appear more quickly and publicly. The successes are difficult to quantify but far easier than the early days of Agile. Market pressure, competitive advantage, and investor expectations compress decision cycles from years to months.

Critical difference: Delay has existential costs in the AI era. Organizations that fall behind may not have time to catch up.

The Expanded Scope

The rate of AI adoption is faster than Agile and across a more broad range of industry. Agile primarily focused on software development and gradually diffused to other business verticals. AI represents simultaneous adoption across finance, healthcare, legal, marketing, and operations.

More diverse use cases mean more complex failure modes. The variants and markets for AI tools are in infancy for both frontier models and how to use them. However, AI-washing already provides CEOs leverage to rationalize massive capital investments and layoffs.

The Dynamic Bottleneck Problem

This is where AI fundamentally differs from Agile in a way that demands new thinking.

Agile's Assumption:

Development and testing are the expensive bottlenecks. Build team rituals and processes to optimize around protecting these resources.

AI's Reality:

AI lowers the cost of cognitive tasks that can be expressed as language. The bottleneck moves dynamically depending on which tasks AI can handle effectively.

Examples of Shifting Bottlenecks:

• Code generation: Development is no longer the primary constraint as code review, integration testing, and technical validation become bottlenecks
• Content creation: Writing is cheap and fast, but editorial judgment, brand consistency, and strategic messaging require more human oversight
• Data analysis: Generating insights happens quickly, but validating accuracy, determining business implications, and making decisions based on analysis require expertise
• Customer support: Response generation is instant, but empathy, escalation judgment, complex problem-solving, and relationship management can't be automated

The Catch-22:

The bottleneck for adopting AI is not incremental improvements to frontier models. No matter the hype, AI does not have domain experience, intuition, and wisdom to divine human intent, ask the right questions, or reward innovation.

The costs of human labor in data preparation and cleaning far eclipse even the costs of training, which in itself is magnitudes more costly in compute and intellectual effort than improving fine-tuning, context window expansion, and RAG.

Without clean, structured data, AI can't deliver value. But without AI proving value, organizations won't invest in the data infrastructure needed to make it work.

The Similarities That Matter

Despite these differences, the fundamental problem is identical to what we faced with Agile.

Both require:

• Clear role definitions that adapt to new production economics
• Data pipelines that capture intent and context, not just output
• Trust-building through incremental success
• Cultural change that respects human capabilities rather than trying to replace them

The human problems remain constant:

• Skills gaps and training needs
• Cultural resistance to change
• CEO pressure for quick wins and investor optics
• Fear of job displacement
• Difficulty measuring ROI during transition periods

What's Genuinely New

Challenges Specific to AI:

• Opacity: AI decision-making is harder to audit than human or rule-based decisions
• Reliability variance: Performance varies wildly by domain and task type
• Context limitations: How much information can be safely and effectively provided?
• Hallucinations and slop: AI confidently produces wrong answers
• Rapid evolution: Best practices for current models may not apply to next-generation models

Why Traditional Change Management Fails

Standard change management approaches assume:

• Stable tools with predictable capabilities
• Clear best practices emerging from early adopters
• ROI calculations based on established use cases

AI reality demands different thinking:

• Tools and capabilities evolving monthly
• Best practices still being discovered through experimentation
• ROI dependent on organization-specific data quality and role adaptation

We can't wait for someone else to figure it out. Each organization needs a framework that co-evolves with AI capabilities.

The World Model Approach: Co-Evolving with AI

What Is a World Model?

A world model is a dynamic, shared representation of how intent, roles, data, and validation interact within your product development cycle‚ designed to adapt as AI changes the economics of production.

This is not another framework to learn. It's an approach to thinking about your existing roles and processes through a lens that makes AI integration natural rather than disruptive.

The Core Concept:

In AI research, world models refer to internal representations that systems build to model how states change over time in response to specific actions. These models enable AI to predict outcomes and plan effectively.

In business, world models serve a parallel function: they create explicit, shared representations of how decisions, data, and outcomes connect across roles. Just as AI builds internal representations of patterns, organizations need external representations of their knowledge flows that both humans and AI can navigate.

Why "World Models" and Not Just "Process Documentation":

The term emphasizes that these representations:

• Are dynamic (they evolve as capabilities and bottlenecks change)
• Are shared (everyone can see how the pieces fit together)
• Model change (they capture not just what is, but how things transform)
• Enable co-evolution between human practices and AI capabilities

The Three Layers of a World Model

Layer 1: Intent Mapping

This layer captures the "why" behind work:

• What problem are we solving? (Product Management domain)
• What does success look like? (Design and Business domains)
• What constraints matter? (Technical, regulatory, resource domains)

AI's role in this layer: Help articulate and validate intent through natural language interaction. Surface conflicts or ambiguities in stated goals.

Human's role in this layer: Provide domain expertise, business intuition, and strategic wisdom that AI lacks. Make judgment calls about priorities and tradeoffs.

Layer 2: Role-Based Data Pipelines

This layer defines how work flows between roles:

• Each role maintains its source of truth
• Data flows between roles with clear handoffs and SLAs
• Changes are versioned with context about why, not just what
• Dependencies and blockers are explicit

AI's role in this layer: Automate data transformation between formats. Flag inconsistencies. Suggest connections between related information.

Human's role in this layer: Make judgment calls when data conflicts. Resolve ambiguities. Validate that AI suggestions make sense in context.

Layer 3: Continuous Validation

This layer ensures quality at every stage:

• Are we building the right thing? (Product validation)
• Are we building it right? (Technical validation)
• Can we support what we built? (Operational validation)

AI's role in this layer: Pattern recognition across large datasets. Identify anomalies and edge cases. Suggest test scenarios based on historical issues.

Human's role in this layer: Contextual judgment about which issues matter most. Risk assessment for edge cases. Stakeholder communication about tradeoffs.

Why This Enables AI Adoption

Addresses the Trust Gap:

Clear accountability at each step means AI suggestions can be traced back to source data and validated by the responsible human role. There are explicit checkpoints at critical junctures where humans review and approve AI contributions.

Trust builds gradually as teams see AI catching issues they would have missed while also learning when to override AI suggestions based on context it doesn't have.

Solves the Data Problem:

When each role sees immediate utility from maintaining their source of truth, data quality becomes a natural priority rather than an afterthought. Documentation becomes a byproduct of the work rather than additional overhead.

The data pipelines serve humans first: clearer handoffs, fewer misunderstandings, less rework. AI benefits second by having clean, contextualized data to learn from.

Clarifies Roles:

AI handles tasks expressible as language and pattern recognition. Humans focus on intent, judgment, and validation. As AI capabilities grow, roles evolve rather than disappear.

The question shifts from "will AI replace this role?" to "how does this role's focus change as AI handles routine cognitive tasks?"

Provides an Evolutionary Path:

No "big bang" transformation required. Start with current roles and minimal process additions. Add AI tools where they provide clear value. Expand as trust and data quality improve.

Teams can adopt at human pace because the framework anticipates that AI capabilities will continue evolving. The goal is not to optimize for today's AI but to create structures that adapt as AI improves.

How This Differs from Other Approaches

vs. AI-First Transformation:

AI-first approaches often assume AI can replace complex human judgment and push organizations to reorganize around AI capabilities. This creates resistance and often fails when AI can't deliver on promises.

World models start with humans and add AI incrementally. The focus is on amplifying existing strengths rather than wholesale replacement.

vs. Traditional Change Management:

Traditional change management assumes you're moving from a known current state to a known future state and that the tools are relatively stable.

World models are designed for dynamic capabilities. They emphasize co-evolution rather than transformation to a fixed end-state and include built-in adaptation mechanisms.

vs. Data Governance Initiatives:

Data governance typically focuses on compliance, access control, and preventing misuse. It's often seen as overhead that slows teams down.

World models focus on active data utility in daily workflows. They connect data quality directly to productivity gains, making maintenance feel valuable rather than burdensome.

The Feedback Loop

World models improve over time through a continuous cycle:

1. Explicit representation of current state (roles, data flows, workflows)
2. AI interaction reveals gaps, inefficiencies, and opportunities
3. Human refinement based on what actually works in practice
4. Update the model with new patterns and improved practices
5. Repeat as AI capabilities and business needs evolve

This creates institutional knowledge that:

• Survives role transitions and employee turnover
• Can be queried by both humans and AI
• Evolves with your organization's unique context
• Becomes increasingly valuable over time as it captures more experience

The world model becomes a living asset that reflects not just how work is done but why it's done that way‚ the accumulated wisdom that makes your organization effective.

The Difference Between This and the Last Twenty Years

Agile adoption was painful because we didn't know where it was going. We experimented, failed, learned slowly, and gradually converged on practices that worked.

We do know where AI adoption needs to go now. We've already learned the hard lessons:

• Role clarity matters more than sophisticated tools
• Data pipelines create value for humans first, AI second
• Trust comes from demonstrated success, not executive mandates
• Incremental change beats big-bang transformation
• People with domain expertise can't be replaced by prompts‚ but they can be amplified

The Promise of World Models

You don't need perfect AI. You don't need complete data. You don't need to transform everything at once.

You need a shared understanding of how work flows through your organization and a framework that adapts as AI changes what's possible.

Start small. Measure honestly. Evolve constantly.

The companies that will thrive with AI aren't the ones with the fanciest models or the most ambitious transformation programs.

They're the ones who figured out how to make AI and humans genuinely better together‚ not by replacing people with prompts, but by building world models that amplify human judgment with machine capability.

You already have the roles. You already have the people. You already have the domain knowledge.

Now you have a roadmap to put them together in a way that actually works.

Next Steps

Ready to start?

1. Map your current state (Weeks 1-2): Identify where your sources of truth actually live
2. Find your bottleneck (Weeks 3-4): Track where work waits in your current process
3. Pick one pipeline (Month 2): Choose a high-value workflow to optimize first

Need deeper guidance?

Each section of this summary will expand into a full chapter with:

• Detailed examples from specific industries
• Templates and tools for each role
• Case studies of successful implementations
• Common pitfalls and how to avoid them

---

About This Work

This summary draws on ten years of experience guiding product development teams through the exact role and process transformations needed to adopt AI successfully. The approach, rooted in Bespoke Agile principles developed since 2016, anticipated the data-first, role-based solutions that AI adoption requires.

For organizations ready to navigate AI adoption without repeating Agile's costly mistakes, consulting and full-time engagement opportunities are available.

Learn more: bespokeagile.com

Your Roadmap: Implementation by Role

Before You Start: Map Your Current State

Weeks 1-2: Identify Your Sources of Truth

For each role in your product development cycle, ask:

• Where does authoritative information currently live? (Often: someone's head, scattered documents, tribal knowledge)
• What decisions does this role own?
• What information do they need from other roles to do their work?
• What information do other roles need from them?

Tools: Use a simple spreadsheet or diagram. Don't overcomplicate this step.

Output: A visual map of information flows and dependencies that everyone can understand.

Weeks 3-4: Find Your Current Bottleneck

AI changes production economics. Where is your constraint NOW‚ not where it was two years ago?

• Is it still development time? (Unlikely if you're using any AI coding tools)
• Is it code review and integration?
• Is it requirements clarity and product decisions?
• Is it validation and testing?
• Is it deployment and infrastructure?
• Is it business decision-making and stakeholder alignment?

Critical insight: If you optimize for the wrong bottleneck, AI won't help and might actively hurt productivity.

Method: Track where work waits in queue. Time waiting reveals bottlenecks more accurately than subjective assessments.

For Individual Contributors

Month 1: Add Intent Documentation

What to change: When you complete a task, spend 2-5 minutes capturing WHY you made key decisions.

Developer examples:

• "Chose library X over Y because it handles edge case Z that we've seen in production"
• "Refactored this section to reduce coupling with authentication system for future flexibility"

Designer examples:

• "Simplified this flow because user testing showed confusion at step 3"
• "Color choice balances accessibility requirements with brand consistency standards"

Product Manager examples:

• "Prioritized Feature A over B due to customer requests from top 3 enterprise clients"
• "This requirement intentionally leaves flexibility for future third-party integrations"

Why this matters:

• AI can learn from your reasoning, not just your output
• Future you (or your replacement) understands the context when changes are needed
• You're building the dataset for AI to provide actually useful suggestions rather than generic patterns

What to expect:

• First 2 weeks: Feels like overhead. You'll question whether it's worth the time.
• Weeks 3-4: Becomes habitual. You find yourself thinking more clearly about decisions.
• Months 2-3: You start benefiting when AI can reference this context in its suggestions.

Month 2-3: Use AI to Amplify Your Work

Now that you're documenting intent, you can use AI more effectively:

• Use AI to draft documentation based on your decision logs
• Ask AI to identify patterns in your past decisions
• Have AI suggest edge cases based on your historical context
• Generate test cases from your implementation notes

The critical difference: AI suggestions are now grounded in YOUR domain knowledge and decision-making patterns, not just generic best practices.

Month 4-6: Validate and Refine

Close the loop on what's working:

• When AI suggestions work well: Note why they were helpful
• When AI suggestions fail: Note what context was missing
• Update your intent documentation with these learnings
• Share successful patterns with your team

Success indicator: You're spending less time on routine cognitive tasks and more time on complex judgment calls that actually require your expertise.

For Managers (Team Leads, Engineering Managers, Design Leads)

Month 1: Establish Role-Based SLAs

Create simple agreements between roles that make expectations explicit.

Example SLA: Design‚ Development

Design provides:

• Mockups, user flows, edge case specifications
• Within 2 business days of development request
• Format: Figma files + written specs in [agreed tool]

Development provides:

• Technical feasibility feedback
• Within 1 business day of design proposal
• Format: Written assessment with alternatives if original design isn't feasible

Example SLA: Product‚ Validation

Product provides:

• Acceptance criteria and success metrics
• Before development work begins on a feature
• Format: Structured template in [agreed tool]

Validation provides:

• Test coverage report and identified gaps
• Within 1 sprint of feature completion
• Format: Dashboard link + written summary of risks

Why SLAs matter:

• Makes implicit expectations explicit, reducing friction
• Creates accountability without creating blame
• Provides clear targets for what AI could automate
• Reveals where processes actually break down in practice

Month 2-3: Identify High-Value Data Pipelines

Pick ONE pipeline to optimize first. Don't try to fix everything at once.

Example: Requirements‚ Development‚ Validation

Current state (typical):

• Requirements exist in meeting notes, Slack messages, PM's head
• Development interprets requirements during sprint planning
• Validation writes tests based on implemented code
• Misalignment discovered late in the process or after deployment

Optimized with world model approach:

• Requirements captured in structured template with intent documented
• AI suggests technical implications and potential edge cases
• Development references structured requirements + documented intent
• AI generates initial test cases directly from requirements
• Validation refines AI-generated tests with domain knowledge
• Changes to requirements automatically flag affected tests and implementations

Measure before and after:

• Number of rework cycles (requirements changes discovered mid-sprint)
• Validation cycles (bugs found in testing vs. production)
• Time from clear requirement to validated, deployable feature

Month 4-6: Pilot AI Tools Within Established Pipelines

Only after you have clear role responsibilities and data flowing between them should you introduce AI tools strategically.

For requirements pipeline:

• AI summarizes customer feedback into structured format
• AI identifies conflicting requirements across feature requests
• AI suggests acceptance criteria based on similar past features

For code review pipeline:

• AI flags potential security vulnerabilities
• AI checks consistency with established coding standards
• AI suggests test coverage gaps based on code changes

Critical rule: AI suggestions must always be validated by the accountable human role. No auto-merge. No blind acceptance. Humans remain responsible for outcomes.

Month 7-12: Expand Based on Success

What worked in your pilot:

• Identify specific AI capabilities that consistently saved time without introducing errors
• Document the pattern: task type, AI tool used, validation method, success rate
• Replicate to similar workflows across other teams

What didn't work:

• Did AI lack necessary context? Fix: Improve data pipeline to provide context
• Did AI produce too much slop? Fix: Try different tool or keep human-only for now
• Did validation take longer than doing it manually? Fix: This workflow isn't ready for AI yet

Success indicators:

• Team reports higher quality output in less time
• Rework cycles decreased measurably
• AI suggestions accepted more than 50% of the time
• Team actively requests more AI integration (rather than tolerating mandated tools)

For Executives (Directors, VPs, C-Suite)

Months 1-3: The Honest ROI Conversation

Stop AI-washing. Start measuring what actually matters.

Instead of: "We're AI-first now" (this means nothing to customers or employees)

Measure these specific outcomes:

• Time saved on specific, repeatable tasks (document generation, code reviews, data analysis)
• Quality improvement: Reduced rework, faster validation, fewer production issues
• Bottleneck shifts: Where is work waiting now versus six months ago?
• Team sentiment: Are people using AI tools voluntarily or under duress? Are they requesting more capabilities?

Red flags you're in a J-curve decline:

• Productivity metrics actually dropping after AI introduction
• Team spending more time correcting AI output than previous manual processes took
• AI tool adoption declining after initial enthusiasm
• Increased errors reaching customers despite AI "quality checks"

Green flags you're on the right track:

• Specific workflows showing measurable, sustained improvement
• Teams adapting tools to their needs (not just using out-of-the-box configurations)
• Data quality improving because people see value in documentation
• Cross-functional coordination getting easier and requiring fewer meetings

Months 4-6: Investment Priorities

Reframe capital allocation around what actually drives AI success.

High ROI (do first):

1. Data infrastructure: Making internal data clean, accessible, and reliable
2. Role clarity workshops: Helping teams define sources of truth and SLAs
3. Training on world model approach: Not generic "AI literacy" but specific workflows
4. Pilot programs in high-value workflows with clear success metrics

Medium ROI (do after pilots succeed):

1. Expanding AI tools to more workflows based on pilot learnings
2. Custom AI integrations with your specific internal systems
3. Advanced capabilities like fine-tuning or specialized models

Low ROI (avoid for now):

1. Wholesale platform replacements before proving value with existing tools
2. AI tools without clear, specific use cases tied to actual workflows
3. "AI transformation consultants" selling generic frameworks
4. Layoffs based on projected AI efficiency gains (you'll end up rehiring)

The critical lesson from companies like Salesforce: You need experienced people whose judgment can compensate for current AI limitations. Over-optimize for headcount reduction and you'll crater productivity while destroying institutional knowledge.

Months 7-12: Cultural Change Timeline

Set realistic expectations with your organization.

What to communicate:

• 3-6 months: Teams will trust the process and see value in new workflows
• 6-12 months: Data pipelines become habitual, AI tools integrate naturally
• 12-18 months: Measurable productivity gains and reduced time-to-market become evident
• 18-24 months: Competitive advantage from institutional knowledge captured in world models

Warning: Demanding faster results will kill trust and create performative adoption where teams claim to use AI but quietly revert to old methods to actually get work done.

Your role as executive:

• Communicate clearly: Why this matters, what success looks like, realistic timeline
• Buffer pressure: Protect teams from quarterly demands during transition period
• Celebrate progress: Small wins, specific improvements, team innovations
• Model the behavior: Use world model thinking in your own strategic work

Success story to aim for at Month 12:

"Our product releases have 40% fewer post-launch issues. Customer Support receives release notes and known issues before deployment instead of discovering problems through customer complaints. Marketing launches coordinated campaigns aligned with feature releases. Development team spends less time in alignment meetings and more time building because requirements are clear and documented. And we've captured institutional knowledge that makes onboarding new team members three times faster than before."

The Universal Implementation Pattern

This pattern works across all roles and organization sizes.

Phase 1: Map (Weeks 1-4)

• Current sources of truth (where authoritative information actually lives)
• Information flows (who needs what from whom, when, and why)
• Current bottlenecks (where work consistently waits)
• Success metrics (how we'll know if this is working)

Phase 2: Pilot (Months 2-4)

• Choose ONE high-value data pipeline to optimize
• Define clear role-based SLAs for that pipeline
• Add minimal tasks to each role (intent documentation, handoff clarity)
• Measure baseline performance‚ implement changes‚ measure improvement

Phase 3: Validate (Months 4-6)

Answer these questions with data:

• Did rework decrease? By how much?
• Did validation cycles shorten? What's the time savings?
• Did stakeholder confidence increase? How do we know?
• Are people actually using the new process or working around it?

Phase 4: Introduce AI (Months 5-7)

Critical: Only AFTER the data pipeline is working with humans should you add AI.

• Start with low-risk, high-value tasks that have clear validation
• Ensure AI suggestions are always validated by accountable humans
• Measure time saved versus validation overhead
• Be willing to remove AI from tasks where it's not adding value

Phase 5: Expand (Months 7-12)

• Replicate successful patterns to other data pipelines
• Remove AI from workflows where it's creating more work than it saves
• Deepen AI integration in areas where it's proving consistently valuable
• Update your world model based on what's actually working

Phase 6: Evolve (Ongoing)

• As AI capabilities improve, revisit what's possible in workflows that weren't ready
• As bottlenecks shift due to AI adoption, adapt role responsibilities accordingly
• As teams learn and share knowledge, capture new patterns in the world model
• As business priorities change, update what's considered high-value

Conclusion: What Success Looks Like

Month 6: Early Wins

Your team conversations change in noticeable ways:

• "The AI caught three edge cases in the requirements that we would have discovered in production"
• "I spent 30 minutes on documentation this sprint and it saved us four hours of rework later"
• "Customer Support knew about the changes and potential issues before we deployed"
• Fewer hours in meetings clarifying requirements because they're already clearly documented
• Designers and developers resolving questions through structured documentation rather than Slack messages

Year 1: Transformation Underway

Measurable improvements accumulate:

• Feature delivery time reduced by 20-30% with higher quality
• Post-launch defects down 30-40%
• Cross-functional coordination smoother and requiring less synchronous time
• Team autonomy increasing as roles and expectations become clearer
• AI tools naturally integrated into 60-70% of workflows
• New team members onboarding faster because knowledge is documented

Year 3: Competitive Advantage

What you've built becomes genuinely differentiating:

• A living knowledge base that captures WHY decisions were made, not just what was decided
• Institutional knowledge that survives employee turnover and role changes
• AI systems that understand your specific domain, context, and decision-making patterns
• Roles that co-evolve with AI capabilities rather than being disrupted by them
• A culture of continuous adaptation that welcomes capability improvements
• Speed and quality advantages that competitors can't easily replicate

Swarms, Models, and Waves

Creating a Rational AI Stack for Adaptive Agile

Article 2 of 3: From World Models to Operational Architecture

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. It argued 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. This AI stack is emergent when product models, functional team models, and information models become the basis of product development.

Note: 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.

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 cross-communications across agents. 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 known maps provide the local framework, and an agent can read 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.

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."