The AI Delivery Platform Landscape in 2026

Part 11 of the Software Development in the Age of AI series

Part 2 of this series examined the state of AI software development in July 2026. It considered interactive assistants, repository-scale agents, asynchronous execution, multi-agent systems, orchestration and the point at which an emerging capability becomes reliable enough to influence an enterprise operating model.

This article begins from that foundation and asks how the parts fit together.

Software delivery begins before code is written and continues after it enters production. A business need has to be understood, its feasibility assessed, requirements established, dependencies identified, architecture considered, resources committed, work organised, changes implemented, evidence produced, releases controlled and operational results fed back into later decisions.

These activities are not inventions of modern software development. Any substantial human undertaking has required some version of scope, feasibility, resources, sequencing, deliverables, milestones, control and verification, whether raising a pyramid in ancient Egypt or replacing a core banking system today. The terminology changes, and the methods used within each activity may change considerably, but the underlying disciplines remain.

Something became muddled in software delivery over the past twenty years. Flexibility in how engineers perform technical work was increasingly confused with an absence of end-to-end planning. Requirements were reduced to stories, project progress was reduced to sprint movement, and the team’s internal method of organising its work became entangled with management control of the project.

AI exposes that confusion.

An agent may complete a well-defined technical task much faster than a human team could have completed it previously. It gains no benefit from story points, ceremonies or the administrative weight attached to a sprint. It requires accurate intent, relevant context, explicit constraints, suitable tools and clear evidence of completion. When those are missing, greater execution speed does not improve delivery. It increases the speed at which a plausible misunderstanding can become implemented software.

The AI delivery platform landscape should therefore not be judged only by the number of agents a vendor provides or the number of lifecycle activities into which it has inserted AI. It should be judged by the delivery model underneath the product. Which parts remain fit for purpose? Which parts are inherited assumptions? What does AI change? Where can the lifecycle be improved rather than merely automated?

The platform is larger than the agent

An AI delivery platform is not simply a coding agent, an editor, a work-management product or a pipeline with AI features added to it.

It includes the environment through which work is defined, the information humans and agents can access, the authority under which they act, the tools they may invoke, the evidence they produce, and the controls used to decide whether a result can proceed. It must also connect production behaviour back to the requirements, decisions, implementation and release evidence that produced it.

A coding agent may inspect a repository, propose a plan, edit several files, run commands, generate tests and prepare a pull request. None of those capabilities establishes that the change should have been made, that the requirement was accurate, that the available context was complete or that the tests prove the intended outcome.

The platform is the wider delivery system surrounding that execution.

This becomes more important when several agents participate. One may analyse a requirement, another may modify the code, another may produce tests, another may review the result, and another may control deployment or respond to a production incident. The organisation needs to know more than what each agent did in isolation. It needs to understand how their combined work remained connected to the original purpose of the change.

That requires continuity of intent, context, authority and evidence across the full lifecycle.

A reference model for software delivery

A useful assessment should begin with the functions required to deliver software rather than with the products currently available.

The lifecycle can be represented as:

Business purpose and project planning → feasibility and analysis → requirements and architecture → engineering work definition → human and agent execution → testing and assurance → release and deployment → production operations → feedback and learning

Several concerns extend across the entire sequence:

Context, identity, authority, permissions, policy, security, evidence, audit, cost, human judgement and accountability.

This is not an argument for a rigid sequence in which every decision is fixed before work begins. It is a statement of the activities that must be addressed.

Some may occur concurrently. Some may be revisited repeatedly. A prototype may deliberately use execution to test feasibility or discover what the requirement should become. A well-understood migration may allow large volumes of similar work to proceed through a repeatable method. An operational incident may require rapid analysis and remediation before the wider project plan is updated.

The method should reflect the nature of the work.

What should not happen is for an organisation to abandon necessary analysis and then claim that discovering the requirement during implementation is inherently Agile. Iteration is valuable when uncertainty is genuine and learning is the objective. It is not a substitute for understanding a deliverable that could have been analysed before execution began.

The reference model also separates two kinds of continuity.

Workflow continuity exists when one activity can trigger another. A work item can be assigned to an agent, the agent can create a branch, a pipeline can test it, and a deployment system can release it.

