Celadon
ServicesAI Decision Sprint
Before build money is committed, the AI Decision Sprint determines which workflow has the strongest combination of business value, technical feasibility, organizational fit, and manageable risk — and whether it should be built at all.
Scope the first workflow →The common failure is not picking the wrong model. It is committing budget to a workflow that was never going to survive contact with real data, real permissions, and real users — and finding out nine months later.
A workflow can look obvious in a leadership meeting and still be a poor first build: the source documents contradict each other, the process differs by team, nobody owns the output, or the people expected to use it have no reason to change how they work. None of that shows up in a demo.
The Decision Sprint exists to surface those constraints while they are still cheap to act on, and to produce a defensible answer to a single question: what should we build first, and is it worth building at all?
What the workflow costs today in time, error, delay, or lost revenue — and what a realistic improvement is worth, stated as a range rather than a promise.
How the work actually happens: who does it, where handoffs break, which steps are judgment and which are retrieval, and how much the process varies by team.
Whether the documents, records, and systems that would ground the output exist, are current, are accessible, and agree with each other.
Whether the workflow can be supported with available integrations, permissions, latency budgets, and operational constraints — tested, not assumed.
Where the system could be wrong in a way that matters, who is accountable when it is, and what review, logging, and access control the workflow requires.
Whether the people expected to use it have a reason to, who owns it after launch, and what would have to change in the operating routine for it to stick.
The Sprint ends with a clear position, not a menu of options. If the strongest candidate does not justify the investment, Celadon will say so and explain what would need to change for the answer to be different. A recommendation to wait, to buy something off the shelf, or to fix a process problem before automating it is a legitimate outcome — and a cheaper one than discovering it mid-build.
Where AI could plausibly create value across the business, and where it could not.
Candidates ranked on value, feasibility, risk, organizational fit, and time to impact.
The state of the data, systems, permissions, and ownership the workflow depends on.
What the change is worth, what it will cost to build and run, and how it will be measured.
Whether this should be a vendor tool, a custom build, a process change, or nothing.
How data, retrieval, models, integrations, and controls would fit together in production.
How correctness gets defined and tested before launch, and monitored after it.
The phases, sequence, dependencies, and decision points that would take it to production.
Agree the business area in scope, the constraints that are fixed, and the specific question the Sprint has to answer.
Interview the people doing the work. Trace the actual path of a task, including the exceptions and workarounds nobody documents.
Examine the real documents and systems. Establish whether the knowledge a system would need is present, current, and consistent enough to rely on.
Evaluate each candidate against the six lenses, with the reasoning written down so the ranking can be challenged.
Present the decision, the business case, the architecture, and the costed path to production — or the case for not proceeding.
A Decision Sprint does not include working software. It is not a prototype, a proof of concept, or a demo environment. It is not a vendor selection exercise run on a vendor's behalf, and it is not an open-ended discovery retainer that expands to fill the calendar.
It also does not attempt to assess every function in the business at once. The Sprint is deliberately narrow: one business area, one decision, one recommendation, delivered in weeks rather than quarters.
The AI Decision Sprint is priced as a fixed fee in the $15,000–$40,000 range, set before work starts based on the number of candidate workflows, stakeholders, and systems that need to be examined. There is no hourly meter and no discovery retainer that expands to fill the calendar.
If the recommendation is to build and you proceed into a Celadon Build phase within 90 days of the Sprint ending, the Sprint fee is credited in full against that first Build phase. You are never paying twice for the same decision work.
A build cannot be priced honestly until someone has looked at the data, the integrations, and the failure modes. That is most of what the Sprint produces, which is why the implementation phase that follows can be quoted as a fixed fee against defined acceptance criteria instead of an hourly estimate.
There is no obligation to continue, and no commitment to Celadon as the implementer. The architecture blueprint, evaluation plan, and roadmap are yours, and they are specific enough for an internal team or another firm to execute against.
A focused conversation about the business problem, the systems involved, the constraints, and what would need to be true for AI to create measurable value.
A focused conversation about the business problem, the systems involved, the constraints, and what would need to be true for AI to create measurable value.