How to write a job description for an AI agent (with template)

An AI agent job description is the brief you hand to an agent, or to the person or firm that operates it, before any work starts. A useful one does more than describe a role. It states one outcome, what you provide, what exists when the job is done, and how you will check it, so you can accept or reject delivered work line by line. This guide covers the eight fields that make that possible, gives a blank template you can copy, and walks through one filled-in example. It is step 2 of the method in how to hire an AI agent.

Why an agent needs a different job description

A job description for a person is written to attract candidates. It lists responsibilities, skills and perks, and leaves the details to onboarding and a manager's judgment. An agent's job description has a different reader and a different purpose. It is read by whoever configures the agent, it becomes the basis of the agent's instructions, and it is the yardstick in the trial.

Two vendor guides on building agents say why the detail matters. OpenAI's practical guide to building agents describes an agent as three parts (a model, tools, and instructions, "explicit guidelines and guardrails defining how the agent behaves") and says clear instructions "reduce ambiguity and improve agent decision-making, resulting in smoother workflow execution and fewer errors." Anthropic, describing what it has seen with customers, says agents add the most value for tasks that "have clear success criteria, enable feedback loops, and integrate meaningful human oversight." Both are the builders' own advice, not neutral research, but they point the same way: the job has to be written down specifically enough that someone can tell when it is done right.

There is a buyer's reason too. A vague job ("help with invoices") cannot fail a test. If you cannot say what a wrong output looks like, you cannot run a trial, compare two providers or know when to stop.

The eight fields

Every job page in this section uses the same fields. They are also the fields of the future job board's posting form.

Field	What it answers	Weak	Better
Goal	What outcome counts as done	"Help with support"	"Every password-reset ticket gets a correct reply within 2 business hours"
Inputs	What you provide, including access	"Our data"	"Read access to the support inbox; the password-reset help article"
Deliverable	What exists at the end, and where	"Answers"	"A drafted reply on each ticket in the help desk, tagged agent-draft"
Acceptance criteria	How you check it	"High quality"	"On a 50-ticket sample, at most 2 replies need a factual correction"
Volume and cadence	How much, how often	"Ongoing"	"Example: 200–400 tickets a month, checked daily"
Systems	Where the work happens	"Our tools"	"Help desk (for example Zendesk); identity provider, read only"
Constraints	What it must not do or touch	(blank)	"No account changes; no customer data leaves the help desk"
Human checkpoints	Where a person approves, and what they check	"We'll keep an eye on it"	"An agent on the team approves every reply before it is sent"

The examples in the "Better" column are illustrations, not recommended numbers for your team.

Goal: one outcome, not an activity

Write the goal as a sentence that is either true or false at the end of a period. "Every supplier invoice is coded and queued for approval within one business day of arrival" can be checked. "Assist the finance team" cannot. One goal per job description. If you find yourself writing "and", you probably have two jobs; split them and hire for one first.

Inputs: what you give, including access

List the documents, exports and accounts the agent needs, and write the access level next to each one. OpenAI's guide suggests building agent instructions from "existing operating procedures, support scripts, or policy documents". If you have a procedure document, a style guide or a chart of accounts, it belongs here.

Keep access narrow. The OWASP Gen AI Security Project lists Excessive Agency as LLM06:2025 and traces it to three causes: excessive functionality, excessive permissions and excessive autonomy. Its mitigations include limiting the extensions an agent can call "to only the minimum necessary" and limiting the permissions those extensions hold on other systems; its example is an agent that only needs read access to one products table and "should not have access to other tables". In the inputs field, that means "read access to the AP inbox", not "email access", and "draft rights in the help desk", not "agent seat". Name the kind of data the agent will touch (customer, personal, financial), so the provider and your own reviewers know what is at stake.

Deliverable: what exists, and where

Say what artifact the job produces and where it lands: a coded invoice in the approval queue, a drafted reply on the ticket, an enriched row in the CRM. A deliverable that lives in your own system is easier to review and easier to take back if you stop the agent.

Acceptance criteria: checkable statements

This is the field that makes the rest testable. Write three to six statements, each one pass or fail, with numbers where you can:

• Tie each criterion to a sample: "on a 50-invoice sample from last month".
• Put a number on errors: "at most 2 coding errors", not "accurate".
• Include time where it matters: "within one business day of arrival".
• Include a rule for the risky cases: "every invoice over $5,000 is flagged for a manager".
• Include what the agent does when it is stuck: "an invoice it cannot code goes to the clerk's queue with a reason".

The last one matters more than it looks. OpenAI's guide says agent instructions should "capture edge cases", such as what to do "when a user provides incomplete information", and its section on human intervention says an agent should escalate when it exceeds "failure thresholds", for example after failing to understand a customer's intent "after multiple attempts." A job description that only describes the happy path leaves the agent to guess on the rest.

