How Founders Should Brief an Agency for an AI Workflow

What Does a Brief for an AI Workflow Agency Need to Include?

A brief for an AI workflow needs six things nailed down before any agency can scope it honestly: the business problem in plain numbers, current-state metrics, every system and data source involved, the exact output format, where human approval sits, and the metric that proves the thing worked. Cmeo Labs frames this as mapping the unknowns agencies price against, because vague inputs produce vague quotes.

Skip any of these and the agency fills the gap with assumptions, and assumptions are where budgets blow up. A brief that only says "automate our support tickets" tells an agency nothing about volume, format, or what a correct answer even looks like. Spell out what each of these six things looks like for your specific workflow, and the agency knows exactly what it's pricing.

The six items, in the order they actually matter:

• The specific process that's broken, with a cost attached
• Volume, team size, and error rate today
• Every system and data source the automation will touch
• The exact output, its format, and where it lands
• Which actions stay human and which don't
• The number that defines "it's working" after launch

Everything downstream in this guide breaks each of those six down into what to actually write.

Should You Start With the Business Problem or the AI Tool You Want?

Start with the problem. A problem-first brief describes the broken workflow and its cost before naming any technology; a tool-first brief opens with "we want a chatbot" and asks the agency to reverse-engineer a use case to justify it. The second approach produces proposals built on guesses, not your actual workflow.

RAND Corporation research found that more than 80% of enterprise AI projects fail to deliver intended business value, a finding TechRadiant's agency-evaluation research ties directly to proposal-stage decisions rather than late surprises. Gartner adds a sharper warning for the brief itself: 60% of AI projects built on data that isn't AI-ready will be abandoned through 2026, per the same TechRadiant research. If you lead with a tool name, the agency never gets the chance to tell you your data isn't ready before you've paid for the build.

What Current-State Numbers Does the Agency Need From You?

Five numbers make an AI workflow brief scopeable: volume, cycle time, team size, error rate, and cost per unit. Without them, an agency can't measure the problem it's being asked to automate, and the proposal defaults to a generic estimate rather than a plan built around your actual workload.

1. Volume: how many units move through this process per week. Sagnik Bhattacharya's write-up on briefing a developer for a custom AI workflow uses a real example: a lead-intake workflow handling about 45 leads a week.
2. Cycle time: how long the manual version takes. That same 45-lead workflow ran about six hours a week by hand, according to Bhattacharya's breakdown.
3. Team size: who touches the process and how many people are involved at each handoff.
4. Error rate: how often the manual process produces mistakes, missed steps, or rework today.
5. Cost per unit: what each item costs in labor time. A separate print-shop example in the same analysis processed 84 items in one week at roughly 11 hours of manual work.

These five numbers are also the exact inputs used to rank and prioritize which workflow to automate first, which this scorecard for choosing your first AI workflow walks through in more depth.

What Systems and Data Sources Belong in the Brief?

Every tool, API, and data source the workflow touches belongs in the brief, named specifically, with a confirmation that access is actually possible. Design Odin found that data quality problems cause 43% of AI project failures, and unclear integrations or messy data are what turn a fixed quote into an expanding one.

List what applies: CRM tools like HubSpot, Salesforce, or Pipedrive; email systems like Gmail or Outlook; scheduling tools like Calendly, Cliniko, or OpenTable; project tools like Asana, Monday, or Notion; communication platforms like Slack or Teams; finance software like Xero or QuickBooks; and, where relevant, an ERP, Shopify, Zendesk, Google Workspace, or AWS S3. Then say explicitly what's off-limits, so the agency can't widen the integration later and bill it as new scope.

Data structure changes the price more than most founders expect. Cmeo Labs puts a number on it: a pile of PDFs sitting in a shared Google Drive instead of a structured document store with a working REST API can add $30,000 to $80,000 in data preparation and engineering work before the actual automation gets built. That gap is scoping work, not AI work, and it's invisible until someone writes it into the brief. For a breakdown of which workflows to stack once the data side is sorted, see AI workflow automation for SMBs that can't hire ops.

How Do You Define the Output, Format, and Destination?

The output needs a defined format, a destination, and a run frequency, stated explicitly in the brief rather than left for the agency to infer. "Automate invoice processing" doesn't say whether the result lands as a line item in QuickBooks, a PDF emailed to a client, or a row in a spreadsheet, and those are three different builds with three different price tags.

Name all three explicitly:

• Format: a structured record, a generated document, a dashboard update, a message sent to a person
• Destination: the exact system or inbox the output lands in
• Frequency: real-time, hourly batch, nightly run, or on-demand trigger

Design Odin's review of scope creep in AI briefs shows what happens without this: a project quoted at £18,000 grew to a £40,000 engagement because the original brief never pinned down what "done" looked like. Leaving output undefined is a common way a fixed-price quote turns into an open-ended one, because ambiguity tends to get resolved in the agency's favor by default, not yours.

Where Should Human Approval Stay in the Loop?

