Give an agent a job you can manage.

Write a short job description.

In this guide, an agent means an AI system that can use tools to carry out steps in a task. The useful question is what it can do in your business and how someone will manage it.

Start with one sentence: “When an approved inquiry arrives, prepare a follow-up draft for a salesperson to review.” That is easier to test than “run our sales.”

Then write down its starting input, allowed source information, expected output, and the person responsible. Include an example of a normal task and an example where the agent should stop.

Separate drafting from taking action.

For each tool, decide what the agent can read and what it can change. Reading a lead record, drafting an email, changing the record, and sending the email are different permissions.

Start with only the access the task needs. Write down which actions require approval, such as sending a customer message, committing a price, changing a record, or making a purchase. For an initial test, a human-reviewed draft is often enough to learn whether the job is useful.

Instructions inside an incoming email or document should be treated as content to evaluate, not permission to change the agent’s job or access.

A lead follow-up example.

Starts when

An inquiry is assigned to the salesperson responsible.

Reads

The approved inquiry details, current service information, and relevant notes.

Produces

A draft follow-up with missing information called out.

Needs approval

A salesperson checks the recipient, facts, promises, and next step before sending.

Stops when

The contact is ambiguous, source information conflicts, or the request falls outside the agreed scope.

Owned by

A named employee who reviews exceptions and can pause the workflow.

This is an illustrative project brief, not a finished system or a promise of specific tool integrations.

Test the awkward cases.

Try an incomplete inquiry, a duplicate, an outdated source document, an unclear customer request, and a tool that fails. Include a case where the right response is to ask a person instead of guessing.

Check for repeated actions. A workflow should not send the same message twice just because it retried after an error. If a step changes a system, plan how the owner will spot and correct a mistake.

Keep a record of the input, the action taken or proposed, the review, and any error. Use the information your team needs to understand what happened, while limiting access to that record appropriately.

Decide who runs it after launch.

Name the person who checks failures, approves changes, updates source information, and can stop the workflow. Agree on what happens when that person is away.

Review the task again when a connected system, instruction, data source, or model changes. Watch for useful results and rework, as well as tool costs and failures. A workflow that ran yesterday still needs an owner today.

If you need help mapping a known problem, start with the AI audit. Building and managing workflows or agents is separately quoted work.