Our recommendation: write the criteria before you see any demo or trial output, and keep the numbers you wrote. The trial guide uses them as the answer sheet.

Volume and cadence

Write last month's real volume and how often the work arrives. These numbers size the trial, decide which pricing unit matters (per seat, per task, per resolution; see how AI agents are priced) and tell a provider whether the job fits what they run. Mark them as your figures, not as targets.

Systems

Name system types first (accounting system, help desk, CRM) and products only as the example you use. A provider reads this field to decide whether they can connect at all.

Constraints

Write the things the agent must not do, and the rules your data is under: no sending without approval, no deletions, data stays in a named region, no use of your data for training. If a law or contract assigns a task to a specific person, say that the task stays with that person; ask counsel which obligations apply to your role and jurisdiction.

Human checkpoints

Name where a person approves and what they check. OWASP's mitigation for excessive autonomy is to "require a human to approve high-impact actions before they are taken." OpenAI's guide names "high-risk actions" as one of two triggers for human oversight and gives as examples "canceling user orders, authorizing large refunds, or making payments." For your job, decide which actions are high-impact before the trial: payments, messages to customers, filings and deletions are where to start looking. Each checkpoint gets a role ("the AP clerk"), not just "a human". The supervision guide covers how checkpoints change once the agent has a track record.

The template

Copy this blank template and fill it in for one job. Every field has a placeholder; delete the ones that do not apply only after you have thought about them.

A filled-in example

Example only; not a real buyer. Assume, for this example, a 40-person software company whose support lead spends part of each day on password-reset tickets.

• Goal. Every password-reset ticket gets a correct, sent reply within 2 business hours of arrival.
• Inputs. Read access to the support inbox in the help desk; the current password-reset help article; the escalation policy. Data touched: customer names and email addresses.
• Deliverable. A drafted reply on each password-reset ticket, tagged agent-draft, or the ticket routed to the support lead with a one-line reason.
• Acceptance criteria. On a 50-ticket sample from last month: at least 45 tickets correctly identified as password resets or not; at most 2 drafts need a factual correction; every ticket mentioning a security concern is routed to the lead, not drafted; no draft promises an account change the help article does not describe.
• Volume and cadence. Assume 300 password-reset tickets a month, arriving throughout the business day.
• Systems. Help desk (for example Zendesk or Freshdesk). No access to the identity provider.
• Constraints. The agent drafts; it does not send and does not change accounts. Customer data stays in the help desk.
• Human checkpoints. A support agent approves and sends every draft during the trial. The support lead reviews the routed tickets daily and can turn the agent off in the help desk settings.

Read the acceptance criteria against one ticket. A customer writes, "I can't log in and I think someone changed my password." The agent should not draft a reset reply; the security criterion routes it to the lead. If the agent drafts a cheerful reset link instead, that ticket fails, and the trial has found exactly the case the job description was written to catch. For the full job, see tier-1 customer support.

The same eight fields work for accounts payable, lead research and enrichment and document processing; each of those pages carries its own filled-in brief.

Mistakes to check for before you send it

• A role instead of a job. "AI marketing assistant" is a role. "Draft three social posts a week from each new blog article" is a job.
• Adjectives instead of numbers. "Fast", "accurate" and "on-brand" cannot fail. Replace each one with a sample and a limit.
• Access copied from a person's account. A person's login can carry more rights than one job needs. Write the access the job needs and ask the provider to match it.
• No exit for hard cases. If the description does not say what happens to work the agent cannot do, the agent will either guess or stop silently.
• Checkpoints without names. "Human in the loop" with no named role means nobody reviews.
• Changing the bar after the trial. If you relax a criterion, write down why. If the reason is that the agent could not meet it, the job description was probably right.

Questions buyers ask

Is this the same as a system prompt? No. The job description is your side of the agreement, written in business terms. The operator turns it into instructions, tool settings and guardrails. Keep both, and check that every constraint and checkpoint in your description shows up in how the agent is configured.

How long should it be? Long enough that a stranger could reject a delivered output using only the description. Our suggestion: one page per job.

Can I hire one agent for several jobs? You can, but write one description per job and trial them one at a time, so each result is measurable on its own.

Who writes it, me or the vendor? You do, because you own the outcome and the acceptance criteria. A provider can help with inputs and systems, but the goal, criteria and checkpoints should come from the person who does or manages the job today.

Sources

1. 1
   A practical guide to building agents

   OpenAIVendorAccessed Nov 14, 2026

2. 2
   Building effective agents

   AnthropicVendorAccessed Nov 14, 2026

3. 3
   LLM06:2025 Excessive Agency

   OWASP Gen AI Security ProjectPrimaryAccessed Nov 14, 2026