Human approval points are architecture decisions that belong in the brief, not something added after the build. The brief should state, action by action, what the AI can do on its own and what must route to a person first, since Design Odin treats this distinction as core to scoping an AI workflow correctly.

Lay it out as a short checklist the agency can build against:

1. List every action the workflow takes: drafting a reply, updating a record, sending a payment, scheduling a meeting.
2. Mark each one autonomous or reviewed. A drafted email waiting for approval is a different build than an email sent automatically.
3. Define the fallback. State what happens when the AI isn't confident: route to a human, flag for review, or default to a safe no-op.
4. Name the exception path. Specify who gets the escalation and how fast it needs a response.
5. Revisit the gate after launch. Some actions that start reviewed can move to autonomous once accuracy holds up over a defined stretch of real runs.

Getting this wrong in either direction is expensive: too much human-in-the-loop and the automation doesn't save the hours you built it for; too little and a bad output goes out the door before anyone catches it. The tradeoffs are similar to the ones covered in how to replace a VA with an internal AI workflow, where the same question comes up for admin work specifically.

How Many Edge Cases and Real Examples Should You Attach?

Twenty to thirty real examples, including the awkward ones, belong in every AI workflow brief, not just the clean cases that happen most of the time. Sagnik Bhattacharya's guide to briefing a developer on a custom workflow names this range specifically, because a build designed only against the happy path breaks the first time a real customer does something unexpected.

Build the attachment out like this:

1. Pull 20 to 30 real records from the actual workflow, including the messy ones: a malformed email, an ambiguous request, a duplicate entry.
2. Attach the SOP, if one exists, even an informal one. It tells the agency the rules a human follows today that the AI needs to inherit.
3. Include screenshots of each system touchpoint so the agency sees the actual interface, not just the tool's name.
4. Provide sample inputs and outputs side by side: the message as it arrives, and exactly what a correct response looks like.
5. Flag the ones that currently require a judgment call. Those are the cases most likely to need a human-in-the-loop gate, which ties straight back to the approval rules above.

An agency that gets the clean cases and the awkward ones up front scopes the project once. An agency that only gets the clean cases discovers the awkward ones mid-build, and that's when timelines slip.

What Budget, Timeline, and Compliance Constraints Belong in the Brief?

A complete AI workflow brief states three constraints upfront: a total build budget range, a monthly running-cost ceiling, and a timeline, plus any compliance rules the workflow has to respect. Sagnik Bhattacharya's framework for briefing a developer on a custom AI workflow calls out the running-cost ceiling specifically, since model usage, API calls, and storage add an ongoing bill on top of whatever the build itself costs.

• Total build budget. The one-time range you're willing to spend on the build itself, separate from what it costs to run afterward. Design Odin's example of a project that grew from £18,000 to £40,000 shows what happens when this range never gets written down in the first place.
• Monthly running cost ceiling. Model usage, API calls, and storage add an ongoing bill on top of the build, and a developer who doesn't know your ceiling will size the system for capability rather than for what you can actually afford to run every month.
• Timeline. State the date you need the workflow live, and whether that date is fixed by an external event or flexible.
• Compliance. If the workflow touches regulated data, name the framework up front: HIPAA for health information, SOC 2 for data-handling controls, GDPR for EU personal data, or PCI DSS for payment card data. Compliance rules shape architecture decisions, not just paperwork, so naming them early lets the agency design around them instead of working around them later.

For a sense of what these constraints actually do to a quote, AI app development cost: what founders actually pay breaks down the real pricing bands behind build and run costs.

How Long Should the Brief Be, and What Happens After You Send It?

Brief length depends on the audience: one to two pages for an executive summary agencies use to decide fit, and four to eight pages of technical appendix once you're ready to scope the actual build. Design Odin, Sagnik Bhattacharya, and Cmeo Labs each recommend a different length because they're answering different questions about who reads the brief and when.

Send the short version first. Once an agency is seriously evaluating the project, attach the longer technical detail, the systems list, and the 20 to 30 examples from the earlier section as an appendix.

The brief only does its job if it connects to what happens after you send it. Cmeo Labs gives a concrete model for a success metric that survives into a contract: 85% classification precision paired with a 40% reduction in senior-agent escalations within 90 days of launch. That's a number QA can test against and a report can measure later, not a vague "it's working."

The evaluation pace matters too. SFAI Labs found that a structured, unhurried evaluation process produces 3x higher partner satisfaction, while rushing evaluation correlates with a 2.5x higher failure rate, according to TechRadiant's review of that research. A brief written in an afternoon and sent to three agencies in the same week beats a brief that never gets written, but the agencies that take the brief seriously enough to ask follow-up questions before quoting are usually the ones worth hiring. More on what separates agency delivery from freelance delivery on exactly this point is in AI development agency vs freelancer: what ships faster.

Write the six-item version first, even if it's rough. A tighter second draft after a few follow-up questions from an agency will always beat a long brief with no feedback loop at all.