Results at a glance
Audit preparation: weeks to days. An operational observation from the people who prepare Catapult’s audits, not an instrumented measurement.
45 requirements and 240 test files. The research platform, built entirely under the workflow between 26 August and 22 October 2026, with 39 decision records.
11.5-minute median ticket. Measured across 137 autonomous build runs from the agents’ own transcripts.
A small team, four management systems
Catapult CX is a small consultancy. A core team works alongside specialist contractors, with the mix changing as the volume of work does.
That team holds ISO/IEC 27001, ISO 9001 and ISO/IEC 20000-1 certification, covering information security, quality management and IT service management. It has passed Stage 1 of ISO/IEC 42001, the AI management system standard, and is preparing for Stage 2. Its clients include government bodies, financial services firms and telecoms providers, and it also runs its own SaaS product.
An organisation with that much compliance and regulated delivery would normally have a compliance function, a quality assurance function and a delivery management layer. Catapult has none of them. That constraint is why its agentic workflow exists, and why the workflow has to be honest: a process nobody has spare time to police has to police itself.
Why the standards had to be executable
Standards written as prose are applied by whoever happens to be reviewing. With a small core team and a contractor pool that changes with the work, “whoever is reviewing” is a hope rather than a control.
So Catapult built its engineering standards as two things a machine applies: text loaded into every agent session, and gates that fail a build. Guidance that only a person applies gets applied inconsistently. Inconsistent enforcement is worse than none, because people learn to argue with it, and the habit spreads to the controls that matter.
The standards system now holds 11 rules files, 29 skills across 14 plugins and 11 architecture decision records (ADRs), built up over 213 commits since 10 February 2026.
The same approach runs Catapult’s operational work. Agents pick up and process tickets, from service requests through to incidents, and others carry out the analysis and problem-solving behind them.
Built on real work, and corrected in writing
Catapult developed the workflow the way it advises clients to develop one: as a system under test, used on real delivery while it was being built, rather than as a pilot in a sandbox.
The clearest evidence of that method is in the rules themselves. Several carry dated amendments, added in September and October 2026, that record what the previous rule said, why it was wrong and what it cost.
- Gates from the first commit. A rule required every quality gate to be wired up from a project’s first commit. On greenfield projects that produced months of permanently failing pipelines, which taught people to ignore the gates that mattered as well. Gates are now owed from a declared project milestone instead.
- “Not yet” versus “not applicable”. A rule separated gates that weren’t needed yet from gates that would never apply, based on whether a gate would apply one day. Almost every gate applies one day, so the distinction did no work, and the rule was reversed.
- The application logger. A rule said the logger needed no abstraction. That left a use case with no way to record a refusal without breaking the dependency rule, and the same document already contradicted itself on the point. That rule was reversed too.
A workflow rule is a specification of behaviour, and getting one wrong has a cost that can be measured. The amendments are how Catapult pays that cost down in the open rather than patching rules quietly.
The same discipline applies to decisions. They’re recorded as ADRs, including some marked proposed, not adopted, with an explicit instruction not to implement them until the supporting work has reported.
Internal products as the proving ground
Before: the knowledge platform. A multi-service platform written in TypeScript and Go, across 6 repositories, with around 3,393 commits between August 2025 and August 2026. It was built with heavy AI assistance but no shared workflow. It shipped, and much of what’s now in the standards was learned building it. What it couldn’t do was answer “what is this required to do?” from anything other than the code.
After: the research platform and the tender pipeline. The research platform was built entirely under the workflow: 716 commits between 26 August and 22 October 2026, with 45 written requirements, 39 ADRs and 240 test files, and Clean Architecture with its dependency rule enforced. The tender pipeline adopted the same workflow alongside it, with 66 commits, 8 ADRs and 58 test files. The second project is the evidence that the workflow transfers between codebases rather than fitting one.
The workflow measures itself. Catapult analysed 137 autonomous build runs using the agents’ own transcripts. The median ticket took 11.5 minutes and the mean 14.2 minutes, with a median of 4.1 minutes to the first test run. Within a ticket, the wall-clock time split like this:
| Activity | Share of wall-clock time |
|---|---|
| Reading and searching | 37.8% |
| Shell commands | 15.2% |
| Edits | 14.0% |
| Running tests | 8.9% |
| Writing files | 7.2% |
| Commit hooks | 3.9% |
| Type checking and linting | 2.4% |
Together these account for 92.2% of the time measured.
Tests, hooks, type checking and linting take under a fifth of the wall clock. Most of the rest is model turns, so the lever is the number of turns. Of 5,313 read turns, 4,046 (76%) carried a single call. That finding led to a specific change in how the build agent batches its work.
This is a before-and-after instrument, not an estimator. The turns an agent chooses to batch are the ones it already knew how to batch, which is also why they’re cheap to batch. Using the analysis to project a saving would be exactly the error its own documentation warns about.
Client work: AI only with consent
Catapult uses AI on client work only where the client has consented. Without consent there are no agents, and the engagement runs conventionally. Clients choose that option often; it’s a real option, not a theoretical one.
Where a client does consent, how much of the workflow runs is itself part of the agreement. The dimensions that vary are:
- where code and data are processed
- what, if anything, reaches a model
- how much of the delivery loop is run by agents and how much by people
- where the review and sign-off points sit
Consent isn’t a limitation to apologise for. It’s the first control in the chain. A supplier that can’t say clearly when it does and doesn’t use AI is unlikely to be able to evidence much else.
Compliance: the management systems run the same way
Catapult applied the same approach to its management systems. The tooling covers 7 standards and frameworks: ISO 9001, ISO/IEC 20000-1, ISO/IEC 42001, ISO/IEC 27001, SOC 2, the EU Digital Operational Resilience Act (DORA) and the Payment Card Industry Data Security Standard (PCI DSS). They’re split into 245 reference files, one per clause, so a conformance check loads the relevant sub-clause instead of a whole PDF.
Twelve skills work over that reference data. They cover clause lookup, conformance checking, control sweeps, evidence and audit preparation, readiness assessment and policy lookup, plus the full nonconformity lifecycle from raising and scoping an issue through to resolution and status. The compliance repository holds 122 commits made between 27 April and 1 October 2026.
The tooling writes into the systems the organisation already uses. Nonconformities become Jira issues in the existing information security management system (ISMS) project. Policies stay mastered in Confluence and reach the agents as a generated local index. There’s no separate set of compliance artefacts to maintain, which mirrors the delivery workflow, where the plan lives where the team already plans.
The result is that audit preparation has gone from weeks to days. That’s an operational observation from the people who do the work, not a measured figure, and it applies to audit preparation only.
It compresses because the expensive part of audit preparation was never judgement. It was retrieval and cross-referencing: finding the clause, finding the control, finding the record and proving that the three connect. That work shrinks when the standards are machine-readable and the evidence chain is generated as the work happens rather than assembled afterwards.
Assessed on AI governance while using AI
ISO/IEC 42001 sets out the requirements for an AI management system (AIMS). Catapult’s AIMS has passed Stage 1 and is preparing for Stage 2, where an external assessor checks that the controls actually operate, not just that a documented system exists. Catapult isn’t yet certified to ISO/IEC 42001.
So the organisation is being independently assessed on how it governs its use of AI, while using AI agents to run its delivery and produce its audit evidence. The assessor follows the chain from the Statement of Applicability to the document that implements each control, and then to the record that shows the control operating. That’s the same chain Catapult argues for in agentic delivery, tested by someone with no commercial interest in the outcome.
This is why validating the process is the right frame for an audited environment: it describes what is already happening, with a certification body on the other side of it.
What’s still open
Two decisions are recorded as proposed, not adopted. One would measure test quality by what tests detect rather than how they read. The other would load rules on demand rather than in every session. Both carry instructions not to implement them until the supporting work has reported.
There’s also a known gap. Nothing currently proves that a test was written before the code, or that every assertion in a suite is capable of failing. The standards acknowledge that a failing test run can’t be reconstructed after the fact, and there’s no automated check for it yet. On the trust stages Catapult uses with clients, that’s the step between reviewing the tests and relying on the evidence chain. It’s written down, and it’s being worked on.
The workflow’s own tooling gets the same scrutiny. A drift detector built into the standards system produced 82 findings, of which 3 were real. That result is recorded in the system’s decision records rather than left out of them, because a check that cries wolf trains people to ignore it, which is the same lesson the first-commit gate rule taught.
What this means for you
If you deliver software in a regulated or audited environment, the question isn’t whether agents can write the code. It’s whether you can show an auditor how that work is governed, and who decided what.
We work with your engineers to put a workflow like this in place: standards your agents apply on every task, gates matched to where each project actually is, and an evidence chain your auditors can follow. It runs only where you’ve agreed it should, at the level of autonomy you’ve agreed to, and your team owns it afterwards.
Talk to an engineer about what your auditors would need to see before agents take on delivery work in your systems.
For more detail on the engineering principles and trust stages behind this approach, read our Agentic SDLC: trusting the workflow, not the code article.
