An accurate quote for a custom AI project comes from a brief that answers five questions: what business outcome you want, what data you actually have, what a wrong answer costs you, which systems the agent must read from and write to, and what constraints are non-negotiable. Everything else, including the model, the framework, and whether it is "an agent" or "a workflow", is the agency's job to propose. Founders who send a two-page problem statement get a number. Founders who send a feature list or a vague "we want AI in our product" get a range so wide it is useless, or a lowball that gets renegotiated in month two.
Why most AI briefs produce bad quotes
A software agency prices risk. Every unknown in your brief gets converted into either a padded estimate or an optimistic one that falls apart when the real data shows up. AI projects have more unknowns than ordinary software because the hard part is rarely the code. The hard part is the data, the edge cases, and deciding how good is good enough.
The three most common brief failures we see:
- Solution instead of problem. "Build a RAG chatbot over our docs with GPT and a vector database." The agency now has to reverse-engineer what you actually need, and often the prescribed design is the expensive one. We have been on the receiving end of this ourselves: the multi-step chain we assumed for our own outreach engine lost to a single call on both cost and quality, and a brief that had prescribed the chain would have locked in the worse design. We cover why this matters in RAG vs fine-tuning for founders.
- No definition of correct. "It should answer customer questions accurately." Accurately compared to what? Who checks? What happens when it is wrong? "Right nine times out of ten and flags the rest for a human" is a definition. "Accurate" is not.
- Integrations mentioned in passing. "It should also update the CRM." That sentence can double a project. An agent that drafts a CRM note for a human to approve and one that changes deal stages on its own are different builds, and the brief usually does not say which one is meant. Authentication, rate limits, field mapping, and failure handling for a third-party system are real work.
Fix those three and the quote you get back will be close to what you end up paying.
The five sections your brief needs
1. The outcome, in business terms
One paragraph. Not "an AI assistant" but "reduce time-to-first-response on inbound support from hours to under two minutes, without increasing escalations to the human team." A measurable outcome lets the agency propose the cheapest design that hits it, instead of the most impressive one.
Include the volume. Fifty requests a day and fifty thousand a day are different systems with different cost structures. If you do not know, give your best guess and say it is a guess.
2. The data you actually have
This section decides more of the price than anything else. Be specific and be honest:
- Where it lives. Postgres, a Google Drive full of PDFs, a legacy CRM with an export button, WhatsApp threads on someone's phone.
- How much and how clean. Ten thousand well-structured records is a different job from two hundred scanned forms in three languages.
- Who owns it and whether it contains personal data. If the project touches EU residents' data, say so. The agency has to design for GDPR from day one, not retrofit it.
Attach a redacted sample. Twenty rows or ten documents is enough. No serious agency can estimate extraction or retrieval work from a prose description of data, and any that claims to is guessing.
3. The cost of a wrong answer
This is the question founders skip and agencies most need answered. An AI feature that suggests blog tags can be wrong a quarter of the time with no consequence. An agent that quotes prices to customers or files insurance claims cannot.
State, in plain language:
- What happens when the output is wrong. Embarrassment, a refund, a regulatory problem, a patient safety issue.
- Who catches it today. A human reviewer, nobody, the customer.
- What error rate you would accept at launch. Even a rough figure helps. "If it is right nine times out of ten and flags the rest for a human, that beats what we have."
This single section determines whether the agency designs a cheap system with a human in the loop or an expensive one with layered verification. Our piece on deterministic guardrails for AI features explains why the second kind costs more and when it is worth it.
4. Systems the agent must touch
List every system the AI must read from or write to, and for each one: do you have API access, who administers it, and is there a sandbox. Writing is more expensive than reading. An agent that drafts a CRM note for a human to approve is a smaller project than one that updates deal stages on its own.
If a system has no API, say that too. Browser automation and screen scraping are possible but they are a different line item, and they break more often.
5. Hard constraints
Things the agency cannot trade away:
- Data residency. Must stay in the EU, in Saudi Arabia, on your own servers.
- Budget per request or per month. A ceiling on inference cost shapes model choice immediately.
- Latency. A WhatsApp reply can take four seconds. A voice agent cannot.
- Timeline and what is driving it. A trade show date is a real constraint. "ASAP" is not.
- Legal or disclosure requirements. If customers must be told they are talking to a machine, say so.
Keep this list short. Every item here removes design options, and some of those options were the cheap ones.
What to leave out
The architecture. Do not specify the model, the vector database, the orchestration framework, or how many steps the pipeline should have. When we built our own outreach engine, which scrapes each prospect's website with a self-hosted crawler and drafts one tailored email with a local model, our starting assumption was a multi-step chain: one call to extract facts, another to plan, another to write. The version that won on both cost and quality was a single call that extracted the facts and drafted the email together. Had a client prescribed the chain in their brief, we would have built the worse system and charged more for it. Let the agency propose, then challenge the proposal.
A long feature list. Features without priority get priced as all mandatory. If you must list them, mark three as launch-critical and the rest as later.
Competitor screenshots as the spec. Useful as reference, dangerous as requirements. You end up paying to replicate someone else's compromises.
What a good agency will do with your brief
Take the support example from section one. A brief that says "under two minutes to first response, current volume roughly five hundred tickets a day, right nine times out of ten with the rest flagged to a human, must draft but not send, EU data only" should get back, within a week or two, a proposal that reads like an answer to those exact lines: a recommended approach with the reasoning, a pilot scope (perhaps one ticket category, drafts only), a cost broken into build, inference at your stated volume, and ongoing maintenance, and a proposed way to measure the two-minute target and the one-in-ten error rate before you pay for the full build. If the response is a single number with no assumptions listed, the agency did not read the brief. If it is a thirty-page deck that never mentions your data sample, same conclusion.
You should also expect questions back. Good agencies push on the cost-of-wrong-answer section and on the integrations, because that is where the real estimation risk lives. Expect to be asked who reviews the flagged tenth today, and whether the CRM has a sandbox. Agencies that ask nothing are either very experienced in your exact problem or planning to discover the problems on your invoice.
Before signing, use how to vet an AI agency demo to pressure-test what they show you, and make sure the success metric from section one makes it into the contract. Agreeing on how the system will be evaluated before the build starts is the cheapest insurance you can buy.
A template you can copy
1. Outcome: what changes for the business, with a number and a volume.
2. Data: where it lives, how much, how clean, personal data yes/no. Sample attached.
3. Cost of wrong: what happens, who catches it today, acceptable error rate at launch.
4. Systems: each one, read or write, API access yes/no, sandbox yes/no.
5. Constraints: residency, cost ceiling, latency, hard dates, disclosure rules.
6. Not in scope for v1: the things you are consciously deferring.
Two pages, plus appendices. It takes a founder an afternoon to write and saves weeks of back-and-forth, or a project that quietly doubles in price.
If you have a brief half-written and want a second pair of eyes before sending it to anyone, or you would rather talk the problem through first, let's talk.
Originally published on the Pykero blog.
