> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.shieldtp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Test, run, and review a Custom Agent

> Use dry runs, inspect outputs and judges, recover failures, and activate only after review.

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

<Steps>
  <Step title="Choose a representative target">
    Include a normal case first, then a sparse-data case and an exception.
  </Step>

  <Step title="Add run-specific context">
    Explain any temporary constraint without rewriting the agent's durable instructions.
  </Step>

  <Step title="Enable Dry run">
    Dry run skips write actions. Some roles may be restricted to dry runs.
  </Step>

  <Step title="Choose notifications">
    Add the people who should know the run finished or needs review, if notifications are configured.
  </Step>

  <Step title="Start the run">
    Follow it from Agent Runs.
  </Step>
</Steps>

## 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.

<Warning>
  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.
</Warning>