From screen recording to a reusable runbook
Your team already knows how the work gets done. Here is how to turn that knowledge into clear, repeatable instructions for an agent.
A reusable runbook describes a task’s inputs, instructions, decisions, and completion checks. A screen recording supplies a worked example; reviewing that example is how you make the instructions clear enough to use again.
My starting point is a task you could show a colleague: open a request, find the matching record, check a few details, and prepare the result. The useful part of the demonstration is the reasoning behind those steps, including when to stop and ask for help.
With Infragrid, we bring recording, runbooks, and agent execution into the same workspace. Here is how I would turn a single demonstration into a runbook worth testing.
Start with one complete example
Choose a task with a clear beginning and end. For example, prepare a summary of a new vendor request using the request form and the existing vendor record. Start when you open the request and stop when the summary is ready for review.
Capture the parts that explain the task, including the checks you make before moving on. If you compare the company name against an existing record, that comparison matters more than the exact number of clicks it took to reach the page. A useful demonstration makes those decisions visible.
Turn the example into explicit instructions
Review the captured steps before treating them as reusable instructions. A recording may include a wrong turn, an unrelated tab, or a value that belongs only to the example. Remove the distractions and describe the intended action at each step.
Replace vague instructions such as “check the details” with the actual comparison: “Compare the business name and address on the request with the vendor record. If either differs, include the discrepancy in the summary.” This gives both a person and an agent something concrete to follow.
- State the source to read and the destination to update.
- Name the information that must be checked before continuing.
- Describe what to do when information is missing or inconsistent.
- Define the result that counts as complete.
Separate changing inputs from the instructions
The vendor in your demonstration is an example, not the task itself. A request URL, company name, date range, or destination document may change every time. Identify these values as inputs so the runbook describes the recurring task without depending on yesterday’s record.
Keep the rules stable and the inputs specific. “Summarize this request” needs an actual request to operate on. “Use this vendor’s contact details for every request” accidentally carries one example into all future runs. Reviewing this distinction is one of the most useful parts of preparing a runbook.
Test the result on another case
Try the runbook on a second request while you can inspect the result. Check that the summary refers to the new vendor, includes the required fields, and calls out missing information. A run that reaches the final step can still produce the wrong output.
Then try an exception: a request with no matching record or a missing address. Decide whether the right behavior is to stop, ask for help, or return a partial summary. Write that decision into the instructions instead of leaving it implicit.
A useful first runbook does one task clearly. Once you can explain its inputs, review its steps, and verify its output, you have a much better starting point for repeatable agent work.
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.