AI Practice Sprints

The substantive mechanism of the Sprint is a structured knowledge architecture. We organise the knowledge a workflow actually runs on into four distinct layers a frontier AI model can use reliably.

Semantic. The domain knowledge that does not change case by case. The principles, the rules, the definitions, the regulatory frameworks the work sits inside.

Procedural. How the team 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 uses to do the work.

Episodic. What happened before. Past cases and decisions, the precedent library, prior outcomes and the reasoning behind them.

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

A Sprint runs in two distinct 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 them with the team. Where workflows overlap, a single semantic layer serves many. Where they diverge, each member builds their own procedural layer on top. The result is one shared operating system the whole team uses, maintains, and extends.

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 people. The engagement runs in two parts. The first one to two weeks: mapping the workflow with the people who run it today, collecting the relevant policy and process artefacts, surfacing the decision logic experienced people apply in practice, settling the design choices that shape the build, and producing a build plan. The following two to four weeks: building the working components, iterating with the team, testing on real cases, running a structured pilot. The output is a working workflow, demonstrably running end to end on real material.

Either shape, the engagement is between three and six weeks. The faster end works where the team can concentrate effort early. The longer end allows for the reality of competing priorities and is the more common pace.

A kickoff workshop opens the Sprint, two hours at the minimum, four hours where a wider audience joins for the same opening. Every team member leaves the kickoff with a structured intake assignment and a deadline.

Week one is intake and architecture. Each member of the team completes the intake, either self-built or with the template we provide, capturing their tasks, processes, and decision patterns in a form ready to be deconstructed. The first build session shows the team how their own intakes translate into structured AI workflows. Live, on their own material. Existing prompts and assistants are reviewed. What works stays. What is fragile is rebuilt properly.

Weeks two and three are build and integration. Structured knowledge files for each layer of the architecture. Prompt frameworks. Quality checklists for the prioritised workflows. Every workflow built on real cases from the team's actual work, not hypothetical exercises. Ongoing support throughout: build sessions with the full team, one-on-one coaching where individuals are stuck, asynchronous feedback on work in progress.

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

We teach the methodology in full depth. Every member of the team understands how an intake works, how a deconstruction template is built, why knowledge files are structured the way they are, and how to create all of it from scratch.

We then offer the team a choice. Build the scaffolding yourselves, or use the workflow templates we have prepared. Both paths lead to the same operating system. Most teams choose the prepared templates, because the day-to-day work does not stop during the Sprint and the value sits in the operating system the team produces, not in the hours spent rebuilding the scaffolding around it. The templates are fully transparent. The team can open them, read every line, see exactly how they work, and adapt them to their context. Over time they evolve into the team's own tools.

The Sprint is intensive. It works because the team invests real time and attention into building something they will use every day. Completing the intake by the deadline. Attending the build sessions. Working on assigned tasks between sessions.

Leadership support is the other half of that. When the team's lead communicates clearly that this is a priority, and that the time invested is expected and valued, the work moves. Without that, even the best methodology stalls.