Pick the Right Job

The most expensive agent I have ever seen worked perfectly. It ran on schedule and never crashed. The output was clean. It was also pointless. The founder spent 3 weeks building it, and during those same 3 weeks a revenue leak sat in plain sight, in an inbox he checked every morning.

You will get that story in full below, with the real numbers. First, the two tools that would have caught it before a single line was built. By the end of this lesson you will have a scored shortlist of 3 processes from your own business, and one winner picked by numbers instead of by whichever task annoyed you most recently.

Three questions before you build anything

Every candidate task has to survive three questions.

Is there a clear deliverable? You should be able to point at the thing the agent produces. A drafted email is a deliverable. You can open it and send it. "Better visibility into the pipeline" is not a deliverable. It is a wish. If you cannot describe the output as a file or a message that exists after each run, the project has no finish line and no way to check its own work.

Is it a hot-button problem? Someone should be complaining about this task this week, out loud. Quotes going out late passes, because a prospect said so and a deal died. Tidier folders fails. Nobody has ever lost a customer to a messy folder. If the pain is quiet, the agent's output will be ignored exactly the way the problem was.

Is it templateable? The task has to happen the same basic way, over and over. A weekly report passes: same structure, new numbers, every Monday. A one-off data migration fails. You would spend the build time once and use the result once. Agents earn their build cost back in repetitions, and a task that never repeats never pays you back.

The rule is strict. All three yes, or it does not get built. Two out of three is not a near miss. It is a no, and the cheapest kind, because you found out before opening a single tool.

The driver tree finds the lever

The filter tells you what is worth building. It does not tell you what to build first. For that, draw a driver tree.

Start at the top. Profit = Revenue - Costs. Then break revenue into the numbers that produce it. For a services business:

Revenue = quote requests x win rate x average job size

Keep decomposing each branch until you hit a number that one specific process controls. Win rate is not controlled by "sales" in general. It is controlled by things you can name, and the speed and quality of the quotes you send is near the top of that list. Costs decompose the same way if your leak is on the spend side, but for most small services firms the first agent belongs on the revenue branch.

Once your surviving tasks each sit on a branch, ask the question that ends debates: which process, improved 2x, moves the top number most? Double the quality of your meeting summaries and profit does not move. Halve the time it takes to send a quote and win rate moves, which moves revenue, which moves profit. The tree turns "I feel like this matters" into arithmetic.

Score it

Here is the working method, start to finish.

List 5 recurring tasks from your week. Real ones, taken from your calendar and your inbox, not tasks that sound automatable. If your team does the work, ask them. They know where the repetition lives better than you do.

Run each task through the filter. Answer yes or no to each question. A maybe is a no you have not admitted yet.

Drop the misses. Expect casualties here. A list of 5 usually comes back as 2 or 3 survivors, and that is the filter doing its job. A shortlist that loses nothing was not a real list.

Place the survivors on your driver tree. For each one, name the exact number it touches. If you cannot name the number, the task goes back to the reject pile until you can.

Pick the branch closest to money. If two survivors tie on the tree, take the one with the louder complaint behind it.

The mistake, and the fix

A 12-person services company decided to take AI seriously. The founder picked the task that irritated him most: meeting notes. Around 6 hours of calls every week, and nobody could remember what was agreed. So he built a summarizer. It listened to recordings and filed tidy summaries in a shared drive. 3 weeks of evenings went into the build, and the first demo worked.

The scoreboard after month 1:

Build time: 3 weeks
Notes generated, month 1: 47
Notes opened by anyone: 3

Same month, in the quoting inbox:
Quote requests received: 31
Average time to send a quote: 2 days 4 hours
Deals lost to a faster competitor (the prospect said so): 4

47 summaries written by a machine, 3 read by a human. In the same month, 4 deals died waiting for a quote, and 1 prospect was polite enough to explain why on his way out.

Run both tasks through the filter and the whole month becomes avoidable:

Task                    Deliverable?  Hot-button?  Templateable?  Verdict
Meeting-notes summary   yes           no           yes            drop
Quote follow-up draft   yes           yes          yes            build

The notes agent fails question 2. Nobody was complaining about missing notes, and 3 opens out of 47 is what a missing hot-button looks like in production data.

The driver tree says the same thing in numbers. The 2-day lag sits directly on win rate. 31 requests came in and 4 losses traced to speed alone. No other process in the business touched revenue that directly.

The founder deleted the notes agent. Then he built the quote agent: a request arrives, the agent drafts the follow-up, a human reviews and sends it within the hour. It paid for itself in the first week, with one saved deal worth more than the entire build.

Recap

A task earns a build by passing three questions: clear deliverable, hot-button problem, templateable. All three yes or it dies. The driver tree then ranks whatever survived, and the branch closest to money wins. Do not trust your annoyance. Trust the arithmetic.

Next lesson: the directive. Your winner gets a written job description, and you will see why that text file matters more than any code in the system.