Most of the testing you do while designing a thunk is hands-on: you push something through the workflow, watch what the agent does with it, change an instruction, and push it through again. This article covers the controls that make that loop fast — and safe to run against a workflow that sends email or writes to other systems.
Once a design is stable, move the cases you care about into a repeatable suite. See Evals / Automated Tests.
Start by turning on test mode
Before you exercise a half-finished workflow, put the thunk into test mode. Open Tests in the left nav — it is available to thunk owners and admins — and go to the Test Settings tab.
Turn on Treat all rows as test rows. Every work item is then treated as a test work item, so the rest of the settings on that tab — and any step marked to be skipped for test work items — apply to everything you run, not only to work items that carry test assertions.
The setting that matters most while testing by hand is Test email. By default it is set to Suppress: outbound email from a test work item is routed to a no-op mailbox and nothing leaves the system. You can instead Redirect it to a single address of your own — the mail is really sent, but to you, with the intended recipients listed in the body — or let it send Normally. Redirect is the useful middle ground when you want to read what the agent actually wrote.
Two other settings on the same tab change how a test run executes:
Simulated current time — the "now" the agent sees. Useful for a workflow whose behavior depends on a date. Only the agent's notion of the time moves; data fetched by tools, and anything the run writes, still happen now.
Model — force one AI model for the run instead of each step's own, so you can compare behavior across models without editing every step.
Turn test mode off when you are done. It is a thunk-wide setting, and leaving it on means real work items quietly run under test policy.
For side effects a setting cannot cover — a step that files a ticket or updates a record in another system — mark the step to be skipped for test work items on its Workflow Options. See Control when a step runs and proceeds.
Watching a run as it happens
Wherever a step is running you will see the agent's activity as a single line you can expand. Click it to open the full run: the agent's reasoning, every tool it called with the arguments it passed and the result it got back, any approval it asked for, and how the run concluded.
This is the main thing to look at while testing by hand. A step that produced the wrong answer almost always shows you why in its tool calls — a search that returned nothing, a file it could not read, an argument it filled in from the wrong property.
The same view carries the run's cost and timing. See Seeing what a step did for how to read it and what the timing breakdown tells you.
Re-running a step
There are two ways to make a step run again.
From the step itself. Open the step and use the restart control. It clears the record of the agent's work on that step and starts it over. Read the confirmation before you accept it: restarting discards the prior AI activity and the data produced by this step and every step after it for that work item. That is what you want when you have just rewritten the step's instructions and want a clean attempt; it is not what you want if you only meant to look at the previous run.
Across many work items at once. From the work items view, use the rocket control in the bottom bar (Run a workflow step across … items) and choose Re-run a workflow step. Pick the step, then choose which work items to run it on — all of them, or the ones your current filter has selected. This is how you re-test an instruction change across a whole batch instead of one item at a time.
The same control offers two other things worth knowing while testing:
Start Draft items — begins the workflow on work items you have added but not yet started, so you can stage a batch of inputs and release them together.
Run an AI column — recomputes one AI-generated property across the work items, either for all of them or only those where it is still empty, without re-running the whole step. Work items still in Draft status are left alone.
Sending a test webhook
If your thunk starts work from an inbound webhook, you do not need an external system to try it. Open Inbound Requests in the left nav, select the webhook connection, and choose Test.
You can send either free text or a JSON payload, and attach files. The agent accepts messages in any format, so a realistic-looking payload and a rough one are both valid tests — sending a deliberately messy one is often the more informative test.
The message then appears in that connection's list exactly as a real inbound request would, and the workflow picks it up from there. Open the message to see what was received, and follow the work item it created to see what the agent made of it.
See Inbound Requests for how to set a webhook connection up in the first place.
Firing a schedule on demand
A step that runs on a recurring schedule is awkward to test if you have to wait for the schedule. You do not.
Open the step, go to its scheduled work configuration, and use Test at the bottom. This fires a single simulated schedule event for that step. Two options make it useful:
Simulate firing at — an assumed date and time for the fire. The agent treats that moment as "now", so you can test what a monthly step does on the first of the month, or what an escalation step does after a deadline has passed, without waiting. As with the thunk-wide simulated time, only the agent's clock moves: tools still fetch live data, and anything the run writes happens now.
Respect the filter — if the schedule only runs for work items matching a condition, you can choose whether this test honors that filter (so it will correctly skip a work item that does not match, evaluated at your simulated time) or ignores it and runs the step regardless. Testing both is worthwhile: a schedule that never fires because its filter is wrong looks identical to a schedule that is simply not due yet.
The panel above the test control also shows when the schedule last ran and when it is next due, which is usually enough to answer "why hasn't this fired?" on its own.
To fire a scheduled step across many work items, use Trigger a scheduled workflow step in the same rocket control on the work items view — it takes the same simulated firing time.
See Scheduled work on workflow steps for how schedules are configured.
When to stop testing by hand
Hands-on testing is how you find out what a workflow does. It is a poor way to find out whether it still does it after your next change — that requires running the same inputs again and comparing the results, which is exactly what the test suite is for.
A good moment to switch is when you find yourself pushing the same input through for the third time. Turn that input into a test work item with assertions and let the suite check it from then on. See Evals / Automated Tests and Building a test plan.