VolttiDiscuss your pilot

Prepare your AI agent pilot: a briefing in seven questions

Most AI agent pilots don't fail on the technology. They fail on the assignment. "The agent handles our customer questions" is not an assignment; it's a wish. A pilot that starts with a vague briefing usually ends up as a demo: nice to watch, but four weeks later nobody uses it.

This article contains a briefing in seven questions you can fill in today. It is written for businesses that have an AI agent built by a partner or set up in-house, and it works just as well if you build it yourself. Answer the questions with your team and bring the result to your first meeting: the sharper your answers, the more precise the quote and the smaller the chance of a pilot without a verdict.

Briefing document with seven questions for an AI agent pilot
Seven questions that make the difference between a pilot with a verdict and a demo.

Why a briefing works

An AI agent is not a ready-made switch you flip. It is software that performs a task within goals and boundaries you set upfront. Those boundaries are not defined during the pilot, but before it. In a ten-step plan for agentic AI pilots, Salesforce describes starting with one problem and one repeatable task, defining the agent's role clearly, and agreeing on guardrails and measurement points beforehand.

Research by RAND estimates that more than 80% of AI projects fail to meet their goals. Poor preparation and unclear goals are among the most common causes. A briefing addresses that partly because it does three things at once. It forces you to pick one task instead of five. It makes explicit what the agent may, can and especially may not do. And it gives your pilot an end date with a verdict: continue, adjust or stop.

QuestionWhat you defineWhat it looks like

Which task?

One recurring task with an owner

"Weekly report from project data"

Which sources?

Input and allowed data

"Project tool, read-only; no customer data"

Which output?

Concrete desired result

"One-page report in a fixed structure"

Which rights?

Tools and minimal access

"Read-only access to the sources"

When to stop?

Exceptions and boundaries

"Nothing gets sent without human review"

When good?

Acceptance tests and baseline

"Five correct reports in a row"

Who after?

Ownership and support

"Owner requests changes; partner provides support"

The seven questions explained

Below, each question explains why it matters and what input a good answer contains. The sample answers are deliberately concrete: a briefing you cannot fill in is a form, not an assignment.

  1. 01

    Which recurring task will you delegate?

    Pick one task that comes back regularly, runs more or less predictably and produces output you can check. "Something with email" is not a task; "remind about every open quote after three days" is. Write the task the way you would brief a new employee, exceptions included. How to spot suitable tasks is covered in our article on recurring tasks.

    Name the owner too: who in your company knows this task best and judges whether the agent does it well? A pilot without an owner is a pilot without a judge.

  2. 02

    Which sources and data may the agent use?

    Some data belongs in a pilot, some does not. State explicitly which systems the agent consults (project tool, CRM, email, document folder) and which data stays out of scope: personal data you don't need, financial details, anything under an NDA.

    Think about shape as well. Can the agent read the source as it is, or does data need cleaning first? Messy input is the most underestimated cause of disappointing pilot results.

  3. 03

    What does the desired output look like?

    Describe the result concretely enough to test it: a report of at most one page in a fixed structure, a draft email in your house style, a daily summary at 9 a.m. Add one or two examples of a good result, and optionally of a bad one.

    The sharper the output picture, the easier acceptance tests become later (question 6). Vague phrases about "better output" cannot be tested.

  4. 04

    Which tools and rights does the agent need?

    Map out which systems the agent works with and which rights come with them. Start small with minimal rights: separate accounts, read-only where possible, write access only where the task truly needs it. A reporting agent needs read access, not admin rights to your entire CRM.

    Ask a partner how they handle rights and whether connections to your existing tools are possible; our article on connecting AI to your CRM and CMS goes deeper.

  5. 05

    What are the exceptions and stop conditions?

    Every real task has edge cases. What does the agent do when a source is unreachable, when data is missing or when a customer asks something unusual? Define what the agent does then: skip, flag for human review or stop.

    Set hard limits as well: nothing gets sent without human review, no access to data outside the scope, no spending above a fixed amount without approval. Stop conditions protect your business and make the pilot safe enough to test for real.

  6. 06

    When is the pilot a success?

    Define upfront when you will call the pilot a success. Good acceptance tests are small and countable: five consecutive correct reports, checked by the owner. Record a baseline too: how long does the task take now, manually? Without a baseline you have nothing to compare against after the pilot.

    Set an end date and what happens next: continue, adjust or stop. One month with a verdict says more than a pilot that quietly keeps running.

  7. 07

    Who is responsible after the pilot?

    Who judges the results, who requests changes, who acts when the agent does something unexpected? And what support do you expect from your partner after delivery: updates, monitoring, availability when things break? How Voltti fills that in is described on our approach page.

    This question feels administrative, but it prevents a classic trap: a working agent nobody maintains anymore. Naming responsibility is the difference between an experiment and a service.