Reasoning and evidence continuity is more demanding. It requires the original outcome, assumptions, dependencies, constraints, uncertainty and accumulated assurance to remain connected as the work moves.

The current market is becoming increasingly capable of workflow continuity. It remains much less mature in reasoning and evidence continuity.

Delivery models before products

The same platform may be appropriate for one delivery mode and damaging in another. The landscape therefore needs to be understood in relation to the work being performed.

Delivery against a defined outcome

Where the business outcome is known, the project should contain an agreed scope, deliverables, requirements, dependencies, milestones, resource assumptions and evidence of completion.

This does not require a Gantt chart, and it does not make the work waterfall. A sequential list of requirements is not waterfall. Understanding what must be delivered, and in what broad order, is ordinary project planning.

The engineering team should decide how the requirements are implemented. It may create stories, tasks, technical specifications or an internal sub-plan. Those are mechanisms for organising execution. They are not the requirements themselves.

The sprint, where one is useful, sits below that level. The team examines the project requirements and wider targets, determines what can be completed within the next cycle and organises the technical work accordingly.

Prototyping and discovery

Prototyping operates differently because uncertainty is part of the assignment.

The organisation may not yet know whether an idea is feasible, which design will work, what users will accept or whether the problem has been understood correctly. The prototype exists to test assumptions and reduce uncertainty.

The plan should therefore define the hypotheses, questions, boundaries and learning outcomes rather than pretend that a final requirement already exists. The team can iterate, discard work and change direction as evidence emerges.

That is also Agile.

The mistake is treating all software delivery as though it were prototyping. A defined project does not become more Agile because the requirement is vague. Nor does a prototype become better managed because somebody writes artificial user stories for outcomes that remain unknown.

AI can accelerate both modes, but it requires different conditions. In defined delivery it needs accurate requirements and sufficient system context. In prototyping it needs explicit hypotheses, constraints and learning objectives.

A platform that treats every activity as a work item moving through the same prescribed workflow is already making an assumption about how software should be delivered. That assumption should be examined rather than accepted.

How Agile became confused with its machinery

Agile emerged from experienced software practitioners who understood that engineering teams needed room to exercise judgement. Its original values were a response to delivery models that attempted to prescribe too much of the technical method from above.

The underlying division of responsibility was straightforward. Project leadership agreed the outcome, deliverables, constraints, dependencies and timing. The engineering team decided how to achieve them.

That arrangement required trust.

In many organisations, trust in engineering expertise was gradually replaced by administrative visibility. Stories, points, sprint boards, ceremonies and status fields became mechanisms through which people outside the technical work could observe and influence its internal organisation.

The sprint ceased to be merely a cycle through which a team organised itself. It became a management unit. Stories were assigned points, points were aggregated into velocity, and movement across a board was presented as progress.

This altered the relationship between the project and the team. Delivery leads descended into sprint administration. Analysts and other intermediaries began defining technical stories before engineers had established the shape of the solution. Requirements were scattered across tickets, documents, diagrams and comments, while the engineering team reconstructed the real deliverable during implementation.

Stories became either too broad to execute or so narrowly divided that none represented a meaningful result. One could not be completed without three others, while the dependency between them was known mainly to the developers expected to perform the work.

The requirement and the story had been confused.

A requirement belongs in the project plan. It should describe the business outcome, relevant rules, dependencies, constraints and evidence that will demonstrate completion. The engineering team should decide how to decompose it into technical work.

The familiar formulation, “As a user, I want…”, does not repair this confusion. It can be useful where it expresses a genuine user need. It becomes process theatre when applied mechanically to migrations, infrastructure work, refactoring, security remediation or technical conversion.

An agent needs the actual objective, context, constraints and acceptance evidence. Ceremonial wording contributes nothing when those are absent.

Agile without the ritual

A software migration I managed provides a practical example.

The project involved converting approximately 2,500 programs. We began with a four-person engineering team and used the first two weeks to establish how much work could be completed. From that evidence, we found that the number of source lines provided a sufficiently reliable basis for estimating conversion effort across the program set, despite differences in the apparent complexity of individual programs.

