AI Practice Sprints

What actually makes the Sprint work is a structured knowledge architecture. We take the knowledge a workflow runs on and organise it into four layers a frontier AI model can use reliably.

Semantic. The domain knowledge that doesn't change case by case: the principles, the rules, the definitions, the regulatory frameworks the work sits inside.

Procedural. How the team actually performs a task, step by step: the order of operations, the decision sequence, the process expertise that lives between the lines of any policy document.

References. The templates, formats, standard clauses, checklists, and company-specific artefacts the team already uses to do the work.

Episodic. What's happened before: past cases and decisions, the precedent library, prior outcomes and the reasoning behind them.

Most of this already exists somewhere on the team, some of it written down, some of it just in people's heads. The Sprint pulls it out, structures it, and turns it into something a model can use consistently across the whole team.

A Sprint runs in one of two shapes, depending on what the team needs.

A broad sprint. The whole team's daily workflows become the material. Each person captures the tasks, processes, and decisions that fill their week, and we work through all of it with the team. When workflows overlap, one semantic layer covers everybody; when they diverge, each person builds their own procedural layer on top of it. What you end up with is one shared operating system that the whole team uses, maintains, and keeps extending.

A directed sprint. One concrete problem or use case becomes the material: a workflow with a known quality gap, a process with a known bottleneck, a decision pattern that needs to scale across more people. The engagement runs in two parts. The first one to two weeks go into mapping the workflow with the people who run it today, pulling together the relevant policy and process artefacts, surfacing the decision logic experienced people actually apply, settling the design choices that shape the build, and producing a build plan. The following two to four weeks go into building the working components, iterating with the team, testing on real cases, and running a structured pilot. What comes out the other end is a working workflow, demonstrably running end to end on real material.

Either way, the engagement runs three to six weeks. The faster end works if the team can put in concentrated effort early on. The longer end accounts for the reality of competing priorities, and it's the more common pace.

A kickoff workshop opens the Sprint: two hours at minimum, four hours if a wider audience is joining for the same opening. Everyone leaves that kickoff with a structured intake assignment and a deadline.

Week one is intake and architecture. Each person completes the intake, either self-built or with the template we provide, capturing their tasks, processes, and decision patterns in a form that's ready to be broken down. The first build session shows the team how their own intakes turn into structured AI workflows, live, on their own material. We review existing prompts and assistants: what works stays, and what's fragile gets rebuilt properly.

Weeks two and three are build and integration: structured knowledge files for each layer of the architecture, prompt frameworks, and quality checklists for the prioritised workflows. Every workflow gets built on real cases from the team's actual work, not hypothetical exercises. Support runs throughout: build sessions with the full team, one-on-one coaching for anyone stuck, asynchronous feedback on work in progress.

Throughout, the team learns to close the loop. When an AI output is wrong, they learn to figure out where the problem actually sits: the semantic layer (wrong domain context), the procedural layer (wrong sequence), the references layer (wrong template), or the episodic layer (a missing precedent). That diagnostic capability is what turns the operating system from a one-time deliverable into something the team can maintain, refine, and extend without us.

We teach the methodology in full. Everyone on the team ends up understanding how an intake works, how a deconstruction template gets built, why knowledge files are structured the way they are, and how to create all of it from scratch.

Then we give the team a choice: build the scaffolding yourselves, or use the workflow templates we've already prepared. Both paths get you to the same operating system. Most teams go with the prepared templates, because the day-to-day work doesn't stop just because the Sprint is running, and the real value is in the operating system the team produces, not in the hours spent rebuilding the scaffolding around it. The templates are fully transparent, so the team can open them up, read every line, see exactly how they work, and adapt them to their own context. Over time they turn into the team's own tools.

The Sprint is intensive. It works because the team puts in real time and attention building something they'll actually use every day: completing the intake by the deadline, showing up for the build sessions, working on assigned tasks between sessions.

Leadership support is the other half of it. When the team's lead makes clear that this is a priority, and that the time people put in is expected and valued, things move. Without that, even the best methodology stalls.