White paper · AI delivery

Agile Delivery in the AI Era

The TomorrowX platform-led production system for turning business intent into trusted AI capability at enterprise scale.

TomorrowX Research · Online edition

Contributors

TomorrowX Research, with perspectives from Arie van Bennekum — co-author of the Agile Manifesto, international authority on Agile transformation and adviser to TomorrowX. The paper extends ideas discussed in the TomorrowX conversation on composable software into the delivery requirements of the AI era.

Abstract

Business transformation begins before software development. It begins when an organisation identifies a need and submits a front door request describing the intended change, the outcome required and the systems believed to be affected.

That request usually enters a long enterprise process of discovery, prioritisation, architecture, development, integration, testing, assurance and deployment. Agile has shortened parts of this process, but the original business intent must still be translated repeatedly before it can affect the operating environment. Business, data, risk and operational specialists commonly participate through documents, backlogs and approval gates, while scarce engineering resources remain responsible for turning their intent into working technology.

Artificial intelligence can accelerate individual tasks, including analysis and code production. But producing code faster does not create a scalable enterprise delivery system. Code must still be understood, reviewed, integrated, secured, audited, approved, deployed and operated. Increasing the rate of code production can therefore move the bottleneck into assurance and production rather than remove it.

This paper presents a broader model for Agile delivery in the AI era. Data Mediation connects the original business requirement to the live data journey through which the outcome must occur. A Proof of Capability and Value creates a bounded working solution and produces evidence before a larger transformation commitment is made. The Composable Agentic Platform then connects reusable functional capability, non-functional requirements, proof, deployment, operation and reuse through one governed production lifecycle.

The result is a platform-led delivery system for AI, cloud, interoperability and connected enterprise capability. It is adaptable without being dependent on a particular model, cloud, application or embedded engineering team. The customer retains authority over its data, systems, models, actions and deployment environment.

AI can produce code faster. A production system is required to deliver trusted capability faster.

1. Transformation starts at the front door

Most enterprise transformation begins with a front door request. The name varies between organisations, but the pattern is familiar: a business sponsor submits a custom document describing a need for change and asks the enterprise delivery system to assess, prioritise and implement it.

The request may seek to improve a customer journey, meet a regulatory obligation, introduce AI into an operating process, connect incompatible systems, reduce cost, strengthen cyber control or support a migration. It commonly includes an expected outcome, known systems, affected stakeholders, urgency, dependencies, risks and an initial view of benefits.

The front door is necessary. It gives the organisation a way to express demand and make investment decisions. But it captures an interpretation of the operating environment, not the operating environment itself.

The document cannot by itself show which data is moving, where it moves, which systems actually participate, how exceptions occur, what users do in practice or whether the proposed change will produce the intended outcome. Those questions begin another sequence of discovery and translation.

A typical request may pass through business analysis, architecture, security, privacy, finance, delivery planning, application teams, integration teams, testing, assurance and operations. Each group contributes necessary expertise. Each transition also creates delay and an opportunity for the original intent to be altered, narrowed or separated from the evidence needed to evaluate it.

The structural problem is therefore not the front door document. It is the distance between the business need and a working, observable outcome.

The front door captures intent. Agile delivery in the AI era must connect that intent to operational evidence before the organisation commits to transformation at scale.

2. Agile’s unfinished promise

Agile was created in response to slow, document-heavy software delivery. It brought people closer to working software, shortened feedback cycles and encouraged teams to respond to evidence rather than defend a fixed plan.

Yet many enterprise implementations confined Agile to the development team. The surrounding delivery system continued to operate through front door documents, portfolio queues, architecture hand-offs, specialist engineering teams, separate assurance processes and operational handover.

“The biggest mistake that we make is to think that Agile is for development.”

Arie van Bennekum, co-author of the Agile Manifesto and adviser to TomorrowX

Arie’s broader definition is more relevant to enterprise AI than any particular ceremony or scaling framework:

“Development is having the right people at the right time talking about the right things and getting it done.”

The right people in an AI-enabled transformation may include business and product owners, customers, data and process analysts, architects, engineers, security, privacy, legal, compliance, finance, service management and operations. Their participation cannot be reduced to producing requirements or approving a completed design.

They need a shared working medium through which their knowledge becomes part of the solution. They need to see the data journey, test the business outcome, express controls, observe results and refine the capability together.

Agile is the collaborative operating principle. It still requires an architecture through which collaboration can influence the live outcome.

3. The enterprise delivery bottleneck is not code

AI-assisted software development can improve the productivity of an individual developer or a bounded project team. It can generate candidate code, explain unfamiliar code, create tests, draft documentation and accelerate troubleshooting.

There is room for these tools, but their benefits have been demonstrated most clearly at the level of a person or a project. They have not yet established an equivalent, repeatable enterprise production model spanning requirement capture, assurance, integration, deployment, operation and reuse.

In a complex organisation, much of the elapsed time between a business request and a production outcome is not spent typing code. It is spent understanding the estate, locating data, resolving ownership, agreeing controls, integrating systems, validating non-functional requirements, preparing evidence, securing approval and establishing operational support.

Generating code more quickly leaves these constraints in place. It may increase pressure on the functions that must understand, review, test, secure and audit the new material before it can enter production.

When code production accelerates but assurance does not, the bottleneck moves. It does not disappear.

The more scalable alternative is to reduce how much bespoke code must be created and reviewed for each outcome. Reusable, proven capability allows an Agile team to begin from what the enterprise already knows rather than restarting from a blank repository.

QuestionAI-assisted codingTomorrowX platform-led delivery
Primary accelerationThe individual or project produces code fasterThe enterprise moves from requirement to governed operation faster
Starting pointA new coding task or repositoryReusable protocols, controls, patterns, evidence and complete capabilities
Assurance burdenMore generated code must still be reviewed and testedProven elements retain explicit functional and non-functional requirements
Scaling unitDeveloper productivityTrusted capability that can be reused across teams and partners
Production outcomePotentially faster implementation inside the existing SDLCA repeatable production system spanning proof, deployment, operation and reuse

4. Data Mediation changes the first move

Conventional transformation normally begins by identifying the applications that must change. Data Mediation begins with the interaction through which the business outcome occurs.

A customer request, payment instruction, AI prompt, clinical exchange, security event or operational action moves between systems. That movement contains the data context, process context and workflow that the business requirement is attempting to influence.

Data Mediation makes this interaction observable and programmable. A mediation point deployed inside the customer’s environment can understand the protocol, data and surrounding context before the interaction completes. It can then observe, govern, transform, simulate or augment the journey without requiring every system on either side to be rewritten first.

Data context

Who or what initiated the interaction? What information is present? What systems and identities are involved? What happened immediately before? Which policy, obligation or customer expectation applies?

Process context

Where does the interaction sit within the broader business journey? Which conditions have already been met? What exceptions are possible? What downstream systems, people or obligations depend on the next decision?

Workflow and action

Should the interaction be allowed, denied, enriched, transformed, routed, simulated, presented for human approval or augmented with AI? What evidence must be retained, and what should happen if the new capability fails?

This creates a direct connection between the business requirement and the operating reality. The team can work from live context rather than relying only on system diagrams, interviews and historical documentation.

Data Mediation changes the first transformation question from “Which applications must we modify?” to “What must happen as this business interaction moves between them?”

5. From front door request to business evidence through the POCV

The Proof of Capability and Value is the evidence-producing extension of the front door.

A conventional intake process asks whether a proposed change should be prioritised and funded. The decision is commonly made from documents, estimates, assumptions and comparable programmes.

A Data Mediation-enabled intake process can ask a better question:

Can the organisation prove the outcome, operating controls and value before committing to the full transformation?

The POCV begins with a bounded business need. It identifies the relevant data journey, establishes the participating systems and stakeholders, defines the evidence required and creates a working capability in controlled scope.