We used that measure to forecast throughput and determine how many programs could be completed in each recurring cycle. A separate roadmap contained the project milestones and wider commitments.

The Jira items were simply the names of the programs to be converted.

There was no reason to convert each one into an artificial user narrative. The engineering team understood the objective and the conversion method. The item identified the next bounded unit of execution, nothing more.

There were no delivery managers or analysts decomposing the technical work, and no ceremonies imposed to provide management with a view into the team’s internal activity. The project had a plan, scope, milestones and measurable outcomes. The team determined how to perform the work and reported whether it had met the agreed target.

Over four years, it was the only team in the wider environment that consistently met its commitments.

That was Agile as originally intended. The team adapted its method to the work, used empirical evidence to improve its forecasts, and retained control over execution within a clear project plan.

Jira was useful because it recorded a simple unit of work. It did not define the method, invent the requirement or become the project plan.

The distinction is critical to evaluating AI delivery platforms. A useful tool remains subordinate to the delivery model. A damaging one encourages the organisation to adapt its work to the tool.

Atlassian and the fixed format of Agile

Atlassian occupies a powerful position because Jira, Confluence and related products have become embedded in the way many organisations represent software work.

That position is not neutral.

Jira converts work into structured fields, workflow states, stories, boards, sprints and reports. Confluence stores another layer of requirements, analysis, decisions and technical explanation. Miro and similar visual tools may hold workshop output, process diagrams and preliminary thinking. Code, tests, releases and production evidence remain elsewhere.

The result is often not a coherent body of organisational knowledge. It is a collection of representations that people must continually reconcile.

Requirements are copied into stories. Decisions are buried in comments. Pages become stale. Diagrams no longer reflect the system. Dependencies are visible in one product but absent from another. The backlog can appear orderly while the underlying analysis remains incomplete.

Jira turns software delivery into structured form-filling and presents the movement of those forms as evidence of control.

Boards move, statuses change and velocity can be reported. None of those facts establishes that the requirement is accurate, the dependency model is understood or the wider deliverable remains on track.

Atlassian’s July 2026 product direction places AI agents inside this existing structure. It describes Jira as a place to plan, assign, govern and measure work across people and AI agents, while Teamwork Graph is intended to connect context held across Jira, Confluence, repositories and other systems.[1][2]

Atlassian also describes agents as participants whose work can be assigned, tracked, audited and governed inside Jira.[3]

Those are factual descriptions of the product direction. They do not establish that Jira should become the organising centre of AI-assisted software delivery.

The important question is whether agent execution should be organised around Jira work items at all, or whether project requirements, engineering decomposition and machine-speed execution need a different relationship.

An agent can complete a bounded task in minutes or hours. Forcing that task into a two-week sprint does not improve it. Monitoring the agent session from a board does not establish that the task was worth doing or accurately specified. Turning intent into a longer ticket does not guarantee that the intent has been understood.

Atlassian is using AI to extend the delivery model its products already dominate. That is commercially rational. Organisations should nevertheless examine whether the model remains fit for purpose before allowing the vendor to make itself the centre of their AI operating environment.

The repository-centred model

GitHub and GitLab begin from a different control point.

The repository contains the code, change history, branches, pull requests and an increasing amount of testing, security and release information. Both platforms are expanding their ability to host or coordinate agents across technical delivery.

GitHub allows work to be delegated to Copilot and third-party agents, including Claude and Codex, with asynchronous work returning plans, code or pull requests to the repository workflow.[4] GitLab describes its Duo Agent Platform as a means of coordinating agentic work across planning, building, security and delivery.[5][6]

The repository is a stronger technical record than a sprint board. It shows what changed and allows evidence to be associated with a specific implementation.

It still does not contain the whole project.

The repository may not contain the business purpose, project dependencies, operational history, regulatory reasoning, resource constraints or decisions that led to the change. It can become the authoritative record of what was implemented without becoming the authoritative record of why the implementation was required.

Repository-centred platforms are therefore well positioned to control technical execution and maintain provenance. They are less naturally positioned to own the full relationship between business intent and project delivery.

