Custom AI agents: write a brief that can be tested

A custom AI agent that processes quote requests rarely fails for lack of technology: it fails because nobody wrote down what the output should be, in which format, and what is forbidden. This guide provides a filled-in brief template for one specific case: an agent that qualifies and prepares incoming quote requests, without ever issuing a final quote. You will find the required fields, contradictory examples, expected formats, business rules, access rights, acceptance criteria and change management. You will also see how to fix a vague brief and which information to prepare before starting the project.

Why a testable brief changes everything

A useful brief is not a style document: it is a test contract. Every sentence must be convertible into a binary check, pass or fail. "The agent must handle requests well" cannot be tested. "The agent must classify each request into exactly one of three categories A, B, C and produce a JSON summary with these seven fields" can be tested.

This discipline protects both sides. The vendor knows what to deliver, and you know what you can reject. If you are comparing several proposals, a precise brief makes offers comparable, as explained in our guide to comparing AI agent agency proposals. Without it, every quote describes a different product.

The case chosen here is deliberately bounded: the agent prepares, it does not decide. No final quote is sent to the end client; a human reviews and sends. This boundary simplifies the rules, reduces risk, and remains an excellent first project, in line with a first AI agent project built around a mission with a clear finish.

Main example: the quote request qualification agent

Take a fictional services SME that receives, in this example, 30 to 60 quote requests per week by email and web form. Today, a sales rep reads each request, chases missing information, then drafts a reply. The custom agent must take over this preparatory task.

Agent mission: for each incoming request, extract structured information, detect missing or inconsistent fields, classify the request by service family and urgency, then produce a reply draft in the company mailbox. The draft stays a draft: it is never sent automatically.

Expected output per request: a structured record with the fields listed below, plus a follow-up or acknowledgment email draft, ready for review.

Explicitly forbidden output: sending an email, quoting a price, committing to a deadline, modifying a sales document, deleting or forwarding a message.

This restriction is not excessive caution. If the agent handles Gmail, note that scopes such as gmail.compose and gmail.modify can also allow sending messages; restricting behavior to drafts therefore requires application-level controls, not just a checkbox on the authorization side. The official Gmail scopes documentation describes this clearly, and a folder label is not a Gmail permission boundary: your application rules draw the boundary.

Required fields of the brief

Here is the skeleton, filled in with our example. You can reuse it as is for a personalized AI qualification agent.

Section	Content in our example
Mission	Qualify incoming quote requests and prepare a reply draft
In scope	Incoming email and web form, extraction, classification, draft
Out of scope	Sending email, pricing, signing, automatic follow-ups beyond a draft
Inputs	Dedicated mailbox, daily web form export
Outputs	Normalized JSON record, Gmail draft, row in the tracking sheet
Business rules	A/B/C classification, missing-field detection, urgency thresholds
Rights	Read access to the dedicated mailbox, draft creation, write access to the tracking sheet. No sending, no deletion
Acceptance	20 real historical requests replayed, with expected results written in advance
Known limits	Requests in languages other than French and English flagged for human review
Change management	Any new rule goes through a change form with acceptance impact

Every line must be written so it can fail. "Rights: no sending" becomes a test: the acceptance scenario attempts to make the agent send a message, and the test passes if the agent refuses and flags it.

Formats and data rules: do not confuse the two

A frequent brief mistake is mixing two different things: the format of the data and the rules applied to that data. Format describes what a piece of information looks like; a rule describes what you do with it.

Formats, in our example:

• Timestamps: date, time and an explicit time zone; a date alone uses YYYY-MM-DD. A request received on 2026-10-20 at 10:00 Paris time corresponds to 08:00 in Dakar; on 3 November 2026 at 10:00 Paris it corresponds to 09:00 in Dakar, because of the clock change. If your teams work across two time zones, the format must carry the zone, not guess it.
• Amounts: decimal number with an ISO currency code, never "about 5k".
• Identifiers: the Gmail draft ID is stable, but the ID of the message it contains changes when the draft is modified. If your tracking sheet references a draft, it must store the draft ID, not the message ID.
• Categories: closed values A, B, C. Any value outside the list is an error to flag, not a catch-all "other" category.

Rules, in our example:

• If the stated budget is missing, the request goes to category C and the draft asks about the budget.
• If the requested lead time is under ten business days, the request is flagged "urgent" and the sales rep is notified in the summary, never by automatic email.
• If the request mentions a competitor by name, the draft makes no comparison; it flags the request to the sales rep, without forwarding or sending any message.

The distinction matters for acceptance testing: formats are tested with data sets, rules with scenarios. A brief that confuses the two produces endless acceptance phases and disputes. The same distinction also helps when evaluating AI chatbot answers against business criteria rather than impressions.

Contradictory examples: what makes a brief unusable

Vague briefs almost always contain instructions that contradict each other. Here are three fictional pairs, written to illustrate contradictions.

Contradiction 1: autonomy versus control. "The agent must reply to clients immediately" and "no reply goes out without validation". Fix: the agent prepares a draft immediately; sending stays human. One sentence suffices: "The draft is available within 15 minutes of receipt; sending is manual."

Contradiction 2: exhaustiveness versus restraint. "Extract all useful information from the request" and "do not invent what is not written". Fix: list the exact fields to extract and the handling for each missing field: "field missing" rather than a guess. A custom AI agent must be able to say "I don't know" in a structured way.

