After the consequences.

Some technology decisions look fine for twelve months and then don’t. Some look fine until the agentic codebase has grown beyond anyone’s ability to reason about it. Some look fine until the AI vendor’s invoice quadruples, changing the economics entirely. Some look fine until a security review, an audit, or a quiet realisation that the system in production is one nobody on the current team fully understands.

Whether or not the current team made the original call, the question is what to do next.

When clients engage us after consequences have arrived.

Typical shapes:

• We adopted agentic tooling at pace, and the codebase has grown beyond what the team can safely maintain. We have code only the most expensive models can safely modify, and routine changes that break things nobody can trace. We need an independent read and a plan to recover.
• Our token costs are rising faster than the business case anticipated, and the lock-in we accepted to move fast is harder to unwind than expected. We need the trajectory modelled honestly, and a clear view of what to keep, what to replace, and what to contain.
• Something has already happened: an incident, a near-miss, a security finding, an audit observation, or the realisation that a production system is behaving in ways nobody on the team can explain. We need principal independent counsel on triage and the remediation path.
• An AI capability shipped without the controls and guardrails it should have had, and patching in place isn’t the right move. We need it rebuilt, with governance and safeguards in place from the start.
• Our AI costs ran past what the business could absorb. We pulled back on unlimited usage for the engineering team, and they’re now struggling to maintain an agent-generated codebase without the tooling that built it.
• Our test suite takes hours to run, produces failures nobody trusts, and seems to test implementation noise rather than behaviour that matters. We need to know what can be removed, what must be rebuilt, and how to recover a useful release signal.
• The architecture has reached the point where nobody can reason about it without asking an LLM to explain it. We need a map of what is actually there, the dependencies and failure surfaces that matter, and a staged path back to a system the team can understand unaided.
• We used agentic engineering in anger and accumulated features and behaviours nobody deliberately asked for. Some customers now depend on them. We need an actionable plan to decide what is real product, what to retire, and how to walk it back without abruptly removing value or losing customers.
• We cannot tell which parts of the product customers actually use, which are expensive to operate, and which absorb the most engineering effort to maintain. We need usage, cost, and change data reconciled into a view that can drive product and remediation priorities.

Work matched to the symptom.

What the engagement looks like.

Remediation engagements are scoped to the situation. They typically begin with a focused assessment (what’s the actual exposure, what’s structural and what’s cosmetic, what’s recoverable and what isn’t) and proceed to a defined remediation plan with clear sequencing, scope, and accountability. Hands-on implementation work is delivered through the Co: the network of operators we engage when the brief calls for hands rather than advice.

When the work calls for hands on the keyboard rather than counsel in the room, we bring them ourselves. Architecture review, technical due diligence, code-level assessment of agent-generated systems, security and governance design, controlled (re)implementation, the engineering practices, guardrails, and controls that put the work on a durable footing, and the ways-of-working that let the organisation move faster, safely and responsibly.

When the brief calls for hands rather than advice, we bring operators ourselves through the Co, so the work stays with the people accountable for it.

Engagement shapes Talk to us about a remediation engagement