Pick Work Worth Automating

The real business problem

Most agent projects die at the whiteboard, not in the code. Someone picks a task that sounds impressive, the team builds around it for a month, and then it never gets trusted enough to run on its own. The model was fine. The work was wrong.

The failure is almost always the same. The task had no clear finish line, or the inputs were a mess, or nobody could tell whether the output was actually right without redoing the work by hand. When that is true, no amount of clever prompting saves you.

So before you touch a model, you need a way to look at a piece of work and say, honestly, whether an agent belongs anywhere near it. That is what this chapter gives you. After it, you will be able to score a real task, rank a few candidates and pick a first use case you can defend to a room full of skeptical people.

The core idea

The right work to automate is not the most exciting work. It is the most checkable work that also has real value.

That distinction matters more than anything else in this playbook. Exciting work is the demo that makes people say wow. Checkable work is the task where you can look at the result and know, quickly and cheaply, whether it is correct. An agent you cannot check is an agent you cannot trust, and an agent you cannot trust gets switched off within a week.

So you are hunting for the overlap of four things. Real value if it runs without you. A clear boundary around what it does and does not touch. Inputs that are good enough to act on. And an outcome you can verify without redoing the whole job. Miss any one of those and the project gets shaky in a way that is hard to fix later.

A simple model

Score every candidate task from one to five on four dimensions. Keep it on one page.

• Value if automated. How much time, money or risk does this remove if it runs on its own. Low value work is not worth the build cost, even when it is easy.
• Boundary clarity. Can you say in one sentence what the task does and where it stops. Fuzzy scope is the single biggest red flag on this list.
• Input quality. Are the inputs complete, consistent and available. Messy or missing inputs raise the cost of everything downstream.
• Verifiability. How easily can you tell the output is correct. This is the one people skip, and it is the one that decides whether you can ever trust the thing.

Add the four scores. A task that lands high on all four is a strong first candidate. A task that scores a nine because it is dazzling on value but a two on verifiability is a trap, and the sum hides it. Look at the shape, not just the total. One low score, especially on boundary or verifiability, should stop you.

A concrete example

Take an accounting firm choosing its first agent. Three candidates come up.

Candidate task	Value	Boundary	Input quality	Verifiable	Read
Draft a monthly management report per client	5	3	3	4	Strong, once scoped tightly
Answer any client question by email	4	1	2	2	Exciting, uncheckable, avoid
Categorise bank transactions for review	4	5	4	5	Best first use case

The email answering agent is the one everyone wants to demo. It also has no boundary and no cheap way to check it was right before a client reads it. The transaction categoriser is boring by comparison. It also has a clear scope, clean inputs and an outcome a human can verify in a glance, because a category is either sensible or it is not. Start there. Win trust on the boring, checkable task, then move up the ladder.

Notice the report task in the middle. Good value, but the boundary score is soft. If you narrow it to one report type with a fixed template, the boundary score climbs and it becomes a real second candidate. Scoping is not just measurement. It is how you turn a shaky task into a buildable one.

The implementation pattern

Here is the pattern I use to go from a list to a decision.

1. List three to five processes you repeat every week. Real ones from your own work, not aspirations.
2. Write the goal of each in one sentence. If you cannot, the boundary is not clear enough yet. That is useful information, not a failure.
3. Score all four dimensions, one to five. Be honest on verifiability. Ask “how would I know this was wrong” and if the answer is “I would have to redo it,” score it low.
4. Rank by shape, not just sum. Kill anything with a one or two on boundary or verifiability, however high the value.
5. Pick one. Write two sentences on why it wins. That written reason is the thing you defend later when someone asks why you did not start with the flashy one.

Once you have your winner, you face a second decision. Do you build it, buy it, or bring in a specialist. Match the choice to how standard the task is and how much of your real edge lives inside it.

Route	Use it when	Watch out for
Buy an existing tool	The task is common and someone already sells a good agent for it	Your data or process is odd enough that the tool cannot bend to fit
Build it yourself	The task carries your real edge, or no tool fits your inputs and checks	You underestimate the verification and workflow layers, not the model
Bring in a specialist	High value, high risk, and you lack the in-house skill to build it safely	Handing over a task you have not scoped, so the specialist scopes it for you

The order matters. Look for something to buy first, because a task common enough to be sold is rarely worth building from scratch. Build when the work carries your edge or the checks are specific to you. Bring in help when the value is high, the risk is real and the skill is not in the room yet. In every case you still do the scoring first. A specialist handed an unscoped task will scope it for you, and you will pay for that twice.

What breaks

The second failure is choosing on excitement. The demo-worthy task and the trustworthy task are rarely the same task, and the difference does not show up in a five minute pitch. It shows up three weeks later when nobody can tell if the output is right.

Decision rules

There are also tasks you should simply not hand to an agent. Anything where a wrong answer is expensive and cannot be caught before it lands. Anything where the rules change constantly and there is no stable definition of correct. Anything that is really a judgement call your customers expect a named human to own. Knowing these cases is not caution. It is the skill.

Related lab

The lab turns this chapter into a worksheet. You take three to five real processes from your own work, score each on value, boundary clarity, input quality and verifiability, then pick one first use case and write down why it wins. It is a one page opportunity map, not a strategy deck, and it is the highest leverage hour you will spend in this book.

◆ Related lab Map an Agent-Worthy Workflow

Practical checklist

What changes after this chapter

You stop picking agent projects by what looks impressive and start picking by what you can check. That one change removes most of the reasons agent projects fail before any code is written. You now have a scored, defensible first use case instead of a wish.

Next: Chapter 3, Give the Agent the Right Context.