The proof can establish:

  • whether the business requirement has been understood correctly
  • whether the necessary data and systems are available
  • whether the proposed workflow changes the business outcome
  • whether security, privacy, resilience, performance and other non-functional requirements can be met
  • whether AI contributes material value and under what boundaries
  • whether the solution can operate inside the customer’s chosen environment
  • whether the evidence supports scaling, revision or stopping

The POCV is therefore not a miniature implementation project. It is a decision instrument. It converts the front door request from a prediction about future value into an evidence-based decision about a working capability.

This also restores a central Agile principle: feedback from something real. Instead of completing months of analysis before the first meaningful learning occurs, the organisation can bring business, data, risk, technology and operational stakeholders around a bounded solution and its evidence.

Explore the TomorrowX Proof of Capability and Value.

6. CAP as the AI delivery production system

The Composable Agentic Platform is the production system through which Data Mediation solutions are defined, programmed, configured, proven, deployed, operated and reused.

The term production system is deliberate. CAP does not impose one fixed application pattern or a restricted catalogue of AI use cases. It provides a common lifecycle, runtime and evidence model while preserving the flexibility of general-purpose programming, customer-selected infrastructure and interchangeable intelligence.

This combines the repeatability of a platform with the adaptability usually associated with custom code.

Define and observe

Establish the business outcome, target data journey, operating boundaries, accountable stakeholders and evidence required. Observe representative interactions so the team understands actual protocols, messages, dependencies, volumes, exceptions and behaviour before deciding what should change.

Program

Program the functional requirements in the Editor. Compose reusable protocol capability, business rules, transformations, workflow, deterministic logic, probabilistic intelligence, human decisions and system actions. Create only what is specific to the problem.

Configure

Select and bind the non-functional requirements in the Console. Security, privacy, sovereignty, resilience, availability, performance, model policy, cost, audit, fail behaviour and operational ownership remain explicit rather than being rediscovered inside each project.

Prove

Test and simulate the complete capability under representative conditions. Prove the intended outcome, data access, model behaviour, policy enforcement, operating performance, cost, reversibility and evidence—not merely whether the code executes.

Deploy

Promote the governed capability through a repeatable mechanism into the customer’s approved environment. The Programmable Data Agent executes in the data path, close to the systems and security zones for which the customer remains accountable.

Operate

Carry the solution beyond go-live through probes, telemetry, management, repair, controlled evolution and eventual retirement. The work is not complete when a release enters production.

Reuse

Publish approved functional capability, non-functional profiles, deployment requirements and evidence for discovery and reuse. The next team begins from a stronger position because the previous outcome has become a governed enterprise asset.

CAP is not simply a development platform. It is an end-to-end production system for business transformation—from the first expression of need through proof, deployment, operation and reuse.

Explore the Composable Agentic Platform.

7. A new shape for the delivery team

Data Mediation and CAP do not remove engineering. They change where scarce engineering effort is concentrated and who can participate directly in creating a solution.

Traditional delivery often requires the person closest to the problem to describe it in a document. Business analysts translate the need. Architects interpret the estate. Engineers convert the interpretation into software. Risk, security and operations review the result through separate processes.

The earlier TomorrowX work in composable delivery exposed the cost of this chain. Regulatory intent could be converted into technical specifications, passed through analysis and development and returned months later in a form that no longer reflected what the original stakeholder meant.

With a programmable data journey and reusable platform capability, a broader group can work closer to the solution:

  • business analysts can connect the requirement to the intended outcome
  • data analysts can work with actual context, messages and patterns
  • process analysts can make workflow, decisions and exceptions explicit
  • risk, privacy and compliance specialists can express controls closer to their source
  • operations teams can define resilience, support and failure behaviour before deployment
  • customer-experience teams can test a real journey rather than a static representation