A sensible architecture may use the repository as the authoritative technical record while retaining requirements and project commitments elsewhere. The challenge is preserving the relationship between them without reducing it to links between tickets and pull requests.

Execution agents as replaceable capability

Claude Code, Codex, Cursor and other coding agents occupy the point where intent becomes technical action. Part 2 examined their operating models and capabilities, so there is little value in repeating their feature lists here.

Their significance for the platform landscape lies partly in their replaceability.

An organisation may use different models for different types of work, permit several agents to operate within the same repository, or replace one execution provider without redesigning the whole delivery environment.

That possibility argues against allowing the coding agent itself to become the organisational control plane. The agent should operate within an environment that supplies context, identity, authority, tools and evidence requirements. Its capability can then improve or change without taking ownership of the delivery model with it.

Open integration standards, including the Model Context Protocol, can reduce the effort required to connect agents to external information, tools and workflows.[7]

They do not determine which information is correct, what an agent should be allowed to do or how conflicting context should be resolved.

Connectivity is useful. It is not understanding, authority or governance.

Testing, assurance and the danger of shared assumptions

AI is being added to code review, test generation, security scanning, vulnerability remediation and test maintenance. These capabilities can reduce effort and improve coverage.

They can also create an illusion of independent assurance.

An agent may misunderstand the requirement and produce an implementation consistent with that misunderstanding. If the same agent, or another agent using the same context, generates the tests, the tests may confirm the same mistake.

A green pipeline does not establish that the right outcome was delivered. It establishes that the implementation satisfied the checks that were run.

A complete platform must therefore retain the relationship between the requirement, the risks identified, the evidence selected and the result obtained. It should show where independent reasoning entered the process and which important assumptions remain unverified.

Testing and security platforms are valuable parts of the lifecycle. They should not be permitted to turn the production of more automated artefacts into a substitute for assurance.

Release, infrastructure and bounded authority

Delivery and infrastructure platforms occupy a legitimate and necessary control point. Environments, secrets, deployment permissions, approvals, rollout, rollback and operational promotion all need disciplined control.

Harness calls its current offering Agent DLC, describing it as coverage of the AI Agent Development Lifecycle from building and testing through deployment, security, governance and runtime operation.[8][9]

This is primarily concerned with delivering and operating AI agents as software, although it also shows how established delivery controls are being extended into agentic systems.

Reusing proven release and infrastructure controls is sensible. AI does not remove the need for them.

It does change how authority may need to be expressed. An agent may be allowed to propose infrastructure code but not apply it. It may deploy automatically to an isolated environment but require additional evidence before production. It may read production telemetry without being authorised to change production.

Those boundaries should follow the work throughout the lifecycle. They should not depend solely on a final approval button placed at the end of a pipeline.

Production operations and the missing return path

Observability and incident-management platforms have access to something planning and coding systems do not possess: evidence of how the software actually behaves.

AI can assist with signal correlation, incident analysis, diagnosis and suggested remediation. The larger opportunity is to connect operational evidence back into the delivery model.

An incident should be traceable to the relevant requirement, assumptions, implementation, tests, agent actions and release decision. Its resolution should update future tests, architecture decisions, context and policy.

Most delivery systems still treat production as the end of a pipeline. A mature AI delivery platform should treat it as part of a learning loop.

That change is not primarily an observability feature. It requires continuity across the whole lifecycle.

Governance at two levels

As organisations adopt multiple models, agents and AI-enabled products, they need an enterprise view of what exists, who owns it, what it can access and which policies apply.

ModelOp and other AI-governance providers approach the landscape through inventory, ownership, risk classification, policy and portfolio oversight. ModelOp describes its inventory as a system of record covering machine learning models, generative AI, agents, agentic systems, vendor tools and embedded AI.[10]

That is necessary, but it is not the same as governing software delivery.

An organisation may approve an agent for engineering use and still need to determine whether a particular change was properly justified, implemented, tested and released. Agent governance addresses the AI asset. Delivery governance addresses the work performed by that asset.

A complete platform needs both views and must connect them.

Mapping the 2026 landscape

The current landscape can be mapped against the lifecycle, with suppliers extending from their established positions.

