nestonexHow we scope a generative AI integration in discovery
Most AI estimates are guesses because the task was never bounded. This is what we settle in discovery, in the order we settle it, and why an integration priced before these answers exist will be priced wrong in one direction or the other.
Settle five things: the single task the system must do, what it should refuse or hand to a person, what material it may read and under whose permissions, who reviews output where the action has consequences, and the twenty-odd real requests that will form the evaluation set. An estimate before those exist is a number without a scope attached.
One task, stated narrowly
The first question is not what the AI should do but what one job it must do well enough to be worth shipping. Answer questions about our product documentation. Extract these eight fields from these supplier invoices. Draft a first-pass reply to this category of support ticket.
Briefs that arrive as an assistant for the whole company cannot be estimated, because they cannot be evaluated. There is no set of cases that would demonstrate success, so there is no point at which the work is finished.
Narrowing is not lowering ambition; it is making the first release checkable. A bounded assistant that works earns the right to a second one. A broad one that nobody can assess gets quietly abandoned, and takes the appetite for the next attempt with it.
- One task, in a sentence, with a verb
- What success looks like for that task specifically
- What is explicitly out of scope for the first release
Answer, refuse, or escalate
The second question is what the system does when it should not answer. Every useful AI feature has three outputs, not one: an answer, a refusal, and a hand-off to a person.
Deciding this early changes the architecture. A feature that may refuse needs a retrieval confidence threshold and an interface that makes a refusal look deliberate rather than broken. A feature that escalates needs somewhere to escalate to, and someone whose job includes receiving it.
Teams that skip this get a system that answers everything, including the things it should not, which is the failure most likely to end up in front of a regulator or on social media.
Data access, and whose permissions apply
Which material may the system read, in what state is it, and who is allowed to see what? Retrieval inherits whatever ambiguity exists in the answer, and then amplifies it, because a search surfaces things a person would never have thought to open.
Source quality is the largest single driver of effort. Clean, current, well-structured material makes retrieval look easy. A decade of inconsistent documents across three systems with contradictory versions is the project, and an honest estimate needs somebody to have looked at the real corpus rather than a description of it.
Provider terms belong here too: pricing per token, data-retention policy, regional availability, and rate limits. A retention clause can rule out an approach entirely, which is much cheaper to discover in discovery than in legal review.
- The real corpus, inspected rather than described
- Who may see what, enforced at retrieval rather than in a prompt
- Provider retention, region and rate limits, checked early
The review path, before the model
Where an output has cost or consequence, someone needs to see what the system decided and be able to override it without filing a ticket. That design belongs in the scope, not in a later hardening phase.
Reading is cheap to make safe. Writing is not. Every action the system can take needs a schema, a limit, and a decision about whether a person approves it, and that work scales with the number of actions rather than the number of prompts. It is the single clearest driver of the estimate.
If the system can act on text it did not write — a document, an email, a message — assume that text is trying to steer it, and design so that a successfully manipulated model still cannot exceed the limits.
What moves the number
Source quality and volume. Whether permissions already exist in the host application or have to be built. The number of write actions. Whether an evaluation set can be assembled from real usage or has to be constructed. And whether anyone on the client side can make a decision about acceptance criteria.
We will also say when the answer is not a language model. If the task is deterministic, a rule is cheaper, faster, inspectable and testable, and we would rather propose that than sell something more impressive.
What you should expect from a proposal: the deliverables, the acceptance criteria in observable terms, who owns the prompts and the evaluation set afterwards, and what the operating cost looks like at your expected volume.
Questions people also ask
How long does discovery for an AI integration take?
Usually one to three weeks, and most of it is spent on the corpus and the permissions rather than on the model. Where the data is clean and the permissions already exist in the host application, it is short. Where nobody can say who may see which document, that question is the discovery.
Can you estimate without seeing our data?
Only as a range wide enough to be useless. Source quality is the largest single driver of effort, and it cannot be assessed from a description. A short paid discovery that inspects the real corpus produces a number both sides can stand behind.
What do we need to bring to the first conversation?
The task in a sentence, a sense of where the material lives, who is allowed to see what, and who can approve acceptance criteria. You do not need a specification, a model preference, or a decision about retrieval.
Will you tell us if we do not need AI?
Yes, and before a proposal rather than after an invoice. If a rule, an existing tool or a better-designed form meets the requirement with less operational risk, that is the recommendation with the reasoning written down.