The quality of the quote you get from any AI development team is directly downstream of the quality of the brief you give them. A vague brief gets a vague, padded estimate, because the team pricing it has to account for unknowns they can't see. A specific brief gets a specific answer, and often a lower one, because a good brief removes the need to pad for uncertainty.
What a brief needs to actually answer
What problem, specifically, not what technology
"We want an AI agent" describes a technology, not a problem. "Our support team spends most of a shift answering the same handful of repetitive questions, and response time during peak hours is too slow" describes a problem. The second version lets a team scope a real solution; the first invites them to guess at one.
What systems it needs to touch, and how
Name the specific systems (which CRM, which database, which internal tool) and be honest about what you know and don't know about their API access. If you're not sure whether your scheduling system's API supports write operations, say so explicitly. Discovering that mid-build is one of the biggest sources of timeline slip we've seen.
What data exists, and its actual condition
If the system needs to reason over your existing data, describe it honestly: how much exists, where it lives, and whether you already know it's fragmented or inconsistent across systems. A brief that says "our data is a mess across three different tools" is more useful to a team scoping the work than one that omits this and lets them discover it later.
What "done" actually looks like
A specific, measurable definition of success (a target response time, a percentage of tickets handled without escalation, a specific task completed end to end) gives a team something concrete to scope against. "Make it smarter" or "improve efficiency" doesn't.
What's actually out of scope
Being explicit about what you don't need yet is just as useful as describing what you do. If you know you want to expand to multiple languages eventually but not in the first version, say so. That shapes the architecture differently than if multi-language support might be needed from day one.
What to leave out
You don't need to specify the technical architecture, which model to use, or whether the solution should be a single agent or multiple. That's the job of the team you're briefing. Prescribing it can produce a worse result if your assumption about the right technical approach turns out to be wrong once someone with real expertise looks at your situation.
Why this actually affects the quote you get
A team pricing a vague brief has to either pad the estimate to cover unknowns, or lowball it and risk a scope conversation later once the real complexity surfaces. Neither is good for you. A specific brief lets a team give you a number grounded in your real situation. If your first brief doesn't cover all of this yet, surfacing it is exactly what a good discovery conversation is for.
How we use a brief like this
We use whatever you send us as the starting point for a scoping conversation, not a fixed spec we quote against blindly. The more of the above you can answer upfront, the faster we can reach a grounded estimate, instead of spending the first part of discovery gathering the basics.