§ Case study · Agentic systems
An agentic pipeline for the full software delivery lifecycle inside a large enterprise engineering organisation.
End-to-end agentic system operating across a 200-strong engineering organisation — from requirements clarification and architecture design through use-case and test-case authoring to progress monitoring and quality assurance. The humans stay in the accountable seats; the agents remove the friction between them.
a large enterprise software delivery organisation
Client
Enterprise
Tier
30 weeks
Duration
2026
Delivered
The context
What they came to us with.
A large enterprise delivery organisation — 200 engineers across eight product lines, a mature architecture practice, an established engineering standards document, and an operating model that had shipped consistently for years. Individual engineers had adopted AI coding tools independently, but the organisation had no shared story about how AI fit into their delivery pipeline as a whole.
The problem wasn't code generation. It was everything either side of it — inconsistent requirements documentation, use cases captured late or not at all, test coverage lag on new work, progress dashboards that reflected activity rather than outcome. Each was a source of rework. Each was individually solvable and collectively invisible.
They wanted an agentic system that operated across the whole delivery lifecycle — not to replace their engineers, but to remove the friction between the humans in each accountable seat.
The approach
What we did, in order.
-
One workflow document per product line.
Four weeks of shadowing before a line of code, in each of the eight product lines. We wrote up how each team actually delivered — from ticket to review to release — and used that as the reference the agent system respected. The agent topology fell out of the workflow, not the other way round.
-
A small fleet of specialist agents, not one general one.
Requirements-clarification agent, architecture-fit checker, use-case authoring agent, test-case generation agent, exception- criteria walker, QA reviewer, progress reporter. Each with a small tool surface and a small fixture set of tasks it was measured against. Composition happened at the workflow layer, not inside any single agent.
-
Human accountability, always.
Every artefact produced by an agent was attributed as such and reviewed by the accountable human — product owner for a requirement, technical lead for an architecture proposal, QA lead for a test plan. Approvals were logged; overrides were logged; nothing merged without a human name attached.
-
Eval spine drawn from real prior deliveries.
Fixture sets built from a year of past requirements, past architecture proposals, and past QA reviews — with expert annotations of what "good" had looked like on each. Regression bars on every rubric. A merge that improved requirements quality but dropped test coverage failed the build.
-
Progress reporting in the operating language of the team.
No new dashboards. The agent system produced its updates in the same Jira workflow the delivery leads already lived in — status changes, comments, PR annotations. Reporting became a by-product of the work, not a separate ceremony.
How we measured
The bar we held ourselves to.
- Requirements-to-first-PR cycle time — per product line, on a rolling four-week window.
- Test coverage delta on new features versus the previous half-year baseline.
- Defect rate on merged code, tracked against the same baseline.
- Human-override rate per agent — a proxy for whether the agent was earning its keep.
- Reviewer sentiment on generated artefacts, sampled monthly across all eight product lines.
The outcome
Where it landed.
200
Engineers across the platform
−41%
Requirements-to-first-PR cycle time
+18pp
Test coverage on new features
Six months in, requirements-to-first-PR cycle time was down 41% across the eight product lines, with the strongest gains in the teams whose requirements documentation had been the weakest at baseline. Test coverage on new features rose by eighteen percentage points; defect rate at merge time dropped materially on the same denominator. Human override rate on the requirements-clarification agent stayed at ~15%, which is roughly where we'd expect it — high enough to prove people were reading, low enough to prove the agent was useful.
The system runs on their own platform, maintained by their own team. Our exit was on the original schedule; the six-month review flagged two of the seven agents as candidates for retirement (they'd been superseded by workflow changes) and one as a candidate for expansion. That's roughly the ratio you want.
Retrospective
What we'd do differently.
- We under-invested in the progress-reporter agent early — it landed in week 20 and would have paid back sooner if it had shipped in week 8.
- The architecture-fit checker was over-scoped in the first design. We halved its remit in week ten and the acceptance rate doubled. Next time we'd design it small first.
- We would have moved the fixture-set construction earlier — the eval spine paid for itself, but retrofitting it after four agents were already in flight cost us two weeks.
Services used
The moves in this engagement.
S1 · Build
AI-Aided Development
Senior engineers paired with AI coding agents, custom tooling, and evaluation harnesses — applied to your delivery or operationalised in your team.
S2 · Build
Agentic Systems Engineering
Multi-step LLM workflows with clean topology, tool surfaces, memory, evaluation, and safety — built to land in production, not stall in a demo.
S3 · Build
LLM Integration
Chat, RAG, and the wider integration stack — measured, regression-tested, and cost-aware from the first prompt.
S5 · Advise
Technical & Solutions Architecture
A senior architect embedded with your programme — end-to-end design, build-vs-buy calls, vendor evaluation, technical risk review.
Have something with this shape?
A 30-minute discovery call. We'll say honestly whether the pattern fits.