Write a Job Description for Your First AI Agent Role

An AI agent role definition is a short written description of one job: what the agent is for, which tools and information it may use, where it must stop and ask a person, and how you will see that the work is good. Write it the way you would write for a new hire, before you pick any technology. A role that is clear on paper is much easier to build, test and correct.

Key takeaways

• Define one role with one purpose, not a general assistant that is expected to do everything.
• List the tools, information and accounts the role needs, and nothing beyond that.
• Decide in advance which actions the agent may take alone, which need approval and which are off limits.
• Name a human owner and an observable success criterion before the agent starts work.
• Review the description on a schedule, because roles drift as the business changes.

Why treat the first agent like a hire?

When a company hires a person, nobody says "help the business" and hands over every password. There is a role, a manager, a first set of responsibilities, access that matches those responsibilities, and a way to tell after a few weeks whether things are going well. Most companies skip all of that when they introduce an AI agent. They connect a model to a few systems, give it a broad instruction and hope it behaves.

The result is predictable. Nobody can say what the agent is supposed to do, so nobody can say when it has failed. Access is granted for convenience and never reviewed. Mistakes are discovered by customers or colleagues instead of by the team that owns the work.

The hiring comparison is useful because it brings the right questions back. What problem is this role solving? Who does it report to? What can it decide, and what must it ask about? What would a good month look like? Anthropic's guidance on building effective agents makes a related point from the engineering side: start with the simplest setup that works and add autonomy only where it earns its place. A job description is the business version of that discipline.

What belongs in an AI agent job description?

You do not need a long document. One page is usually enough, and a page that someone can actually read will be used more than a forty-page specification. These are the fields that matter:

• Role title and purpose: one sentence on the outcome the role exists to produce.
• Human owner: the named person who answers for the role and receives its escalations.
• Responsibilities: the specific tasks the role performs, written as verbs and objects.
• Out of scope: tasks the role must not do, even if it technically could.
• Information sources: the documents, records and systems that count as the source of truth.
• Tools and accounts: what the agent may read, what it may write, and under which identity.
• Approval boundaries: actions that need a person to confirm before they happen.
• Escalation path: who is contacted, how, and what the agent must include in the message.
• Success criteria: what you will observe to decide the role is working.
• Review rhythm: how often the description, access and results are checked.

The fields that people most often leave out are the human owner, the out-of-scope list and the review rhythm. Those are also the ones that prevent the slow problems: an agent nobody feels responsible for, a role that creeps into work it was never meant to do, and permissions that outlive their reason.

How narrow should the purpose be?

Narrower than feels ambitious. A good purpose statement describes one outcome for one group of people using one set of information. "Prepare first drafts of customer follow-ups from the notes in our CRM, for the sales team to review and send" is a role. "Improve our customer experience" is a hope.

A useful test is whether a new colleague could read the purpose and tell you what they would do on their first morning. If they could not, the purpose is too wide. Another test is whether you can describe a single finished unit of work, such as one draft, one reconciled record or one summarized thread. If you can point to a unit, you can count it, check it and improve it.

Narrow does not mean trivial. A role can be narrow and still valuable if it covers a recurring task that costs your team real attention. The point is that the first role should be small enough to prove. If you are still choosing which work to hand over, the article on choosing your first AI workflow covers how to pick a task that is frequent, bounded and easy to check.

One more thing belongs in the purpose: who the work is for. An agent that drafts for the sales team has a different tone, risk and review process than one that answers customers directly. Naming the audience early keeps those two jobs from being mixed together.

Which tools, memory and access does the role need?

This is the part of the job description that most resembles an access request, and it should be treated with the same care. For each responsibility, ask what the agent must see and what it must change. Then write down the minimum.

A practical way to do this is to separate three kinds of access:

• Read access: what the agent can look at, such as a shared folder, a ticket queue or a customer record.
• Write access: what the agent can create or change, such as a draft, a note or a field in a system.
• Action access: what the agent can send or trigger outside the company, such as an email, a payment or a published page.

Most first roles need broad read access, narrow write access and no unreviewed action access. That pattern is a good default. The principle behind it is least privilege, described in more detail in least privilege for AI agents. OWASP's authorization guidance supports the same habit in general software: grant the smallest permission that lets the job be done, and deny by default.

Then decide what the role needs to remember. A job description should say which facts persist (customer preferences, agreed terms, decisions already made) and which do not (a one-off question, a draft that was rejected). Without that, memory becomes a pile of everything, and the agent starts to rely on things that are out of date.

Finally, give the role its own identity. An agent that works under a person's login makes it impossible to tell who did what and hard to remove access cleanly. A separate account with its own permissions can be reviewed, limited and switched off without disturbing anyone else.

Where does the agent stop and ask?

Approval boundaries are the part of the role that protects the company when the agent is wrong. Every agent will sometimes be wrong. The question is whether the error stays inside a draft or reaches a customer, a ledger or a contract.

A simple decision guide helps. For each action in the role, sort it into one of three groups:

• Do alone: reversible, low impact, inside the agent's own workspace. Examples: reading a record, preparing a draft, tagging an item for review.
• Propose, then wait: changes something shared or visible to others. Examples: updating a CRM field, sending a message to a customer, creating a task for a colleague.
• Never: actions outside the role, or with consequences that cannot be undone. Examples: deleting records, changing permissions, moving money.

When in doubt, move the action one group toward caution and relax it later, once the evidence supports it. Trust should be earned by a record of good work, not assumed on day one.

The escalation path matters as much as the boundary. When the agent stops, it should hand a person the decision, not a tangle of context: what it was trying to do, what it found, what it recommends and what happens if nobody responds. The article on where an AI agent should stop and ask goes deeper on how to design those handoffs so they do not become a new burden.

How will you observe whether it is working?

A hire gets a review. An agent should too, and the criteria belong in the job description from the start. The test is simple: could someone who did not build the agent look at evidence and say whether the role succeeded?

Good criteria are observable and tied to units of work. Think in terms of what you can see:

• Completion: how many of the intended units of work were finished, and how many were handed back.
• Quality: how often a reviewer accepted the output as it was, edited it lightly or rejected it.
• Boundaries: whether any action happened outside the approved list, which should be never.
• Escalations: whether the messages sent to humans were clear and arrived at the right person.
• Effort: how much human time the role saved or consumed, counted honestly including review.

These need a record to check against. That means the agent's work should leave a trail: what it received, what it used, what it did and what a person decided. General observability practice, as described in the OpenTelemetry primer, is built on the same idea: you can only reason about a system if it emits signals you can inspect. For a business agent, the equivalent is a readable activity log, not a technical dashboard that nobody opens.

Pair the criteria with a definition of done for each task. A definition of done for AI agents explains why the agent should show evidence of completion rather than simply report that it finished. And keep a small set of real examples with known good outcomes, so changes to the agent can be compared against something stable. Anthropic's writing on evals for agents is a helpful reference for how to think about that.

Avoid vague goals such as "be helpful" or "save time" without a way to see them. If you cannot observe it, it cannot be part of the job description.

What does a finished job description look like?

Here is an illustrative scenario. It is an example of the format, not a description of a real company.

Illustrative: a small distribution business wants help with overdue invoice follow-ups. The owner of accounts receivable writes the following role.

• Title and purpose: Receivables follow-up coordinator. Prepare polite reminder drafts for overdue invoices so the finance team can review and send them.
• Human owner: the accounts receivable lead, who receives all escalations.
• Responsibilities: read the open invoice list, check payment status, draft a reminder in the customer's preferred language, record what was proposed.
• Out of scope: negotiating payment terms, offering discounts, contacting customers directly, changing invoice amounts.
• Sources: the accounting system is the source of truth for balances; the customer record holds language and contact preferences.
• Access: read the invoice list and customer records; write drafts to a review queue; no ability to send.
• Approvals: every reminder is reviewed by a person before it goes out; any dispute or unusual note is escalated with the invoice, the history and a suggested reply.
• Success: drafts are accepted with light edits, no draft contains an incorrect balance, and the finance team can see each day what was drafted and what was held back.
• Review: the owner checks the log weekly and revisits access and wording after the first period of use.

Notice what is absent. The role does not chase customers by itself, does not decide anything about money and does not need access to the whole company. It is boring in the right way, and that is what makes it testable.

To write your own, follow these steps:

• Pick one recurring task with a clear unit of work and a person who currently does it.
• Write the purpose in one sentence and name the human owner.
• List responsibilities as verbs and objects, then write the out-of-scope list on purpose.
• Name the source of truth for each fact the role relies on.
• Specify read, write and action access separately, and give the role its own account.
• Sort every action into do alone, propose then wait, or never.
• Define the escalation message and who receives it.
• Write the success criteria as things a reviewer can observe, and decide how often you will review them.
• Test the role on real examples before it touches live work, and adjust the description, not only the instructions.

How Be Human handles this: a first engagement starts from exactly this document. We define one useful role with the client, along with the memory and tools it needs, its approval boundaries and an observable success criterion. The agent then runs under its own identity, with permissions kept under human control. Managed operations can include monitoring, recurring evaluations, integration maintenance, permission review and controlled improvements, so the job description stays true as the work changes. For a broader picture of the recurring work, see what managed AI services include.

Frequently asked questions

How long should an AI agent job description be? One page is usually enough. If you cannot describe the purpose, boundaries and success criteria on a page, the role is probably too broad and should be split into smaller roles.

Who should write it, the business or the technical team? The person who owns the work should write the first draft, because they know what good looks like and where the risks are. A technical partner then checks that the tools, access and logging can support it. A description written only by engineers tends to miss the business judgment, and one written only by the business tends to miss the practical limits.

What if the agent needs to do more than the description says? Treat it as a change request, the same way you would with a person whose responsibilities grow. Update the description, adjust access and approvals, test on real examples and then extend the role. This keeps expansion deliberate instead of accidental.

Do we need a job description if we only use a chat assistant? A lighter version still helps. Even a simple note on what the assistant is for, what information it should not receive and who checks its output reduces mistakes. The full structure matters most once the agent has memory, tools and access to company systems.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.