Architects and engineers remain essential. They establish platform patterns, protocols, security boundaries, performance, advanced capability and the response to difficult exceptions. But they no longer have to recreate the same integration and control mechanisms for every front door request.

Scarce engineers build and extend the production system. Business, data and process specialists use that system to solve more problems.

This is Arie’s definition of Agile made operational: the right people can work together on the same executable outcome rather than communicating through a sequence of hand-offs.

8. AI across the complete delivery system

AI makes this production system faster, but it is not the production system itself.

Its value is broader than code generation. Within explicit customer-defined boundaries, AI can help teams:

  • interpret the front door request and identify ambiguity
  • analyse observed interactions and discover process patterns
  • identify exceptions, missing context and unexpected dependencies
  • propose mappings, transformations or candidate workflow logic
  • assist analysts in composing reusable capability
  • generate test scenarios and simulation conditions
  • compare expected and observed outcomes
  • interpret POCV evidence and operational telemetry
  • recommend repair, optimisation or model-routing changes
  • identify capability that should be retained for reuse

These activities accelerate understanding, composition, proof and operation across the complete lifecycle. They do not transfer enterprise authority to the model.

The organisation still decides the outcome, permitted data, approved models, production boundaries, automated actions, cost limits, evidence requirements and conditions for rollback.

CAP can combine deterministic rules and probabilistic intelligence in the same data journey. AI can interpret, classify, recommend or generate. Deterministic controls can decide what data it receives, which actions are permitted, when human authority is required and what evidence must be created.

AI accelerates the production line. Data Mediation and CAP make the line governable, repeatable and ready for enterprise operation.

9. Adaptability without loss of choice or control

Enterprise AI delivery must remain adaptable. Models, clouds, regulatory obligations, system estates and business priorities will continue to change.

Adaptability cannot require the customer to surrender control to the current model vendor, cloud platform, application provider or delivery team.

Data Mediation separates enterprise authority from the source of intelligence. The model can change while the control architecture remains with the customer.

The customer retains control over:

  • where the capability runs
  • where data moves and what may leave the controlled environment
  • which models, providers and tools may participate
  • what information each model may receive
  • which systems an agent or AI capability may access
  • what actions may occur automatically
  • which decisions require human authority
  • how usage and cost are limited
  • what evidence is retained
  • how the capability is changed, withdrawn or replaced

This freedom is not only a commercial safeguard against lock-in. It is an architectural requirement for AI delivery at scale. Enterprise operating capability should not become inseparable from a model that may be replaced next year.

Models provide intelligence. Data Mediation provides controlled access to the data, systems and actions that make that intelligence useful.

10. Platform-led scale

Forward-deployed engineers can be valuable when an organisation is discovering a first-of-kind workflow, learning its constraints or establishing the first working pattern. The limitation is not the quality of the expertise. It is the unit through which the delivery model scales.

An FDE-led model scales through specialist headcount. A project-led model scales through additional programmes. A platform-led model scales through reusable capability, common controls, repeatable deployment and accumulated evidence.

TomorrowX changes the role of experts. They establish difficult patterns, encode capability, define boundaries, certify practices, support exceptional complexity and improve the production system. Customers and partners can then use that system to prove, deploy and operate more solutions inside their own environments.

Delivery modelWhat scalesWhat remains after delivery
Project-ledIndividual implementations and delivery activityProject code, documentation and another maintenance dependency
FDE-ledSpecialist teams embedded with customersA successful solution whose evolution may still depend on the experts
TomorrowX platform-ledReusable capability, controls, evidence and certified deliveryA customer-controlled capability that strengthens the starting point for the next outcome
Project-led delivery scales activity. FDE-led delivery scales specialists. TomorrowX platform-led delivery scales trusted capability.

CAP is standardised by platform and decentralised by deployment. A common programming, assurance and evidence model does not require one central runtime, one central delivery team or one model provider. Domains, customers and certified partners can own the capabilities and environments for which they are accountable.

11. Two decades toward this moment