The landscape contains strong products in individual areas. The unresolved question is how they should be assembled, which functions should remain authoritative, and whether the resulting delivery model improves the work or merely creates a larger system of automated administration.

AI-enabled delivery and AI-optimised delivery

The most important distinction in the 2026 landscape is between adding AI to the current process and reconsidering the process in light of AI.

An AI-enabled process retains the existing lifecycle and inserts AI features into it. Planning tools generate stories, agents complete them, review tools analyse pull requests, test systems generate cases, pipelines diagnose failures and observability tools summarise incidents.

Each capability may be useful. The combined system may remain fragmented and badly designed.

An AI-optimised delivery model begins with the nature of the work. Defined projects retain scope, requirements, dependencies, milestones and project accountability. Prototypes retain hypotheses, boundaries and learning outcomes. Engineering teams determine how technical work should be decomposed. Agents operate within clear authority and context. Evidence accumulates throughout execution. Production outcomes return to planning and analysis.

Management controls the outcome rather than the mechanics of every task.

This is not a return to heavyweight project methods. It is a restoration of the distinction between project planning and expert execution.

What remains missing, and what a complete platform would require

The present landscape covers most individual delivery activities. Its weakness lies in the relationships between them.

Authoritative intent

The first gap is a durable representation of what the project is trying to achieve.

Planning and documentation platforms can store large quantities of material, but the requirement may still be fragmented across tickets, pages, diagrams, comments and conversations. The platform needs to preserve the project outcome, business rules, dependencies, constraints, uncertainty and evidence of completion.

This information cannot be replaced by a larger story description. It needs to remain authoritative as the work is decomposed, implemented, tested and operated.

Engineering decomposition

Business and project analysis should establish the business requirement and intended deliverable. The engineering team should determine the technical stories, tasks or internal sub-plan required to produce it.

Current platforms frequently encourage the reverse. Somebody is expected to populate a backlog before the technical analysis has established the structure of the solution.

AI could assist engineers in analysing a requirement, identifying dependencies and proposing a coherent technical decomposition. It should not be used merely to produce more stories from incomplete material.

Context that is relevant and trusted

Giving agents access to Jira, Confluence, repositories, databases, telemetry and other systems does not establish that the material is current, relevant or internally consistent.

The platform needs to retain provenance, identify authoritative sources and expose conflicts. More accessible context can otherwise produce greater confidence without greater understanding.

Coordination across agents

Several agents may analyse, implement, test, review and deploy parts of the same change. A collection of sessions and transcripts is not a shared delivery model.

The platform needs common work state, explicit authority boundaries, conflict handling and traceability across their combined reasoning and actions. It also needs to recognise that several agents using related models or shared context do not necessarily provide independent judgement.

Evidence that travels with the change

Tests, security scans, reviews, approvals, deployment records and production results are usually held in different systems.

Evidence should accumulate alongside the change and remain connected to the original requirement. Its depth should reflect the risk and consequence of the work rather than forcing every change through the same administrative process.

A low-risk, well-understood modification may need little intervention. A change affecting customer funds, safety, regulatory reporting or critical infrastructure may need independent analysis, richer evidence and explicit approval.

Outcome-level control

Management does not need continuous surveillance of every prompt, story and agent action. It needs to know whether the deliverable remains achievable, whether dependencies are resolved, whether evidence is adequate and whether risk is changing.

Detailed agent activity will be necessary for investigation, technical review and audit. It should not become the AI equivalent of managing software through ticket movement and velocity.

A mature platform should strengthen project-level visibility while preserving the engineering team’s control over execution.

Bounded authority

Agents should operate through controlled identities and permissions appropriate to the task, system and environment.

An agent may be permitted to inspect a repository but not its production secrets. It may propose a deployment but not execute it. It may make an isolated low-risk change automatically while a consequential change requires independent evidence and human judgement.

Authority should be expressed throughout the lifecycle rather than reduced to a final approval gate.

Production as part of delivery

Production telemetry, incidents, support cases and customer outcomes should alter future requirements, tests, architecture decisions and agent instructions.

The platform should preserve the return path from operational evidence to planning and analysis. Without it, the lifecycle remains a one-way automation pipeline rather than a learning system.

Clear accountability

