How to Brief an AI Agent on a Work Project

A well-formed brief for an AI agent describes the expected output, the data source, access boundaries, verification criteria and the point at which a human takes over. Leave any of those out, and the agent will fill the gaps on its own. The mistake may then arrive inside a neatly formatted deliverable.

Why "prepare a sales report" doesn't work

Say you ask an agent to build an executive presentation from a monthly CRM export. The request sounds clear enough. But the agent doesn't know which column holds revenue and which holds returns. It doesn't know whether to count open deals. It doesn't know whether the slide needs a regional breakdown or just a total. And it certainly doesn't know that accounting corrected three rows by hand last month, leaving the file with two competing values for the same figure.

The agent will handle whatever you described explicitly. Everything else it will either infer from its own logic or halt with an error message at the worst possible moment. Neither outcome works for a manager who needs slides by Monday.

Output: what the finished thing should look like

Start the brief with the final file, not the process. Describe the artifact: its format, structure, length and intended audience. The agent optimizes its work toward whatever you define as the finish line.

Weak: "Produce a sales analysis."

Better: "Prepare an 8-to-10-slide PPTX for the monthly directors' meeting. Slide 1 - monthly totals; slide 2 - week-by-week trend; slide 3 - top five products by revenue. Agree the structure of the remaining slides with me before the final assembly."

When the endpoint is concrete, the agent plans its intermediate steps backward from the result. That reduces the chance it will spend time on analysis that ends up in no slide at all.

Source data: where it lives and how much to trust it

The agent works with what it is given. If you don't name the source, it may pull the wrong file, use a cached version or ask for data halfway through the job. State the source explicitly: the file path or folder, the sheet name, the date range, the export version.

Also say something about data quality. If the file contains known blank rows, duplicates, manual edits or non-standard units, the agent needs to know that upfront. Otherwise it will either ignore the anomalies or stop and ask for instructions - after it has already spent time on the first steps.

A practical technique: ask the agent to produce a field map and a list of discrepancies as its very first output. That short intermediate result lets you confirm the agent has understood the data structure correctly before it moves on. It is precisely this step that stops an error in the source from propagating into the final file.

Constraints: what must not change and what must not be touched

Constraints are easy to omit from a brief. You need to say what the agent must not modify and which systems or files are off limits. A sentence in the task description is not enough on its own, though - constraints should also be enforced through actual access permissions.

Specify three things: which data the agent may only read, not write; which systems or files are outside the scope of the task (for example, the agent works only with the current-month export and does not touch the archive); and which decisions the agent must not make independently - choice of calculation methodology, changes to the report structure, rounding of figures.

For actions with real-world consequences - sending an email, writing to a database, publishing a file - you need an explicit confirmation point. The agent prepares a draft and stops. A person reviews it and gives the go-ahead. That is the safeguard against an automated action that turns out to be irreversible.

A verbal restriction in the brief does not replace a technical permission setting. If the agent must not modify a file, configure read-only access at the system level, not just through the wording of the task.

A sample brief for a single task

The example below is fictional - it is here to illustrate the structure. Adapt it to your own data and context.

Task: prepare a sales presentation for the July directors' meeting.
Output: file sales_july.pptx, 8 slides, structure agreed with me before final assembly.
Source: CRM_July_2026.xlsx, sheet "Deals", rows 2-1450.
  Column F = revenue excluding VAT; column K = status (include only "Closed").
Constraints: file is read-only; do not use archive data;
  do not change the calculation methodology without approval.
Intermediate step: before building any slides, show a field map
  and a list of rows with a blank value in column F.
Verification: the total revenue on the slide must match the sum of F2:F1450
  filtered to rows where K = "Closed". For each aggregate figure,
  state the range, filter and formula; for any individual deal, state the row.
On uncertainty: stop and report the issue; do not make the decision independently.
  Direct questions to the project manager.

This is not a universal prompt. It is a structure you fill in for a specific task with specific data.

How to check that the work was done correctly

The agent has no idea what "good" means to you. Acceptance criteria need to be written into the brief; otherwise you will receive a result that technically matches the assignment but diverges from your expectations.

Describe three things: how to verify the numbers (cross-check the total against a control sum from the source using the same filter, confirm that the time periods match); how to verify the sources (for an aggregate figure you need the range, filter and formula; for an individual deal you need the row); and what counts as the final artifact (a file in a specific folder, not a draft sitting in a working directory).

If the agent should show an intermediate result before finishing, say so explicitly. For example: first a draft dashboard with a comment on each figure, then - after your approval - the final slides. That structure lets you catch an error at the stage when it is still easy to fix.

Where the agent should stop and ask a human

Agents do not always ask clarifying questions on their own. Some tools ask; others make a silent choice and continue. It is safer to state explicitly the conditions under which the agent must stop and message you rather than proceed.

Typical situations: the data does not match the expected format; the agent must choose between two calculation methods; an intermediate result contains anomalies. Write it into the brief: "if you encounter a situation not covered by this task, stop and report it - do not make the decision yourself."

This matters most for tasks where a data error leads to a wrong conclusion that reaches senior management. Agreeing on something before the final file is cheaper than explaining at the meeting where a wrong number came from.

For guidance on building these processes across a team, see the article on running an AI pilot with your team and the section on AI implementation in workflows.

FAQ

Do I need to write a brief like this for every task?

For a one-off simple task, a short description of the output and the source is enough. A detailed brief is worth the effort when the agent takes multiple steps, works with real data and its output goes to other people. The higher the cost of a mistake, the more specific the description should be.

What if the data changes every time?

Describe a rule for finding the file rather than a specific filename: "the most recent export in /reports/crm/ whose name starts with CRM_." The agent will apply that rule to the current file. Always add an intermediate step to check the structure - different exports can differ in format.

The agent got something wrong. Who is responsible for the result?

The agent acts within the scope of what it received. If the task was described vaguely, responsibility for the outcome rests with the person who wrote the brief - though that does not mean the brief-writer is at fault for every agent error. Checkpoints and explicit constraints exist precisely for this reason: they give you a chance to catch a discrepancy before it becomes a problem.

Can the same brief be reused?

Yes, if the task recurs with the same requirements. Save the brief as a template and update only the variable parts: the period, the file path, the recipient. The rest of the structure stays valid.

If you want to work through a specific task or check whether your brief covers all the risk points, reach out on Telegram or at hello@majento.ai.

Source

Majento consultations and training courses.