# Choosing a Workflow (/concepts/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 job [#what-makes-a-good-first-job]
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](/concepts/triggers-and-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 job [#what-makes-a-poor-first-job]
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 candidates [#compare-two-or-three-candidates]
Write down each candidate and fill in the same four rows. This example compares three common jobs.
| | PO entry | Quote preparation | Supplier chasing |
| -------------- | ------------------------------------- | ---------------------------------------- | ------------------------------------------- |
| Starts with | Customer email with a PO attached | A request by email, phone, or from a rep | An open-PO report each morning |
| Inputs | Mostly the same fields | Different every time | Spread across supplier websites and inboxes |
| Finished state | Sales order draft in the order system | Quote sent to the customer | Updated expected ship dates |
| Easy to check? | Yes | Partly | Partly |
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](/recipes/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 small [#keep-the-scope-small]
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 done [#watch-the-job-being-done]
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](/concepts/human-in-the-loop).
A job map for customer replies to proofs. It starts with the trigger, lists
each place the work looks things up, and splits clean approvals from the
exceptions a person reviews in Slack.
## Decide how you will measure it [#decide-how-you-will-measure-it]
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](/build/define-a-workflow) template, then try it on past work as [Testing a Workflow](/concepts/testing-a-workflow) describes.
## Where to go next [#where-to-go-next]
Write the job down before you build.
What an agent is made of.
How a job starts.
Where people review and approve.