Contradiction 3: classification versus exceptions. "Any request under €2,000 goes to category C" and "known clients stay in category A regardless of amount". Fix: write the rule order. "Rule 1: if known client, category A. Rule 2: otherwise, if amount under €2,000, category C." The order is part of the brief.

To fix a vague brief, apply this four-step procedure:

1. Underline every action verb and ask: what trigger, what input, what observable output?
2. For every adjective ("fast", "reliable", "smart"), replace it with a measure: "draft ready within 15 minutes", "95% of required fields filled on the acceptance sample".
3. For every "always" and "never", write the matching test scenario.
4. Have someone who was not involved read the document and list what they would do differently. Each gap is a remaining ambiguity.

Access rights and permission boundaries

The brief must treat rights as a specification in their own right, not a technical detail. Three different things often hide behind the word "connection": transport (the technical channel), the vendor's authorization (the account and its scopes), and operational evidence (the log showing what was actually done). A serious brief describes all three.

In our example:

• Transport: the agent reads a dedicated mailbox through the API, not the owner's personal inbox.
• Authorization: the requested scope covers reading and draft creation. Since compose- or modify-type scopes can also allow sending, the brief imposes an application control: the send function does not exist in the delivered code, and an acceptance test attempts a send to verify the refusal.
• Operational evidence: every processed request produces a timestamped log line with the request ID, the classification and the created draft ID.

If your agent must also read calendars, note that Calendar supports creating events with explicit IDs, but there is no guaranteed global transaction between Calendar and your own system: the brief must provide a reconcilable intermediate state for partial failures. Similarly, a protocol like MCP exchanges tools and context, but it does not choose your business rules or permissions for you: those stay in your specification. Finally, the personal data the agent processes (prospect contact details, message content) must follow the core principles recalled by the CNIL: purpose limitation, minimization, security.

Acceptance criteria: how validation will work

Acceptance testing turns the brief into a verdict. Prepare it while writing, not after development. Our example sets:

• Test set: 20 anonymized real requests covering the three categories, two multilingual requests, one request without a budget, one with an urgent deadline, one inconsistent request (delivery date before sending date).
• Classification criterion: at least 18 out of 20 answers classified as expected; the two maximum gaps must be analyzed and understood.
• Field criterion: 100% of produced records comply with the formats (dates, amounts, closed categories). A single invalid format fails the test.
• Security criterion: no sending possible, verified by a deliberate attempt; no writes outside the planned tracking sheet.
• Draft criterion: every draft referenced in the tracking sheet remains findable after modification, thanks to storing the draft ID rather than the message ID.

These criteria echo the general logic of acceptance testing and handover in chatbot development: tests written in advance, a binary verdict, and an explicit list of accepted gaps rather than a general impression.

Change management and information to prepare

An agent lives with your business rules, and those will change. The brief must say how. In our example: any rule change (new category, new threshold, new field) goes through a one-page change form describing the current rule, the target rule, the affected acceptance scenarios and the effective date. Changes touching mandatory formats trigger a partial acceptance run on the full test set.

On your side, prepare this information before writing or handing over the brief:

• Twenty to thirty past real requests, with the classification your team would have given.
• The closed list of categories and service families.
• The priority rules in writing, with their order of application.
• The dedicated mailbox and the rights available on it.
• The existing tracking sheet, with its actual columns.
• The people who sign off acceptance and those who decide on changes.

If you are starting from scratch, the guide to business AI agent missions helps you pick a task with a clear finish, a condition of a successful first project.

Limits to state in the document

Writing the limits into the brief avoids discovering them in production. Three limits deserve explicit mention in our example. First, classification relies on past examples: a request of a never-seen type may remain uncertain, and the brief provides a pending state flagged for human review, distinct from categories A/B/C: until the classification is validated, the category field stays empty. Second, extraction from non-textual attachments (drawings, scans) is out of scope; such requests are flagged "attachment to process". Third, the agent does not manage the sales relationship: a prospect who replies to a draft restarts the normal human process.

Owning these limits also protects trust in the successes. An agent that correctly qualifies 19 out of 20 requests and honestly flags the twentieth is more useful than an agent that claims to handle everything.

Frequently asked questions

Should sending emails be forbidden on a first project?

It is strongly recommended for a first custom AI agent. Since Gmail scopes of the compose or modify type can also allow sending, the ban must be enforced by the application code and verified during acceptance. You can widen it later, with explicit sending rules and a log.

What is the difference between a data rule and a business rule?

A data rule describes the format and validity of a piece of information: date as YYYY-MM-DD, amount with a currency, category from a closed list. A business rule describes the handling: "if the budget is missing, go to category C". The first are tested with data sets, the second with scenarios.

How many acceptance scenarios should I plan?

Count one scenario per written rule, plus the edge cases you already know: request without a budget, inconsistent dates, unexpected language. The twenty requests in our example are an illustrative starting point, not statistically sufficient proof. Add the edge cases and adapt the volume to the diversity of requests and to the consequences of an error, provided the expected results are written before the tests.

What if my brief contains contradictory instructions?

Treat each contradiction as a decision to make, not a detail. Write the rule order, replace adjectives with measures, and have an outsider read the document. A contradiction left in the brief will resurface as a dispute at acceptance.

Should the brief plan for future changes?

Yes; that is what distinguishes it from a mere feature list. Provide a change form with acceptance impact for each new rule, and a partial acceptance run when formats change. A personalized AI agent that cannot evolve cleanly becomes a cost at the first business change.