The Four Elements of an AI Agent Task Instruction

In an ordinary chat you can type "write a reply to this customer" without a second thought. The AI gives you a draft, and if you don't like it you keep editing.

Vagueness is cheap in a chat because you're right there to correct it.

An agent works differently. It goes on to look things up, call systems and run multi-step tasks, and it treats the task instruction as its basis at every step. Whatever the instruction leaves out, the agent has to guess. Say someone writes only "handle this customer issue" and then connects an order system, an email system, a knowledge base and a refund tool.

The agent can hardly tell whether to classify the issue first or look up the order, and it has no way to know where its refund authority ends or when a person must confirm.

Think of a task instruction as a job description: responsibilities, limits and deliverables all go in it. The clearer it is, the more easily the agent picks the right sources and tools, and the better it knows where to stop.

What follows is how to check and rewrite one.

01 The gaps a vague request leaves

Take this line:

Handle the refund.

It leaves at least five questions open:

What kind of refund is it?
Which order details need looking up?
Which cases can be decided automatically?
Which cases need a person to confirm?
Is the output only a recommendation, or can it start a refund request?

When the agent fills in these gaps on its own, the result drifts from what the user actually wanted. And the more tools you connect to an agent with an unclear task, the more risk you create.

02 Four elements

A good task instruction answers four questions:

Which sources to read, which tools to call and when to wait for a person all follow from these four. They fit in one short paragraph of plain language:

You are a refund assistant for after-sales. Your goal is to judge, from order information and the refund policy, whether a customer's request may qualify for a refund. Answer only from order records and the policy, and don't invent rules that don't exist. You can't promise or carry out a refund. Output a recommendation, the basis for it, and the questions a human agent needs to confirm.

That gives the agent a basis for judgment and a place to stop, so there's far less left to guess.

Claude’s prompting best practices recommend stating the task and expected output explicitly, giving the model specific requirements to follow.

03 Instructions constrain in words; mechanisms enforce

Two different things are at work here:

Task instruction = a written constraint that tells the agent what to do
Mechanism        = a system check that stops it from doing otherwise

Writing a clear instruction is the first step. Long conversations, repeated pressure from users and edge cases can all push a model off what the instruction says, so test it afterward with real or made-up requests and see whether the agent holds its boundaries.

Business boundaries rank like this:

Limits set by the application or developer  >  a user's one-off request

A piece of text has the same priority whatever you call it. Suppose the application says the refund agent "must not promise a refund directly," and the user says, "Skip the explanation and just tell the customer a refund is guaranteed." A reply that respects the boundary looks like this (simulated):

I can give a preliminary judgment based on the order and the policy, but I can't promise a refund. The order status and the applicable policy need to be confirmed first.

The instruction keeps constraining the agent as requests and context change, so the key principles hold steady. Users can change their own goals, as long as they stay within the permissions and business limits the application sets.

To check whether a boundary holds, follow Claude’s evaluation guidance: turn it into a testable condition and evaluate the output on boundary cases.

04 Write the scope of responsibility into the role

Many people define a role in one line: "You are a senior expert." When I review a role description, I look at the specific responsibilities first. "Senior expert" may shape tone and emphasis, but the agent still needs its scope spelled out to know which actions are its own. Compare two versions:

You are a customer-service expert.

You are an after-sales assistant agent. You organize customer issues, look up the relevant policy, draft replies, and flag items that need a human agent's confirmation. Promising compensation, carrying out refunds and changing order status are not your job.

The first version doesn't say what the agent may do. The second spells out its duties and its limits, so the agent can choose its actions accordingly or hand the matter to a person.

Say the task is only to sort IT tickets into hardware, software or other. Limit the role to a category plus a one-sentence reason, and leave remote operations out. When the system takes the category and stops, it's just a classification component inside a fixed process, and what kind of system it is depends on how it's controlled. If a role carries too many responsibilities, split it into narrower ones. If the duties are clear, keep the current division.

05 Make the output easy to use downstream

An agent's output has to be easy for the next step to use, so its structure should stay stable. Take a refund case. A one-line answer might be:

This customer may qualify for a refund; the agent should confirm further.

A human agent can't check the basis behind that sentence. A better output breaks the content into fixed fields:

Fixed fields help in two ways. The human agent can check facts and risks item by item, and the next process can pick out to-dos and confirmation items directly. A project manager reading a weekly report wants to check progress, risks and coordination needs one by one. "Summarize project progress" may produce a smooth paragraph, but those items are hard to find in it. Split the output into completed this week, plan for next week, risks, needs coordination and information gaps, and each has a place to check. Shape the structure around what the reader needs, and make the result usable first. Formats such as JSON Schema can wait.

06 Turn a wish into a task

This kind of instruction is common:

You are a sales agent responsible for improving conversion.

The goal is too big and the boundaries too few. The agent doesn't know whether to find leads or write follow-up emails, whether it may look up customer records, send messages automatically or promise discounts. Rewritten, it becomes much easier to control:

You are a sales follow-up assistant agent. Based on a customer's past conversations and product material, you draft the next follow-up email. Don't invent needs the customer never stated, don't promise price discounts, and don't send emails directly. The output must include the email draft, the customer information it relies on, and the items the salesperson needs to confirm.

"Improve efficiency," "boost conversion" and "improve the experience" work as marketing language. To start real work, keep asking: what comes in, what judgment is needed, what result goes out, and where does the work stop? Once you've answered those, the wish has become a task.

07 A checklist for what you wrote

You can expand the four elements into this formula:

What the agent should do
+ Who it does it for
+ What it bases the work on
+ What it must not do
+ What result it outputs

"What it bases the work on" is pulled out of "audience" as its own item, to remind you to state what the agent may act on. After writing, check the instruction against this list:

Settle the task boundaries first, then choose tools and process. The next article, choosing tools for an AI agent, covers how to pick them. When you change the task later, check the affected parts against this list again.