How to Write an AI Agent Job Description

How do you define what an AI agent should do? Write a one-page job description that states the business outcome, trigger, authoritative inputs, permitted responsibilities, tool access, prohibited actions, completion condition, escalation path, measures and accountable owners. Then test that specification against real cases before granting production authority. A prompt describes behaviour; a job description defines responsibility.

Why an AI agent needs a job description

Many agent projects begin with a tool list and a broad instruction such as “help the sales team.” That is not a job. It gives the system no dependable way to decide which work belongs inside its scope, when the work is complete, or when a person must take over.

A useful AI agent job description performs the same function that role design performs in an operating team: it converts an ambition into bounded responsibility. It tells business owners what they are delegating, gives builders a specification, gives evaluators expected behaviour, and gives operators a basis for reviewing failures.

NIST's AI Risk Management Framework makes this an organizational requirement rather than a prompting preference. Its Govern function calls for documented roles, responsibilities and lines of communication; its Map function calls for a specified application scope and defined human oversight. The person remains accountable for the workflow even when the agent performs part of it.

The one-page agent-role canvas

I use eight fields. If a team cannot complete them clearly on one page, the proposed role is probably too broad or the underlying workflow is still poorly understood.

Download the AI agent role canvas

Step 1: write the job purpose as an outcome

Start with the result the workflow needs, not a human-sounding title. “Customer-success agent” is vague. “Prepare a complete renewal-risk case for an account manager before the weekly review” is testable. It identifies the object being produced, the recipient and the moment it is needed.

A good purpose statement contains four parts: the business object, the change the role should create, the boundary of the workflow and the human owner. Avoid goals the system cannot directly control, such as “increase revenue.” The agent may improve lead-response coverage or prepare qualified opportunities, but a commercial owner controls pricing, relationships and closing decisions.

Also write a non-goal. For the renewal example: “The agent does not negotiate terms, promise discounts or contact the customer.” One sentence can prevent a large amount of accidental scope expansion.

Step 2: turn responsibilities into observable work

List responsibilities as actions whose evidence can be inspected. Replace “manage enquiries” with a sequence: retrieve the new enquiry; verify required contact fields; classify the stated need using an approved taxonomy; attach the source evidence; prepare a CRM record; route unclear or sensitive cases.

The SOP-to-AI-workflow method is useful here. Mark which steps are deterministic rules, which require language interpretation, which require tools, and which remain human decisions. An agent should not improvise around a missing control simply because the existing SOP is informal.

For each responsibility, specify an output contract. “Prepare a lead record” should define mandatory fields, permitted classification values, source links, confidence or exception state, and validation before writing. Clear actions and outputs reduce ambiguity and make representative evaluation possible.

Step 3: design tools as permissions, not features

Tool access is delegated authority. Record the system, permitted operation, data scope and approval condition for each tool. “CRM access” is too broad; “read open enquiries assigned to Team UAE and prepare—but do not submit—a normalized record” is a usable permission.

Separate verbs that are often bundled together:

• Read: retrieve approved records or documents.
• Prepare: create a draft that has no business effect.
• Write: change a system-of-record field.
• Send: communicate externally or trigger another party.
• Approve: accept a transaction, exception or policy decision.
• Pay or delete: perform high-consequence, difficult-to-reverse actions.

Grant the lowest level needed for the purpose. OpenAI's current agent-building guide recommends risk-rating tools based on factors such as read versus write access, reversibility, account permissions and financial impact, then using guardrails or human intervention for higher-risk actions. The same tool can require different approval rules at different values or customer states.

Step 4: write constraints and prohibited actions

Constraints are not a closing paragraph that says “be careful.” They are operational rules with detectable conditions. Define approved data sources, required fields, transaction limits, allowed communication windows, retry limits, retention, output format and completion conditions.

Then list prohibited actions explicitly. Examples include inventing a missing customer fact, changing bank details, accepting contractual terms, sending a message without consent, overriding an authorization result, weakening a validation rule, or treating an earlier model output as authoritative evidence.

Keep deterministic controls outside the model where practical. Authentication, authorization, totals, duplicate checks and thresholds should be enforced by application logic or the system of record. Instructions tell the agent how to work; controls make unsafe actions unavailable.

Step 5: define stop and escalation rules

“Ask a human if unsure” is not an escalation design. Define observable triggers: a required field is missing; two sources conflict; the request is outside taxonomy; a tool fails twice; the action exceeds a value threshold; the customer disputes the record; a policy has expired; or the agent cannot cite the basis for its classification.

Every escalation should include a destination, urgency and evidence package. The person receiving the case needs the original request, relevant records, actions already attempted, tool results, reason for stopping and a clear decision request. Escalation without context merely transfers investigation work.

Use the human-oversight ladder to match review to consequence. OpenAI's agent guide identifies exceeded failure thresholds and high-risk actions as common triggers for human intervention. NIST likewise calls for human roles and oversight to be clearly differentiated and documented.

Step 6: choose measures and accountable owners

Do not measure an agent only by token use, response speed or task completion. A system can finish quickly and still produce incorrect records, unnecessary escalations or expensive rework. Use a balanced set of measures:

• Outcome: did the workflow reach its defined business result?
• Quality: were required fields, classifications and evidence correct?
• Control: did prohibited actions remain blocked and approvals occur when required?
• Operations: what were cycle time, retries, abandonment and exception volume?
• Human impact: did the hand-off reduce investigation work or simply move it?

Name at least four owners: a business owner for the outcome and policy, a technical owner for the runtime and integrations, a risk or control owner for authority decisions, and an operations owner for queues, incidents and manual fallback. In a small company one person may hold more than one role, but the responsibilities should still be explicit.

A completed example: inbound-enquiry preparation agent

This example is intentionally narrow. It does not “run sales.” It removes structured preparation work while preserving commercial judgment and customer communication. Expand the role only after representative cases show that the current responsibility is reliable.

Test the job description before deployment

1. Normal cases: complete inputs that should produce a successful output.
2. Messy cases: missing, stale, duplicated and conflicting information.
3. Boundary cases: work that resembles the role but belongs elsewhere.
4. Risk cases: attempts to obtain prohibited actions or excessive access.
5. Failure cases: unavailable tools, timeouts, partial writes and repeated retries.
6. Handoffs: whether a human can act from the escalation package without reconstructing the case.

Review traces against the written role. If evaluators cannot agree whether an action was allowed, improve the specification before improving the model. The agent security checklist adds identity, data, tool and incident controls for production review.

A role, not a persona

A friendly name and tone can help users interact with an agent, but personality does not create operational clarity. The production specification is the job: purpose, scope, authority, constraints, escalation, evidence and ownership.

Start with one outcome and the smallest useful responsibility. Keep consequential decisions visible. When the agent performs reliably, expand its role by revising the job description, permissions and evaluations together—not by quietly adding another tool.

Primary sources checked

Checked 1 September 2026. Frameworks and product guidance can change; review the current official sources during implementation.

• NIST AIRC — AI RMF Core
• NIST AIRC — Human-AI interaction, roles and oversight
• NIST — AI RMF Playbook
• OpenAI — A practical guide to building AI agents