5 min read

Three weeks to a permanent system: how the diagnostic sprint works

Most AI engagements begin with a lengthy discovery phase and end with a report. The Verum diagnostic sprint ends with a running system and a team that knows how to use it. Here is what happens in each of the three weeks.

The standard pattern for technology engagements in Indian mid-market companies goes like this: a consulting firm runs a discovery phase, produces a report, recommends a large implementation, quotes a number, and then the project stalls in procurement.

The Verum sprint is designed to break that pattern.

Three weeks. One fixed scope. A running system at the end. The client owns the code.

Why three weeks is the right unit

Three weeks is long enough to understand a business deeply and short enough to stay focused on a single workflow problem. It forces both sides to prioritise.

A twelve-week engagement can expand. A three-week sprint cannot. That constraint is a feature, not a limitation.

It is also the right window for a proof of value. After three weeks, you either have a system that is visibly useful or you have learned something important about the problem. Neither outcome is wasted.

Week one: discovery and data mapping

The engineer is on-site with your team from day one. Not in a conference room with a questionnaire. In the room where the work happens.

The goal of week one is to map every data source that touches the target workflow. Where does the data live? What format is it in? How stale is it when it arrives at the person who needs it? Who makes decisions based on it, and what do they actually need to know?

By the end of week one, the team has a complete picture of the visibility gaps: the points where data exists but does not flow, where decisions are made on approximations, and where the operational and financial cost of that lag is highest.

The output is a gap map, not a PowerPoint. It is a structured document that becomes the technical specification for weeks two and three.

Week two: deep analysis and proof of concept

Week two moves from mapping to building. The engineer selects the highest-value gap from the map, the one where a working agent would have the clearest operational impact, and builds a working proof of concept against your actual data.

This is not a demo. It is a system running against your production data, in your environment, showing you what the gap looks like when it is closed.

The analysis in week two also produces the financial case: what is the operational improvement worth at your revenue and margin levels? At 1% PAT on ₹15,000 Cr, a 0.1% improvement is worth ₹15 Cr. The sprint quantifies what is actually at stake.

Week three: executive presentation and agent deployment

The final week has two outputs.

The first is an executive presentation: five to seven slides that show the gaps, the value at stake, and a full roadmap of agents that would close them. This is the brief that the leadership team can act on.

The second is the first agent running in production. Not a proof of concept. The real thing, deployed, documented, and handed to your team with training.

The engineer’s job in week three is to make themselves unnecessary. By the end of the sprint, the agent runs without the engineer in the building. The client’s team understands how it works, how to adjust it, and how to extend it.

What you have at the end

After three weeks you have:

  • A complete map of your visibility gaps
  • A quantified view of the value at stake
  • A running agent that closes the most important gap
  • A roadmap for the next agents
  • Code and documentation that belong entirely to you

You do not have a dependency on Verum. You have a system that runs on your infrastructure, operated by your team. Future engagements are your choice.

That is the sprint. If you have a workflow problem that fits, it is worth three weeks to know what you are dealing with.

Ready to fix a workflow?

Tell us the problem. We'll tell you if we can help, within two business days.

Book a discovery call