Choosing a Workflow

The best first job for an agent is one that happens often, has a clear start and a clear finish, and is easy to check. Small and testable beats big and impressive. A job you can judge within a week or two tells you quickly whether the agent works.

What makes a good first jobCopy Anchor Link

A good first job passes five checks.

1. It happens often. Saving a few minutes only matters if the job repeats. Five minutes, 80 times a day, adds up faster than a two-hour report once a month.
2. It has a clear start. Something kicks it off, such as an email with a PO attached, a request posted in Slack, or a report that arrives every morning. See Triggers & Inputs.
3. It has a clear finish. You can say what a correct result looks like. "When a PO arrives, prepare the sales order" can be tested. "Help the team move faster" cannot.
4. The information is within reach. What the agent needs lives somewhere your team can already get to, such as an inbox, an order system, a supplier website, or a spreadsheet.
5. A mistake is easy to catch. Someone can review the unclear cases while you test, and errors show up before they cause real damage.

The job does not need to look identical every time. It needs a repeatable sequence, with the judgment calls in clear places. A person can keep making those calls while the agent does the looking up around them.

What makes a poor first jobCopy Anchor Link

A job is a poor first choice when it fails one of the five checks. Common signs:

• It happens a few times a year, so you would wait months to learn anything.
• It has no clear start or finish, such as "keep customers happy."
• The information it needs sits in someone's head or in a system nobody on the team can open.
• A mistake is expensive or hard to undo, such as sending a payment, and nobody would catch it in time.
• Every case is different, so there is no repeatable sequence to write down.

For example, "decide which customers get a discount" is a poor first job. It happens rarely, the judgment changes every time, and a wrong answer costs real money. "Look up the discount already agreed with a customer and put it on the order" is a good one, because the answer already exists and the agent only has to find and apply it.

Compare two or three candidatesCopy Anchor Link

Write down each candidate and fill in the same four rows. This example compares three common jobs.

PO entry wins here. Every order starts as an email with a PO and ends as a draft in the order system, so you can tell within days whether it works. The Purchase Order Entry recipe shows that job worked through in full. Quoting takes more time per request, but no two requests look alike. Supplier chasing is a job people dislike, but the answers sit in too many places to check cleanly on a first try.

Keep the scope smallCopy Anchor Link

Start with one slice of the work, such as PO intake for one team or for your top twenty customers. Widen it once the first slice runs well.

Watch the job being doneCopy Anchor Link

Before you build anything, sit with the person who does the job. Write down what starts it, every screen they open, the different forms the input takes, and what they do when something is missing. The map shows you where the exceptions are. Those become the cases a person reviews. See Human in the Loop.

Decide how you will measure itCopy Anchor Link

Write down how long the job takes today before you change anything. Then measure results, not activity: time per job, hours given back to the team, backlog, how fast customers hear back, and how often a person has to fix the agent's output. If a job drops from eight minutes to two but someone spends five minutes fixing it, nothing was saved. Once you have picked the job, write it down with the Define a Workflow template, then try it on past work as Testing a Workflow describes.

Where to go nextCopy Anchor Link