How to Write a Job Description for an AI Agent

An AI agent should have a job description too.

Businesses are starting to give AI agents access to: Email. CRM systems. Documents. Calendars. Databases. Internal knowledge. Business software. The ability to take actions. But sometimes the instruction behind all that access is little more than: "Help us with sales."

That would be a terrible job description for a person. It is not a particularly good one for an AI agent either.

Before deciding which model to use, which tools to connect or how autonomous an agent should be, define the job. What is it responsible for? What information does it need? What is it allowed to do? What must it never do? When does a person become involved? How do you know when the job is complete? That is the beginning of a useful AI agent.

Start with the job. Not the agent.

Do not begin with: "We want an AI agent." Begin with: "We have a piece of work that needs doing." For example: Every website enquiry needs to reach the appropriate salesperson. Salespeople need useful context before meetings. Meeting commitments need to become next actions. CRM updates need preparing after conversations. Active opportunities need checking for missing next actions. Account information needs gathering before a salesperson contacts someone.

Those are jobs. Once the job is clear, you can decide whether it needs: Automation. AI assistance. An AI agent. A person. Or some combination.

Bad job description: "Help us sell more."

This sounds like an objective. It is not a useful agent job. What should the agent actually do? Generate leads? Research accounts? Send emails? Qualify enquiries? Update CRM records? Prepare meetings? Monitor opportunities? Follow up? Create proposals? Negotiate? How does it know when to act? What information can it use? What is it allowed to promise? When should it stop? Who handles exceptions? There is too much hidden inside the instruction.

A better job description.

"Make sure every new website enquiry reaches the appropriate salesperson with the relevant context." Now we have something we can design. The agent may need to: Detect the enquiry. Understand what the person wants. Identify the organisation. Check whether an existing relationship exists. Gather relevant account context. Apply agreed routing logic. Identify missing information. Prepare the handover. Escalate unusual enquiries. That is a defined responsibility.

Better still: add the boundaries.

Now we are describing a system that can actually be built and tested.

1. JOB: What is the agent responsible for?

Write this in one sentence if you can. A useful structure is: "The agent is responsible for [piece of work] so that [clear outcome]."

Examples: "The agent is responsible for preparing salespeople before scheduled customer meetings so they have the relevant account context." "The agent is responsible for identifying active opportunities without a clear next action so they can be reviewed by the appropriate salesperson." "The agent is responsible for preparing approved CRM updates after sales meetings so the salesperson does not have to recreate the meeting manually." "The agent is responsible for gathering relevant account information before first sales conversations so the salesperson can prepare efficiently."

Notice what these do not say: Increase revenue. Improve sales. Delight customers. Maximise conversions. Those may be business objectives. They are not specific jobs.

Test the job description. Ask: Could two reasonable people read this and agree what the agent is responsible for? Could we recognise when the job has been completed? Could we recognise when the agent has gone outside the job? If not, make it narrower.

2. TRIGGER: What starts the job?

An agent should not simply wander around your systems looking for something useful to do. Define when the work begins. Examples: A website enquiry arrives. A meeting is added to the sales calendar. A sales meeting ends. An opportunity changes stage. An opportunity has no next action. An account changes owner. A customer replies. A task becomes overdue. A salesperson requests research. A proposal is approved for sending.

The trigger may be: An event. A schedule. A person. A system state. A defined condition. The important part is that the agent knows: Why am I working on this now?

3. OUTCOME: What does "done" look like?

This is one of the most important questions. Suppose the job is: "Handle new enquiries." When is that complete? When the email has been read? When the lead has been classified? When a salesperson has been assigned? When the customer receives a response? When a next action exists? When the salesperson accepts ownership? These are different outcomes.

Define the end state. For example: "The job is complete when the enquiry has an appropriate owner, the owner has the required context and a next action has been recorded." Now the agent has somewhere to stop.

Agents need stopping conditions.

Otherwise responsibility can become vague. A useful agent should know when: The job is complete. The job cannot be completed. A person needs to take over. The situation is outside scope. Further action is no longer appropriate. The agent should not keep acting simply because it still can.

4. INFORMATION: What does the agent need to know?