The market increasingly recognises that model capability is not the same as enterprise AI delivery. The harder problem is connecting intelligence with operational data, existing systems, business workflow, assurance and customer-controlled action.

These questions are new to many organisations. They are not new to TomorrowX.

Since 2006, TomorrowX has focused on how valuable new capability can be introduced around the data exchanged by existing systems. The work progressed from application mediation and enterprise control into reusable components, composable architecture, distributed technologies, Connected Agile, Data Mediation and the Composable Agentic Platform.

Across that history, the recurring objective has remained consistent: enable the enterprise to change what happens next without forcing continuous disruption into the systems, platforms and infrastructure on which it already depends.

The current AI-delivery problem brings these lines of research together:

  • Data Mediation provides access to the live interaction
  • composable architecture provides reuse and adaptability
  • Agile provides collaboration and evidence-led learning
  • CAP provides the production lifecycle
  • the POCV provides the controlled entry point
  • AI provides additional intelligence across the solution and delivery system

TomorrowX’s position does not rest only on a view of how AI delivery should evolve. It rests on an existing platform, two decades of focused research and enterprise deployment experience.

TomorrowX is not adapting an AI coding tool to the enterprise transformation problem. It has built the production system through which Agile delivery can operate in the AI era.

Explore the TomorrowX research and deployment history.

12. The next iteration of Agile

The next iteration of Agile is not another ceremony, team topology or portfolio framework. It is the completion of Agile’s original promise across the whole business-transformation delivery system.

The people closest to the need must be able to connect a front door request with live data, working evidence and governed production. Functional intent, security, privacy, resilience, cost, model policy, deployment and operation must remain part of one lifecycle rather than being separated into sequential departments.

Arie has warned that organisations unable to get things done can end up “innovating backwards”: reimplementing old solutions because the delivery environment prevents them from innovating forward.

Using AI only to produce more conventional application code risks doing precisely that. New technology accelerates an old production system without changing its economics or constraints.

Data Mediation and CAP enable a different path. The team can work with the real journey, prove an outcome, reuse existing capability and retain customer authority throughout production.

“Maximising the work not done.”

Arie van Bennekum

In the AI era, this principle becomes a practical measure of delivery maturity:

  • code that did not need to be written
  • systems that did not need to be modified
  • integrations that did not need to be duplicated
  • requirements that did not need to be translated repeatedly
  • controls that did not need to be reconstructed for each project
  • specialist teams that did not need to remain embedded permanently
  • solutions that did not need to be rebuilt by the next business unit

The future of Agile is a continuous business-transformation capability through which the right people can move from need to evidence and from evidence to controlled operation.

Conclusion

Agile connected people around working software. Composable architecture connected reusable capability around business outcomes. Data Mediation connects business intent with the live data journey. CAP turns that connection into a governed production system.

It begins at the front door, before a conventional software requirement has been completed. It uses inline data context to understand the real process, the POCV to produce evidence, the platform to compose and assure capability, and customer-controlled deployment to carry the outcome into operation.

AI increases the speed and intelligence available across this system. It does not replace the need for the system. The enterprise still requires a repeatable way to govern data, connect systems, prove value, retain model choice, deploy safely and accumulate reusable capability.

This is the emerging requirement for Agile Delivery in the AI Era.

The right people collaborate around a real outcome.
The POCV produces business evidence.
AI accelerates the work.
Data Mediation governs the interaction.
CAP retains and scales the capability.
The customer retains control.

TomorrowX is defining and providing this platform-led production system for trusted AI delivery at enterprise scale.

Further listening

The Agile and composable-architecture perspectives in this paper continue a public TomorrowX discussion featuring Arie van Bennekum and enterprise practitioners.

Listen to Introduction to Composable Software on Apple Podcasts ↗

Listen on Spotify ↗

Next in Origins and foundations · Step 3 of 3

Foundational work, written for the present

Explore the complete collection of architectural and operating-model research behind the current work.

Read the next paper