How to Brief an AI Vendor or Agency Without Wasting Everyone's Time

Most AI project failures can be traced back to a bad brief. Vague requirements, undefined success criteria, unclear data access, and misaligned expectations on both sides. The vendor builds what they understood; you needed something different. Six weeks and a significant budget later, you’re back at the start.

Here’s how to write a brief that sets AI projects up to succeed.

The Difference Between a Tool Brief and a Project Brief

Two types of engagements require briefs:

Tool evaluation brief: You’re evaluating an AI vendor’s platform for internal use. The brief outlines your use case, your data environment, your success criteria, and what the pilot structure looks like.

Project brief: You’re hiring an AI vendor or agency to build something — an automation, a custom model, an AI-powered feature. The brief is the specification for what you’re commissioning.

The stakes are different. A tool evaluation brief is about buying well. A project brief is about building well. Both require rigor; project briefs require significantly more.

The Core Brief Structure

1. Problem statement (not solution statement)

Describe the problem you’re solving, not the solution you think you need. “We need an AI that generates social posts” is a solution statement. “Our social media manager spends 12 hours per week writing posts that perform inconsistently, and we’re producing fewer posts than our competitors” is a problem statement.

Vendors and agencies are better at finding solutions when they understand the problem. Anchoring to your solution assumption limits their thinking — and your options.

2. Current state and what’s been tried

What does the current process look like? What have you tried? What worked and what didn’t? This prevents vendors from proposing things you’ve already ruled out and helps them understand the real constraints.

3. Success definition

How will you know the project succeeded? Not “the AI works” — specific, measurable outcomes. “The social media manager’s weekly post production time decreases from 12 hours to 4 hours, while maintaining or improving current engagement rates.”

If you can’t define success specifically, you can’t evaluate a project outcome. Take the time to do this before writing the brief.

4. Constraints

What are the hard limits?

• Budget (range, not exact — but don’t make vendors guess if there’s a real ceiling)
• Timeline
• Data access (what systems can they access, and under what conditions?)
• Privacy and compliance requirements
• Technical environment (what tools, APIs, and platforms are in scope?)
• Integration requirements (what does it need to connect to?)

5. Data and input description

AI projects live and die on data quality and availability. Be specific about:

• What data exists and where it lives
• What format it’s in
• How much of it exists
• What the quality is like (clean/messy, complete/partial)
• What access the vendor will have

Vendors who don’t ask about your data before scoping a project are winging it.

6. What “done” looks like

Define the deliverables explicitly. Not “a working AI solution” — “a trained classification model deployed in our HubSpot instance that scores incoming leads within 60 seconds with 85%+ accuracy, documented for our internal team to maintain.”

The Evaluation Questions That Reveal Real Capability

When reviewing vendor responses to your brief:

• “Walk me through a similar project you’ve done. What were the inputs, the process, and the specific outcome?” (Real case > demo)
• “Where do projects like this typically go wrong? What will you do to prevent those failure modes?” (Self-awareness is a signal of experience)
• “What does maintenance look like after launch? Who owns it — us or you?” (Many AI projects require ongoing maintenance that isn’t priced into the initial scope)
• “What’s your approach if the model performance doesn’t hit the success metric we defined?” (How do they handle failure?)

The vendor who asks you hard questions back — about your data, your current process, your real constraints — is usually the better choice over the one who responds confidently with a proposal before they fully understand your situation.

Protecting Yourself Contractually

AI projects have specific risks that standard vendor contracts don’t address:

• Model performance benchmarks — If the project brief defines a performance standard, the contract should include it and define what happens if it’s not met.
• Data ownership — Who owns the data used to train the model? Who owns the model?
• Privacy provisions — How is your data stored, processed, and protected? Is it used for the vendor’s training purposes?
• Change order process — AI projects frequently evolve as the data reality becomes clear. Define how scope changes are handled before they happen.

A vendor who won’t put performance standards in the contract doesn’t believe their own projections.