Proof of Concept · DevSecOps · Release Automation
Hundreds of builds a day, governed by an agent
Hundreds of build iterations were deploying daily, and every one of them ran through a DevOps team drowning in manual coordination: chasing approvals, babysitting pipelines, triaging failures. This proof of concept put an AI agent in front of the entire release process, from the developer's first email to the finished deployment, and left two engineers comfortably running more than twenty environments.
- 100sof build iterations deployed daily through the agent-governed processDaily, through the agent-governed path
- 4approval stages managed by the agent: module lead, QA lead, functional, securityStages the agent requests and tracks
- Every stepof the Jenkins pipeline monitored; failures analyzed the moment they occurPipeline coverage, not a success rate
- Exact fixemailed to the developer, what to change in the code, not just what brokeEmailed to the developer who submitted
- PRs raisedon GitHub with the agent's code-review feedback attachedWith review feedback attached
- 2 → 20+two DevOps engineers now operate more than twenty environmentsEngineers to environments, in this POC
The Challenges
Release volume had outgrown the team long before anyone admitted it. Every build meant manually chasing four different approvers, triggering pipelines by hand, watching them fail, and translating cryptic pipeline errors into something a developer could act on, hundreds of times a day, across more than twenty environments.
- Approvals chased by hand
Module lead, QA lead, functional and security sign-offs collected over chat and email, for every single build.
- Pipelines babysat
Someone had to trigger Jenkins, watch it, and re-run it, at a volume no team can watch.
- Failures without guidance
A red pipeline told the developer something broke, not what to change to fix it.
- Code review as bottleneck
Review depth collapsed under release volume; feedback arrived late or not at all.
- No release intelligence
Nobody could say which services failed most, or why one service burned through so many builds.
- Headcount scaling with chaos
Every new environment meant more manual coordination, not more value.
The architecture, and why intake is an email
The design decision people question first is the one that makes it work. Developers submit a release by emailing the agent, with the Git details in the body, because that is what they were already doing to a human release manager. Nobody had to learn a portal, and adoption did not depend on anyone changing a habit under deadline pressure.
Everything after intake is the part that used to consume two engineers: chasing four sets of approvals, triggering the pipeline, watching it, working out why a stage failed, and reviewing the code. The agent fronts all of it, and the approvals remain human decisions rather than becoming a rubber stamp with a shorter path.
Governance configured once, enforced always: the four-stage approval chain is policy, not process heroics. No build reaches a pipeline without its complete, recorded approval trail, and every agent action is audited.
What the proof of concept established, and what it did not
Release automation is an easy place to overclaim, because a pipeline that runs looks like a process that works. The split below is what we would defend in a room with the engineers who ran it.
What it established
- Email intake removes the adoption problem: developers submit the way they already communicate
- An agent can request, chase and track a four-stage approval chain without the approvals becoming a formality
- Pipeline failures can be diagnosed to a cause and returned as an actionable fix rather than a stack trace
- Code review can be raised as a PR with feedback attached, restoring review depth that had become a bottleneck
- Two DevOps engineers operated more than twenty environments through this path
What it did not establish
- A measured change in release failure rate, lead time or rework. None was measured
- Whether the fix suggestions are right often enough to be trusted unsupervised over months
- Behaviour under a genuinely contentious release, where approvals are withheld and argued about
- That the two-to-twenty ratio holds as environments grow, rather than describing this estate at this moment
What a release looks like now
Six steps, of which exactly one still requires a human to think, and that is deliberate. The approvals are the control, not the friction.
The Sentinel loop, as it runs here
Every Opstral deployment runs the same four-stage loop: Observe, Investigate, Act, Optimize. It is the methodology rather than a feature list, and the point of setting it out per deployment is that you can see which stages carried the weight in this one and which did not.
- ObserveTake in every signal the estate produces, normalised and correlated as it arrives rather than after somebody goes looking.HereIntake is an email from a developer, deliberately, because the loop has to start where the work already starts. Every pipeline stage is then watched as it runs.
- InvestigateWork the signal into a probable cause with the evidence attached, before anyone is notified.HereFailures are diagnosed rather than reported. The agent reads the stage that failed and produces an explanation, which is the step that removes the DevOps team from the middle of every build.
- ActRun the approved procedure where the blast radius allows it, or hand a named human the plan, the evidence and the rollback.HereFour approvals are requested and tracked, and on acceptance the pipeline runs itself across 20+ environments. Code is reviewed and a pull request raised with the feedback attached.
- OptimizeFeed the outcome back so the next run of the loop is better informed than the last.HereThe release becomes data. Each run adds to a record that makes the next diagnosis better founded than a fresh read of a log file.
- A developer emails the agent
Git details in the body. No portal, no new tool, no change of habit under deadline pressure. Intake being boring is why the rest of it got used.
DeveloperObserve - The agent requests and tracks four approvals
Module lead, QA lead, functional and security. It asks, it chases and it records. What it does not do is decide, and the distinction is the reason a security lead was willing to be in the chain at all.
PlatformAct - On acceptance, the pipeline runs itself
The agent triggers Jenkins in the background. Nobody sits with a hand on the button waiting for a green tick, which is the specific activity that consumed two engineers.
PlatformAct - Every stage is watched, and failure is diagnosed
Not just detected. On failure the agent works out the cause and emails the developer what to change in the code, which is a different artefact from a link to a failed build.
PlatformInvestigate - Code is reviewed and a PR is raised
The agent reviews on GitHub and raises a pull request with its feedback attached. Review depth had become the bottleneck precisely because the people qualified to do it were the people already busy.
PlatformAct - The release becomes data
Releases, failure rates and build churn per service are tracked and queryable. Asking why one service keeps breaking now returns an answer rather than an impression formed by whoever was on call most recently.
PlatformOptimize
The Outcome
The chaos did not shrink, it disappeared as a category. Release throughput stayed at hundreds of builds a day; what changed is that two engineers now run the whole estate, and the process answers questions instead of generating them.
| Dimension | Before | After · agent-governed |
|---|---|---|
| Release intake | Ad-hoc requests, manually coordinated | Email to the agent, Git URL, tags, changes, done |
| Approvals | Four sign-offs chased by hand per build | Agent-managed chain, build accepted only when complete |
| Pipeline execution | Triggered and babysat by DevOps | Triggered and monitored by the agent, end to end |
| Failure handling | Red pipeline, developer left guessing | Exact fix emailed, with a reviewed PR raised on GitHub |
| Team footprint | Headcount scaling with environments | 2 engineers running 20+ environments |
| Visibility | No answer to 'which service fails most?' | Queryable release intelligence across every environment |
The approval chain was configured once. Since then, every release has followed the same governed path, and the two people who used to drown in coordination now manage twenty-plus environments by exception.
At a glance
- Domain
- DevSecOps · CI/CD
- Geography
- Not disclosed
- Engagement
- Proof of concept
- Scale
- 20+ environments
- Platform components
- Sentinel AI, email intake, Jenkins, GitHub, governed approval tracking
- Evidence basis
- Proof of concept: scope was capability validation, not production operation. Figures reflect the engagement’s observed operating scale rather than measured improvement. Customer identity withheld by request.
Put an agent in front of your release process
Email-driven intake, policy-grade approvals, self-monitoring pipelines and exact-fix feedback, validated at hundreds of builds a day.
Proof-of-concept engagement: scope was capability validation, not production operation. Customer identity withheld by request. Figures reflect the engagement's observed operating scale.