What a filled-in briefing looks like

  1. 01

    Task and owner

    "Every Friday, summarize the project status into a one-page report. Owner: the project lead."

  2. 02

    Sources and data

    "Project tool (read-only) and the shared document folder. No customer data, no financial data."

  3. 03

    Desired output

    "Report with fixed sections: status, risks, decisions pending. Sample report available."

  4. 04

    Tools and rights

    "Separate account for the agent, read-only access to the sources, no access to email."

  5. 05

    Exceptions and boundaries

    "The agent flags missing data; it fills in nothing. Nothing gets sent without human review."

  6. 06

    Acceptance tests and baseline

    "Five consecutive correct reports. Baseline: it currently takes 45 minutes a week manually."

  7. 07

    Ownership and support

    "The owner reviews weekly. The partner delivers updates and support as agreed in the quote."

An example from our own practice

At Voltti, a Hermes installation runs for our own work. For its SEO tasks, we go through the same seven questions. One recurring task: analyzing search data and proposing priorities. Sources: read-only access to our own Search Console data, nothing more. Output: a priority list with reasoning. Boundary: the agent only reads; for some tasks it publishes itself, and human review follows afterward. How that works is described in our article on SEO with an AI agent.

What that yields: a briefing of half a page that every stakeholder can read. The agent knows its boundaries, the owner knows what to check, and there is a measurable verdict: do the proposed priorities match what we would choose ourselves?

From briefing to pilot

With a filled-in briefing you are ready for a conversation with a partner. They translate your answers into a proposal: which steps the agent performs, which connections are needed, what the pilot covers and what support includes afterward. Which questions to ask a vendor is covered in our article on what an AI agent costs.

Not sure whether to build an agent yourself or have it built? On the AI agent development page you can read what Voltti takes care of and which first tasks are suitable. Ready to start? Discuss your pilot and bring your filled-in briefing: the first conversation is immediately substantive.

Portretfoto van Seppe Gadeyne

Seppe Gadeyne

    • Updated on

    Frequently asked questions

    01How long does filling in the briefing take?

    Expect an hour, with the people who know the task. Most time goes not into filling it in, but into agreeing on the task and the boundaries. That conversation is exactly what the briefing is for.

    02Should I share the briefing with my vendor?

    Yes. The briefing is the starting document of your pilot: your vendor or partner bases the approach, the rights and the quote on it. Without a briefing your partner has to make assumptions, and those cost time and therefore money.

    03Can a pilot work without a briefing?

    Technically anything is possible, but a pilot without a briefing measures nothing. Afterward you don't know whether the agent fell short or the assignment was unclear. The briefing is the difference between an experiment with a verdict and a demo.

    04What if I don't know which task to pick?

    Pick the recurring task that happens most often and is least enjoyable to do manually. Still unsure? Read how to spot recurring tasks or request an intro call: together we find a suitable candidate in half an hour.

    Request a conversation

    Discuss your pilot