The AI agent process brief: scope, outputs and acceptance criteria

A job title is not a task specification

“We need an AI sales assistant” describes a role, not a bounded assignment. Colleagues may imagine customer research, quotations, record updates or pipeline follow-up. Without a narrower agreement, a technically impressive build can leave the actual bottleneck unresolved.

Define one repeatable unit of work. For the hypothetical distributor in this series, it is a quotation draft from a complete request in a supported product category. Complaint handling, special-price negotiations and supplier ordering remain outside the initial version.

This boundary is not the final ambition of your AI strategy. It lets development, sales and leadership assess the same deliverable. A working task provides a basis for expansion. Starting with an entire department makes it harder to identify which rule or integration caused a failure.

Document today’s process using real examples

Collect representative completed cases, including ordinary requests, incomplete inputs and situations requiring judgment. Record steps and waiting points. Prefer cases with known outcomes so that the team can later examine what the agent changed.

Separate active work from total completion time. A draft may take little hands-on effort but wait most of a day for another department’s information. Faster writing does not remove that delay. The brief should identify the part of the process the project is expected to improve.

OpenAI’s guide to identifying and scaling use cases connects task selection with business context and preparation. For your implementation, the practical implication is that an accountable person must explain the work and a satisfactory result before the team chooses the technical solution.

Define entry conditions and valid outputs

Entry conditions specify which cases qualify for the automated route. For example: a recognized customer, supported product category, requested quantity and known delivery destination. If a required fact is missing, the process requests clarification rather than replacing it with a plausible assumption.

Describe the output as a concrete artifact. A quotation draft contains a customer identifier, product codes, quantities, the price basis and unresolved questions. A common output template aligns reviewers and makes required fields easier to validate programmatically.

Include outputs other than a draft: a clarification request, a handoff to a product specialist or a technical exception. Assign an owner to each. An agent that correctly identifies an unsuitable case and hands it over may meet the brief better than one that always produces an answer.

Separate rules, facts and interpretation

A business rule determines who may approve a special discount. A data fact is the current price in an authoritative system. Interpretation is understanding which product matches a customer’s informal description. Mixing these categories turns the model into a substitute for unresolved business decisions.

Assign a source and owner to every important fact. An old spreadsheet does not automatically have the same authority as the current price list. Define source precedence or a handoff condition when records disagree. A longer prompt will not resolve a disagreement about which record is valid.

Label each step as a rule, a fact lookup or interpretation. This exercise reveals where AI is actually useful. It also exposes steps better served by a simple validation, calculation or reliable data connection. The architecture should reflect those differences rather than making every step generative.

Make acceptance criteria case-specific

“The response should be high quality” is not testable enough. A stronger criterion says that an unsupported product must not produce an apparently confirmed quotation and must generate a handoff reason. Reviewers can apply that rule to a specific input.

Build a table with the input, expected behavior, unacceptable output and assessment method. Some fields can be checked automatically; product suitability may initially require a specialist. Agree how disagreements between reviewers will be resolved before using their scores to judge the system.

Anthropic’s evaluation guidance distinguishes an agent’s response from the final state of its environment. Apply that distinction to the brief: verify that the expected draft record exists, rather than accepting the agent’s statement that it saved one. A convincing demonstration should not become an incorrect operational record.

Specify recovery and useful feedback

Ask employees which situations force them to make extra checks today. Their answers often reveal missing categories, ambiguous variants and differences between written procedures and actual practice. Include these cases in the brief before development discovers them after rollout.

Microsoft’s HAX Toolkit addresses interaction design and anticipated AI failures. Use that as a prompt for a practical discussion: how does an employee recognize a limitation, correct the result and take over without entering all the information again?

Feedback should identify the error. “Bad answer” is less useful than “wrong model selected” or “outdated price used.” Collect agreed correction categories while allowing a short explanation. The resulting evidence informs the next improvement instead of becoming a collection of disconnected complaints.

Name the outcome owner and change owner

The business owner defines an acceptable result. The data steward owns source reliability. The technical owner maintains execution and connections. Operational users judge everyday usefulness. One person may hold several roles, but the responsibilities should remain explicit.

Define who can change the brief and which changes require renewed verification. Adding a product category can affect matching rules, data shape and the test sample. It may be more than a new paragraph in the instructions. Keep the specification version with the deployed system version.

A supplier should also state the assumptions behind its scope estimate. Data access, catalog quality and specialist availability are not automatic. A strong brief exposes dependencies so that the buyer and implementation team are discussing the same project, including the work needed before the agent can operate.

Worked example: a short completed specification

The brief states that the agent prepares a draft for an existing customer in a supported product category when required inputs are complete. The pilot aims to reduce repetitive draft assembly while a salesperson still judges the proposal. This is an objective, not a guaranteed savings or staffing claim.

Inputs include the case identifier, original request, confirmed customer and requested quantities. For each field, record whether intake supplies it or a tool retrieves it. An unconfirmed customer blocks draft creation. Development can test that rule and an operational user can understand its purpose.

The output is a draft with line items, supporting data and unresolved questions. Acceptance requires valid product codes, a reproducible calculation and a state clearly showing that the document has not been sent. Incomplete cases must identify the missing field and the responsible continuation queue.

At acceptance, examine an ordinary case, missing quantity, ambiguous customer, unsupported product and unavailable price source. Apply the predefined criterion to each instead of inventing an explanation afterwards. Disagreement between sales and development signals a specification gap to resolve before it reaches production.

Use the brief to make an implementation decision

Before building, agree what will be shown at acceptance, which cases must pass and who will assess them. Separate unresolved issues into blockers and questions the pilot can answer. Do not leave blockers hidden in the hope that a more capable model will settle them.

At NUMEDIA, the objective is an implementable scope: one task, accountable people, agreed data and verifiable criteria. This also improves comparisons between suppliers. The number of proposed agents matters less than the responsibilities each solution actually accepts.

Once agreed, use the brief throughout integration and pilot reviews. If the task needs to change, record the change. Do not redefine acceptance retrospectively merely to make an existing prototype appear successful. A maintained specification is more valuable than a document that becomes irrelevant after procurement.

Sources and methodology

1. Identifying and scaling AI use cases (OpenAI, accessed 2026-10-19)
2. Microsoft HAX Toolkit (Microsoft, accessed 2026-10-19)
3. Demystifying evals for AI agents (Anthropic, accessed 2026-10-19)