A requirement may begin in one product, be interpreted by an agent from another provider, implemented through a repository platform, tested by specialist tools, deployed through a pipeline and monitored by an operational agent.

The distribution of work cannot be allowed to obscure ownership of the outcome.

The organisation must retain clear responsibility for the requirement, technical decision, assurance decision and release. AI can perform actions and produce recommendations. Accountability remains with the people and structures that authorised the work.

A complete AI delivery platform does not need to be a single product. Given the pace of change, dependence on one supplier may be undesirable. It does need an architecture that establishes which information is authoritative, how authority is delegated, how evidence is retained, and how the participating products and agents remain subordinate to the organisation’s delivery model.

A landscape that should be challenged

The 2026 landscape contains most of the technical components required for AI-assisted software delivery. Planning and documentation products hold organisational information. Repository platforms preserve the technical record. Agents can perform substantial engineering work. Testing and security systems can produce assurance evidence. Delivery platforms control release and infrastructure. Operational systems reveal production behaviour. Governance products provide enterprise oversight.

The existence of those components does not prove that the current model is correct.

Established suppliers are extending AI from the products and processes they already own. That is commercially understandable, but it creates a risk that AI will be used to preserve inherited structures rather than improve them.

Lean organisations and startups may be less constrained. They can design around clear outcomes, small expert teams, rapid agent execution, dynamic technical decomposition and continuous evidence without first reproducing the administrative machinery of a large enterprise toolchain.

Large organisations face more dependencies, greater risk and stronger regulatory obligations. They cannot simply discard existing controls. They can still question whether stories, points, sprint reporting, duplicated documentation and task-level surveillance are the controls they actually need.

Nothing in software delivery should be beyond criticism. Older project methods produced results and also accumulated serious weaknesses. Agile arose because engineers challenged them. Agile itself was later absorbed into practices and products that often contradicted its original purpose.

AI provides another opportunity to examine the whole lifecycle.

Part 2 asked which AI capabilities were mature enough to enter the engineering environment. The harder question now is whether the environment being built around them is itself fit for purpose.

The important choice is not which vendor has inserted AI into the greatest number of activities. It is whether the resulting delivery model retains what works, changes what no longer fits and removes structures that obscure rather than improve the work.

The defining AI delivery platform will not be the one that produces the most stories, fills the most workflow states or places an agent in every product. It will be the one that connects project intent, engineering judgement, rapid execution, evidence and operational learning while preserving clear human responsibility for the outcome.

References

[1] Atlassian (2026), ‘How we’re evolving Jira for AI-native software development’, Atlassian, 15 July.

https://www.atlassian.com/blog/company-news/ai-sdlc

[2] Atlassian (2026), ‘Jira for AI-Native Software Development’, Atlassian.

https://www.atlassian.com/software/jira/dev

[3] Atlassian (2026), ‘Atlassian Team ’26: Meet the AI-Native Organization’, Atlassian, 6 May.

https://www.atlassian.com/blog/company-news/founder-update-team-26

[4] GitHub (2026), ‘Agents on GitHub’, GitHub.

https://github.com/features/copilot/agents

[5] GitLab (2026), ‘GitLab Duo Agent Platform’, GitLab Documentation.

https://docs.gitlab.com/user/duo_agent_platform/

[6] GitLab (2026), ‘GitLab 18.8 released’, GitLab, 15 January.

https://docs.gitlab.com/releases/18/gitlab-18-8-released/

[7] Model Context Protocol (2026), ‘What is the Model Context Protocol?’, MCP Documentation.

https://modelcontextprotocol.io/docs/getting-started/intro

[8] Harness (2026), ‘Harness Agent DLC: Secure the Agent Lifecycle’, Harness, 21 July.

https://www.harness.io/blog/introducing-harness-agent-dlc

[9] Harness (2026), ‘Introducing Harness Agent DLC: New Capabilities for the AI Agent Development Lifecycle’, Harness, 21 July.

https://www.harness.io/press-and-news/introducing-harness-agent-dlc

[10] ModelOp (2026), ‘Evergreen AI Model Inventory’, ModelOp.

https://www.modelop.com/ai-governance-software/inventory