Start with the job. Then identify the minimum information required to perform it. For an enquiry agent, that might be: The enquiry. CRM account records. Relevant contact history. Service information. Routing criteria. For a meeting preparation agent: Calendar information. Relevant CRM history. Previous meeting information. Outstanding actions. Approved account context. For a follow-up agent: Previous conversation. CRM status. Outstanding commitments. Next action. Relevant customer response.

The answer should not automatically be: Everything. More access is not automatically better. Every information source should have a reason. Ask of each source: Why does the agent need this? Which part of the job uses it? Does it need the entire source or only certain information? Does it need read access only? What happens if this information is missing? What happens if this source conflicts with another? If you cannot explain why the agent needs access, question whether it should have it. Permission should follow the job.

5. ACTIONS: What can the agent actually do?

Separate understanding from action. An agent might be capable of: Reading a CRM record. Searching approved information. Classifying an enquiry. Preparing a summary. Recommending an owner. Creating a task. Updating a field. Drafting an email. Sending an email. Scheduling a meeting. Changing an opportunity stage. Escalating an issue. Those actions do not all carry the same consequence. List them individually.

Do not simply write: "CRM access." What does that mean? Read contacts? Search accounts? Create contacts? Change opportunity values? Delete records? Add notes? Create tasks? Actions should be explicit.

6. AUTHORITY: What may happen without a person?

Capability and authority are different. Your agent may technically be capable of sending an email. That does not mean it needs permission to send one independently. Use the Agentic Selling Authority Ladder.

Assign authority action by action. Not agent by agent.

Imagine a Follow-Up Agent. It may: READ CRM information, previous approved communications, outstanding actions. RECOMMEND which opportunity needs attention. PREPARE a follow-up message. ACT WITHIN LIMITS create an internal reminder. ACT WITH APPROVAL send customer-facing communication. ESCALATE a commercially sensitive response. One agent. Several authority levels. This is much more precise than: "The agent has medium autonomy."

7. LIMITS: Write down what the agent must not do.

This part is frequently missed. A job description should include boundaries. For example: Must not change pricing. Must not agree contractual terms. Must not send external communication without approval. Must not create a new account when a possible duplicate exists. Must not use information outside approved sources. Must not continue follow-up after an agreed stop condition. Must not guess missing customer information. Must not change opportunity stage without approval. Must not make promises on behalf of another team. The exact limits depend on the job. The point is to make them explicit.

Negative instructions are not enough.

Design the workflow around the boundary. Writing: "Never make pricing commitments." is useful. But stronger design may also mean: The agent does not have permission to change pricing fields. Pricing information comes only from an approved source. Unusual pricing requests automatically escalate. Customer-facing messages involving pricing require approval. Important controls should exist in the workflow, not only inside the prompt.

8. ESCALATION: When should the agent stop and ask a person?

Escalation is not failure. It is part of the job. Examples: The account cannot be identified reliably. Two records may refer to the same customer. Required information is missing. Two systems conflict. The enquiry is outside normal scope. The customer asks for an exception. A commercial commitment is requested. The AI cannot determine the correct action. The situation is sensitive. A workflow rule has been exceeded. An external action carries higher consequence than the agent is allowed to take.

The agent should know: I am no longer the right decision-maker.

Define who receives the escalation.

"Ask a human" is still incomplete. Which human? The opportunity owner? Sales manager? Technical specialist? Finance? Operations? A shared queue? Someone selected by routing logic? And what context should they receive? A good escalation should not say: "Something went wrong." It should say: What happened. What the agent knows. What is unclear. What action was attempted. What decision is required. That makes escalation useful.

9. RECORD: What should the agent record about its work?

This depends on the workflow, but you may need a record of: What triggered the job. Which account or opportunity was involved. What information was used. What recommendation was made. What action was prepared. What was approved. What action occurred. What was escalated. Why an action stopped. What system changed. This does not mean storing every possible piece of model activity forever. It means deciding what operational record the business needs.

Logging is different from filling the CRM with AI output.

Record what is useful. Your CRM does not need: Every reasoning step. Every generated summary. Every research result. Every internal AI message. Every intermediate output. It may need: Relevant customer information. Agreed next action. Approved meeting summary. Useful opportunity context. Completed activity. Store information because the business needs it. Not because AI generated it.

