How to Brief an AI Agency So the Quote Is Actually Accurate

Posted on Oct 17 • Originally published at pykero.com

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.

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:

Fix those three and the quote you get back will be close to what you end up paying.

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.

This section decides more of the price than anything else. Be specific and be honest:

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.

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.

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.

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.

Keep this list short. Every item here removes design options, and some of those options were the cheap ones.

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.

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.

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. Enter fullscreen mode Exit fullscreen mode 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.