How to choose your first task to automate
Start with work that repeats, has clear inputs, and produces a result you can check. A practical guide to finding your first useful runbook.
A good first task to automate repeats regularly, starts with clear inputs, and produces an output you can check. I would start with a draft or research summary whose result you can review before it affects anyone else.
It is easy for a request to prepare a weekly update to grow into a plan for an entire reporting process. Each additional responsibility brings more decisions about what the agent should do. I prefer to begin with a task I can describe in one sentence and evaluate in a few minutes.
The point of a first runbook is to learn whether the instructions hold up on another example. These are the questions I would use to choose that starting task.
Look for work you already repeat
Start with your own recent work. Which tasks sent you through the same sequence of pages or applications? Perhaps you collected links for a research note, assembled a status summary, or copied a fixed set of fields into a review document.
Repetition gives you examples to compare. You can see which inputs change and which decisions stay the same. If you cannot yet explain how you do the task yourself, spend time clarifying the process before asking an agent to repeat it.
Choose an output you can check
“Research this company” leaves a lot unspecified. “Create a table containing the company’s product, target customer, pricing-page link, and the source for each finding” gives you a result to inspect. You can check the fields against the source pages and mark anything that could not be found.
Write the acceptance criteria before you run the task. If a field is missing, should the agent leave it blank, label it unknown, or stop? If two sources disagree, should it include both? These small choices make review much easier.
Keep the first scope small
A draft or a research summary is often a manageable starting point because you can inspect it before it affects anyone else. Sending the summary to customers introduces additional decisions about recipients, wording, timing, and authorization. Treat that as a separate responsibility when designing the task.
For example, start with “prepare a weekly project update from these notes.” Give the runbook a date range, a fixed set of sources, and an output structure. Review the draft yourself. Once that part is useful, decide whether the next step belongs in the same runbook or should remain a human action.
Compare a few candidates
You do not need a scoring system to get started. Write down three tasks and answer these questions for each. Prefer the one whose answers are already clear.
- How often do I do this, and can I show a recent example?
- What information does the task need at the start?
- Which applications or pages does it use?
- What would a correct result look like?
- What should happen when a source is unavailable or a detail is missing?
- Can I review the output before it changes something important?
Let the first runs guide the next step
Record one example in Infragrid, review the resulting runbook, and try it on another case. Keep notes on what you had to correct. A recurring correction is a clue that an instruction, input, or completion check needs more detail.
Count the review and correction work when judging whether the task is useful. A fast run that needs extensive repair may not save effort. A modest task that consistently produces an easy-to-review draft can be a better foundation. Expand the scope when the existing result deserves it.
From reading to doing
Turn your next task into a runbook.
Capture how you work, refine the instructions, and give your agent a repeatable starting point.