10. MEASURE: How will you know whether the job is useful?

Do not start with: How many actions did the agent perform? Ask what problem the job was meant to improve. For an enquiry agent: Are enquiries reaching the correct owner? Is useful context arriving with them? Are fewer enquiries sitting without action? For a meeting preparation agent: Do salespeople spend less effort gathering context? Do they use the briefing? Is important information missing? For a CRM agent: Is manual reconstruction reduced? Are prepared updates useful? How often are they corrected? For a follow-up agent: Are commitments easier to track? Are unnecessary follow-ups avoided? Does the correct person know what needs attention?

Activity is not value.

Example job descriptions.

Four defined jobs, each written the same way. Notice how the authority sits with individual actions, not with the agent as a whole. You can find more worked examples in our AI sales agent examples.

The job description should exist before the prompt.

Prompt engineering is not process design. You can spend hours refining instructions such as: Be concise. Think carefully. Check your work. Use this tone. Follow these steps. But if the underlying job is vague, the prompt is being asked to repair a process problem. Define: Responsibility. Trigger. Outcome. Information. Actions. Authority. Limits. Escalation. Then turn that design into the technical instructions the agent needs. The prompt comes later.

The job description should exist before choosing the model.

Different AI models and platforms have different capabilities. But model selection is easier once you know: What the agent must understand. What information it must process. Which tools it needs. What actions it performs. How quickly it needs to respond. How important accuracy is. What controls surround it.

Choose the technology around the job. Not the job around the technology.

The job description should exist before connecting tools.

Access should have a reason. Do not begin by connecting: CRM. Email. Calendar. Drive. Slack. Documents. Database. Browser. Then ask what the agent could do. Start with the job. If it needs CRM read access, provide appropriate CRM read access. If it does not need email, do not connect email. If it only needs approved documents, do not provide access to the entire document environment. Permission should follow the job.

One agent or several? Follow the responsibilities.

Suppose you want AI to: Research an account. Prepare a meeting. Update CRM. Follow up. Monitor the opportunity. That could potentially become one enormous agent. But ask whether these are actually separate jobs. A Research Agent gathers context. A Meeting Agent prepares the salesperson. A CRM workflow prepares records. A Follow-Up Agent monitors next actions. Separating responsibilities can make: Permissions clearer. Testing easier. Failures easier to understand. Authority easier to control. You do not need to split everything into dozens of tiny agents. But neither should one agent become responsible for your entire sales department.

If the job description keeps growing, stop.

You may be designing several jobs. Watch for: "And it should also..." Then another. Then another. Then another. Soon your Enquiry Agent: Handles enquiries. Qualifies leads. Researches companies. Writes proposals. Schedules meetings. Updates the CRM. Runs follow-up. Monitors the pipeline. That is not necessarily one job. Break the process into responsibilities.

Give the agent the smallest useful job.

A smaller job is easier to: Understand. Build. Test. Permission. Observe. Measure. Improve. If the first agent performs well, you can extend the workflow. You do not need to begin with maximum scope.

A job description is not permanent.

Change it when the evidence says you should. You may discover: The agent has information it does not need. A particular action should require approval. A common escalation could become a rule. An independent action should move back to approval. Two responsibilities should be separated. A human step is unnecessary. A human step needs adding. The job can evolve. So can its authority. Autonomy should earn its place. And it should be possible to take it away again.

Before you build, answer these ten questions.

1. What exactly is the agent responsible for?
2. What starts the job?
3. What does successful completion look like?
4. What information does it genuinely need?
5. What specific actions can it perform?
6. Which actions require human approval?
7. What must it never do?
8. When should it stop and escalate?
9. What should be recorded?
10. How will you know whether it made the process better?

If you cannot answer one of them yet, that is useful. You have found something that needs designing before the agent starts acting.

Frequently asked questions

Before you give an agent tools, give it a job.

Do not start with: What model should we use? Which agent platform should we buy? How many tools can it connect to? How autonomous can we make it?

Start with: What is this agent responsible for? Then: What starts the job? What does it need? What can it do? What can it not do? When does a person take over? What does done look like? That is the foundation. An agent should have a job description too.