→ Engagement spotlight / Agentic engineering
Teams across the business were struggling to build their own tools with AI. The software factory that industrialises them runs on 8 agents
Most of those applications could only be run by their author. They sat outside source control and any deployment pipeline, and they met none of the organisation's standards for architecture, authorisation, code review or security.
Client developers join the pod from month two. By week 12 they contribute to the shared Skills Repo and use the factory for live work.
→ The sequence / requirement to running application
Six steps, in this order.
01
Treat the prototype as the specification
What someone vibe-coded goes into the pipeline as the requirement. It already encodes what they wanted the tool to do.
02
Write the Living Specification into the repo
CLAUDE.md, AGENTS.md and coding conventions are treated as project infrastructure, versioned alongside the code.
03
Generate to the client's own standards
Agents handle architecture standards, coding conventions, tests, deployment, monitoring and documentation, built to the client's stack.
04
Gate it before it ships
Automated tests, security and compliance gates, user acceptance testing, then a canary release into production.
05
Run the Night Shift
Dependency upgrades and security patches run overnight. Pods review what changed at 9am.
06
Transfer it
Client developers pair with the pod from month two, then phase two stands up a Centre of Enablement they own.
The eight-agent pipeline / mint marks a human decision
↻ Logged Every step is recorded and can be audited, which is what makes the output acceptable to an enterprise IT function.
→ The situation
A growing pile of prototypes that could not ship.
Across the client's teams, people were building their own tools with AI coding assistants. The company encouraged it, and adoption spread fast.
Most of those applications could only be run by their author. They sat outside source control and any deployment pipeline, and they met none of the organisation's standards for architecture, authorisation, code review or security. When someone left, the only person who understood their application left with them, and the bigger a codebase got, the slower it was to change.
The client's instinct was to industrialise what people had already built and keep the adoption it had spent a year encouraging.
MISSION+ proposed a software factory: a pipeline that takes requirements in and puts running, governed applications out. The prototypes become the specification. Agents handle the standards, the tests, the deployment and the documentation. People decide what ships.
The shape of an ACDC sprint
Specifications account for the bulk of the work. Code comes last, and agents write most of it.
→ How the effort divides
Most of the sprint goes into specification.
Where a sprint's effort goes under the Agent Centric Development Cycle
Share of sprint
SpecifyLiving Specification in the repo
Validate and shipGates, UAT, canary release
BuildAgents write, the team reviews
The split is the working allocation of the pilot rather than a measured average across completed sprints. The point it makes is that the specification is the deliverable and the code is derived from it.
Agents in the pipeline
From specification to running application, built to the client's IT standards and stack. Every step is logged and can be audited.
Client developers embedded
Client engineers join the pod and pair with MISSION+ practitioners on live work from the second month.
Client contribution
By week 12 client developers add to the Skills Repo on their own and use the factory for live work.
Reusable agent skills, specification templates and playbooks, specific to this client. It grows with every feature shipped and it remains after the pilot ends.
We work with business owners to choose candidate applications and score them on impact against effort. The factory builds what that scoring puts first.
Dependency upgrades and security patches run overnight, with pods reviewing the diff at 9am. Maintenance stays off the sprint, and a person still signs off what merges.
This is a pilot in delivery. There are no measured productivity figures to report, and the numbers here describe the shape of the engagement rather than an outcome. Extensions such as an application store and a backlog agent have been scoped and remain unbuilt.
→ Why it matters
The client owns the factory once the pilot ends.
Restricting what people had already built would have cost the client the adoption it spent a year encouraging. Putting engineering around it instead means a tool that started as one person's prototype can carry an authorisation model, a test suite and a deployment pipeline without that person having to build any of it.
Client developers join the pod from month two and pair with MISSION+ to transfer the skills. Phase two stands up a Centre of Enablement owned by the client, so the team keeps building once we step back. The Skills Repo is the artefact that makes that possible, and it is theirs.