Agencies that build AI automations, RAG systems, and agent workflows usually do not lose margin because the first demo was hard.
They lose margin earlier:
- the client goal is real, but the first milestone is too wide;
- the source material is not ready for retrieval;
- the team agrees to "automate the workflow" before naming the approval gate;
- the quote assumes clean inputs and discovers messy edge cases after the kickoff;
- the implementation team inherits a scope that was sold as simple.
The expensive part is not always implementation. Sometimes it is realizing, too late, that the project should have been narrowed before anyone touched the build.
A useful pre-build review
Before an AI automation or RAG build starts, I like to reduce the scope to four written questions.
1. What is the first paid milestone?
Not the whole product. Not the full system. The first paid milestone.
A good milestone has:
- one workflow or knowledge area;
- a clear input;
- a clear output;
- a human approval point;
- a reason it is valuable even if later automation is delayed.
If a team cannot describe that milestone in plain language, implementation will probably absorb the ambiguity.
2. What should stay human-approved?
AI projects often fail because the team only lists what should be automated.
For scoping, the more useful question is:
What should not be automated yet?
Examples:
- final customer replies;
- financial approvals;
- policy exceptions;
- code merges;
- regulated decisions;
- anything where a bad answer creates a support, legal, security, or reputation problem.
This is not anti-automation. It is how a workflow becomes shippable.
3. Are the sources ready?
For RAG projects, weak source readiness shows up as model problems later.
Before building, check whether the source set has:
- stable owners;
- enough coverage for expected questions;
- outdated or conflicting docs removed or labeled;
- examples of questions that should be refused;
- a small evaluation set;
- a process for updating sources after launch.
If the documents are not ready, the correct first milestone may be source cleanup, not retrieval.
4. What failure modes change the quote?
Some failure modes are tolerable. Some change the delivery plan.
Examples that should affect scope:
- the workflow needs private credentials or production access;
- the client cannot provide redacted examples;
- retrieval has to work across conflicting sources;
- the output will be used without human review;
- the system must integrate with brittle internal tools;
- success depends on data the team does not actually control.
Those are not reasons to reject every project. They are reasons to price, sequence, or narrow it differently.
A simple async review format
For agencies, a useful second pass can stay small:
- scope summary;
- first milestone recommendation;
- readiness gaps;
- failure modes;
- approval gates;
- go / narrow / defer recommendation.
It does not need calls, production access, or client credentials. A redacted brief is usually enough to catch the big mistakes before a team commits build time.
I put together a page for this exact use case:
https://mindtrovertlabs-sketch.github.io/scopegrade-storefront/agency-partner-review.html
There is also a free preview of the checklist style here:
https://mindtrovertlabs-sketch.github.io/scopegrade-storefront/preview.html
The main point: AI agencies do not need more enthusiasm in the scoping stage. They need a written way to decide what is safe to fund first.
Top comments (0)