Enterprise software supply chains today run largely on a deterministic toolchain anchored around project management methodologies like AGILE. The Software development lifecycle brings together several personas ( Project managers, Developers, Security operators, SRE engineers ) and stretches all the way from planning to release management and is composed of a rich set of tools operating across the various stages of the SDLC. Think of Jira/Linear for Epic/issue management, Gitlab/Github for SCM, Terraform for IaC, Data Dog for Observability. The list is quite vast and depending on the SDLC function/ end user preferences, this list varies for each customer and is heterogeneous.
AI agents now participate at every stage of this SDLC (Software development lifecycle ). They draft requirements, generate code, interpret pipeline results, and recommend release decisions. This toolchain worked well when software systems were principally designed for human workflows but when it comes to AI agents however, the emerging risk now is between the SDLC stages that agents operate without shared context and governance.
In this article, we examine some of the architectural gaps and outline a modernisation path enterprises can follow, introducing a reference model for governed agent infrastructure that can operate seamlessly within your existing toolchain boundary and allow effective orchestration of the deterministic systems layer organizations already operate today.
What we’ll cover:
1. The current state of DevSecOps in AI-native software development
2. Why pre-AI operating models are insufficient for agent-driven workflows
3. The challenge of context across the deterministic toolchain
4. Three stages of DevSecOps modernization
5. Reference Architecture for governed agent infrastructure for Devsecops
Enterprise DevSecOps today depends on a deterministic toolchain that produces replayable, auditable results at each stage of the software supply chain. AI agents currently operate within this toolchain. Most deployments integrate these agents at the point-tool or platform level, often without a shared context layer and introduce context fragmentation across the SDLC (planning, development, CI/CD, Release Management).
In our view, enterprises are progressing through 2 patterns of modernisation,
1) Embedding Intelligence within a specific stage of the SDLC tool/platform: Over the past year most tools adopted integrating intelligence directly within their application /platforms ( think of co-pilots, chat assistants doing RAG), Devsecops platforms like Github and Gitlab offered code assist and generation capabilities. These capabilities were largely anchored on feeding tool/application context to an LLM that could provide a response.
2) Adoption of a Workflow orchestration layer: Starting early this year most platforms now offer agent driven capabilities where workflows can be orchestrated in a vendor’s opinionated way ( example Gitlab ). While we believe this greatly expands the scope of automation for an enterprise adopting a heterogeneous toolchain, this also introduces the problem of agent sprawl and infact increases the Operational cost of running the tool chain. We can debate whether the inference happens locally or remote but if we consider for a moment the cost of distributed inference where every vendor charges you for inferencing costs, it makes absolute sense for an enterprise to move the agent orchestration layer out of the deterministic layer and build out a dedicated Agent orchestration and governance layer where LLM costs and token usage can be consolidated.
Another aspect to consider would be the platform tooling strategy itself for an enterprise. SaaS/ Self hosted developer platforms made sense when the industry was trying to solve the integration and context switching problem with the aim of reducing the cognitive burden for the end user. With Agent driven flows on standardized MCP connectors, the integration problem has largely been solved. Its worth debating if specialised purpose built modular point solutions are a better way to go instead. The software industry is shifting from a feature moat ( which a lot of Opencore business models also relied on ) to now building a service moat. This opens up an opportunity for enterprises to decouple themselves from licensing costs justified on proprietary features and increase adoption of specialised purpose built deterministic tools within the SDLC tool chain.
In our view, for Agent driven workflow’s it makes sense to decouple the deterministic platform layer from the agent orchestration layer to reap the benefits of tool chain consolidation during this exercise. Your existing deterministic toolchain could very well be relegated to a CRUD database as the end user value moves from the feature layer of an application to the agent orchestration layer which owns the outcome.
A governed agent infrastructure / dedicated control plane for the SDLC now starts making sense in this context. Think of agent identity, policy, context routing, audit, and cost governance all being centralised and decoupled from the operational flows of your current SDLC toolchain. Are there any benefits of doing this ? Lets understand further.
Traditional DevSecOps organized people into specialized functions ( development, security and platform engineering). Each function owned a segment of the SDLC and teams worked across defined boundaries and coordinated context through a predefined workflow. Tools could be plugged in and out of this workflow and context often resided within the application datastore, documentation, tickets and informal channels.
While frameworks like Agile and scaled agile standardized these human driven workflows, these frameworks could not standardize machine-readable context across systems.
In human-centric workflows, missing context often only created coordination delays. In an agent-driven workflow, it creates autonomous action on incomplete context and information which can have sub optimal outcomes.
Organizations have adopted specialized systems so each supply-chain stage remains deterministic and auditable. The issue when it comes to Agent native workflows is largely architectural. End to End workflows decompose into partial views for an agent without a layer that carries intent, policy, and operational context across the different stages of SDLC.
Stage 1: Embedded Application intelligence | Embed inferencing in products: copilots, retrieval-augmented generation, embedded models | Delivery toolchain unchanged; agents remain application-adjacent | AI investment visible in product, not in delivery velocity or governance.
Stage 2: Point-tool agent adoption | Integrate agents into IDEs, pipelines, Project planning and review workflows | Context fragmentation; each agent accesses a single tool boundary
Stage 3: Fully Orchestrated toolchain | Execute end-to-end workflows across planning, delivery, and release | Requires context orchestration and governed agent infrastructure that spans beyond point tools and platforms. | Inference cost, policy enforcement, and audit become operational concerns
For technology leaders trying to modernise their software supply chain, three actions clarify readiness at the moment:
1. Map the deterministic toolchain to delivery stages/outcomes and identify inefficiencies: Consolidating your tool chain can drive not just cost efficiencies but also reduce operational toil and LLM token usage for your teams. Document per stage, system of record, inputs/outputs, human handoffs, agent touchpoints
2. Modernize for end-to-end workflows — not point tools/platforms: Having a centralized Agent orchestration layer with a unified context/storage and memory allows agents to have complete operational visibility of the SDLC and how agents should reason and act.
3. Build out a separate Agent Infrastructure stack / layer decoupled from your deterministic SDLC tooling layer: Adopting a dedicated agent infrastructure stack can help enterprises decouple from proprietary features and products and increase adoption of Opensource. This also helps reduce licensing spend.
Key Takeaways: