Skip to main content
Testing should prove that the agent finds the right evidence, stays within its tool boundary, produces a useful output, and stops safely when inputs are incomplete.

Run a dry run

1

Choose a representative target

Include a normal case first, then a sparse-data case and an exception.
2

Add run-specific context

Explain any temporary constraint without rewriting the agent’s durable instructions.
3

Enable Dry run

Dry run skips write actions. Some roles may be restricted to dry runs.
4

Choose notifications

Add the people who should know the run finished or needs review, if notifications are configured.
5

Start the run

Follow it from Agent Runs.

Review the run

Check:
  • the actual target and configuration version;
  • connected records and files used;
  • unsupported assumptions or missing evidence;
  • output completeness and usefulness;
  • skipped or attempted actions;
  • judge results;
  • warnings, handoffs, or errors.
Do not approve an agent based on one ideal case. Run a small test set that includes absence of data, stale data, conflicting sources, provider errors, and a condition that should cause no action.

Follow up and recover

Agent Runs preserves the output and run state. Depending on the failure, you can:
  • rerun a transient failure;
  • correct a connection or account mapping;
  • revise the agent and run a new version;
  • continue in a run-scoped Chat with files attached;
  • hand the output to the human owner.

Activate and operate

Activate only after the owner accepts the dry-run behavior and administrator confirms Availability. Then monitor:
  • run completion and latency;
  • useful vs empty or noisy outputs;
  • judge trends;
  • write outcomes;
  • recurring failures by system or account;
  • whether a person still reads and acts on the result.
A successful run means the workflow completed as configured. It does not by itself prove that every source value was current or every recommendation was correct.