Most quotes for a short AI build describe an outcome and leave the engineering implied. That is where the disappointment comes from. A sprint that works has four parts, a contract written down before anyone opens an editor, and a handoff you can hold. Here is what should be in it.
Written for owners, founders and operations leads who have already picked the painful workflow and now have to judge what a two or three week build should actually contain.
Scope
The word sprint has been stretched to cover everything from a two week build to a six month program with a standup. The version that works for a small team is narrow on purpose: one workflow, one entrance, one output, one review point, shipped in weeks rather than quarters.
The reason is not modesty. It is that a bounded build can be tested. You can say what good output looks like, assemble examples where you already know the right answer, and check the system against them before anyone depends on it. A program that touches six processes at once cannot be checked against anything, so it gets judged on the demo, and a demo proves only the happy path on data somebody chose.
This article assumes you have already chosen the workflow. If that part is still open, choose it first. Picking the wrong process carefully is more expensive than building the right one sloppily. We wrote the selection method up separately in your first AI project is probably not a chatbot, which covers the candidate tests and a scorecard for ranking three workflows against each other.
The build
Almost every useful automation of language-heavy work has the same skeleton, whatever the workflow and whatever the tools. If a proposal is missing one of these four, that is the question to ask about it.
One defined way for work to arrive: a form submission, an inbox rule, a file drop, a CRM event, an export, a ticket, or a button somebody presses on purpose. Version one should have exactly one. Every extra entrance doubles the error handling and halves the chance the sprint finishes. The input path is also where the data boundary is enforced, which means it is the part that decides what the system is even capable of seeing.
The prompt is the smallest part of this. The contract is what matters: which inputs the step may read, the exact output shape it must return, what it does when the input is incomplete, when it is required to answer that it does not know, which outputs have to carry a source reference, and which fields it is never allowed to invent. Write that down before the build. If it only exists inside a prompt, nobody can test it and nobody can change it safely.
The output has to land where the work already happens: a draft in the inbox, a note on the record, an item in the queue, a row in the sheet, a comment on the ticket. Not a separate dashboard nobody opens. The reviewer needs to see the output, the input it came from, and a way to correct it in one place. Corrections are not just a courtesy to staff. They are the only free source of test cases you will ever get.
The sprint earns its money at the moment a result stops being retyped. Update the field, attach the summary, create the task, post the internal notification, append the row. One or two connections, chosen because they remove a copy-paste step somebody does every day. Replacing the CRM is a different project with a different budget and it is not this one.
The part that gets skipped is the second one. A prompt that works on five examples in a chat window is not a contract. Without a written output shape, a defined behavior for incomplete input, and an explicit rule for when the system must say it does not know, you have a demo with a deployment URL. The difference shows up in month two, not in the review meeting.
Before the build
This is not a discovery phase and it should not become one. For one workflow it is a short document, usually a couple of pages, and it is the thing the build gets checked against. A sprint that starts without it spends its last week relitigating what it was for.
Note the sixth one. Writing down the current number before the build is the only way to say anything true about the result afterwards. It takes ten minutes at the start and it cannot be recovered later.
The line
Assist and decide are different scopes, different risks, and different prices. A first build should assist. That is not timidity, it is what makes the thing small enough to ship and safe enough for staff to adopt without being told to.
These should stay with a person, on any budget:
The useful question is not whether a person is in the loop. It is whether that person has enough in front of them to disagree. A review step that shows an answer with no source, no input, and no way to correct it is a rubber stamp with extra clicks, and it will be treated as one within two weeks.
Handoff
A sprint should not end with a walkthrough and a thank you. Ask for this list before the work starts, not at the end, because most of it has to be produced during the build to exist at all.
The test set and the failure behavior are the two that get left out most often and matter most. They are what let somebody else maintain the thing, including you, including a year from now. A build you cannot rerun a test against is a build you cannot safely change, which means it will be frozen and then replaced.
The handoff should also say what is not included. Production credentials, ingestion of regulated data, a public-facing chatbot, compliance certification, autonomous decisions, company-wide AI governance. If those were not scoped and priced, they are not in the sprint, and that belongs in writing rather than in a conversation nobody remembers the same way.
Afterwards
The sprint ends and the question changes. It stops being does it run and becomes is it still right. Three cheap habits answer that, and all three have to be set up during the build rather than bolted on later.
Rerun the test set on a schedule. Models change underneath you, providers adjust defaults, and your own documents drift. A test set you can rerun in minutes turns a silent degradation into a failed check. Without one, you find out from a customer.
Count the corrections. If the reviewer edits the output, log it. The correction rate is the most honest quality signal a small team will ever have access to, and a rising rate in one category is usually the first visible sign that something upstream changed.
Compare against the number you wrote down. Response time, missed follow-ups, hours spent retyping, documents returned for missing information. Four weeks of the new number against the old one is enough to know whether the next build is worth doing, and honest enough to tell you when it is not.
Not yet
Sometimes the workflow is real, the pain is real, and the build is still the wrong next move. These are the ones worth catching before money is committed.
Not a sponsor who approved the budget. An owner, the person whose week gets measurably better or worse, who will look at the output every week and say whether it is any good. Without one, the build is delivered, praised, and quietly stops being used by the second month.
A retrieval step over documents that disagree with each other will answer confidently and wrongly, and it will be blamed on the model rather than on the documents. If two policies conflict, fix that first. It is cheaper than any build and it is the actual problem.
If the answer is better or faster with no number behind it, there is nothing to scope against and nothing to check afterwards. Pick the number before the build. Any imperfect number beats none, because it forces the conversation about what the work is for.
Some workflows hurt because two teams duplicate a step, or because a form asks for the wrong things, or because a handoff has no owner. Automating around that preserves the problem and makes it harder to see. A review worth paying for will tell you this and recommend not building.
Patient records, financial account data, employee files, production credentials. This is not a no, it is an order of operations. The boundary and the handling terms get written and signed before the data moves, and the thing you learn on should not be the thing carrying the risk.
The stale-or-contradictory source material problem shows up constantly in one specific shape: a “chat with our documents” assistant built before anyone agreed which documents it is allowed to use. We wrote that one up separately in a company document assistant is only useful if it knows its boundaries, which covers the boundaries a document assistant needs before staff should trust it.
Send the workflow, or the proposal you have been handed. You get back a written review: the four parts that are missing, the data boundary, what should stay human, the test set the build needs, and what to build first. Five business days from access. If the honest answer is that the process should be fixed rather than automated, the review says that.
Reviews start at $500, fixed price agreed in writing before any work starts.
No secrets, credentials or confidential records through this form.