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

# Validate an agent before release

> Test an agent against ordinary, edge and failure cases, pilot it in shadow and then assisted mode, and decide whether it's ready to release.

An agent is ready when the evidence says so, not when the build is finished. Validation tests it against the work it will meet, pilots it on real work with a person in control, and ends in a release decision that someone accountable makes.

## Set the bar before you test

Write these into the agent specification before the first test runs, so the results are judged against a bar nobody moved:

* **The evaluation threshold** the agent has to meet.
* **Autonomy for each action**: what it may do on its own, what it drafts for a person, and what it never does.
* **Red lines**: actions it must refuse.

## What to test

| Case | What it checks |
| - | - |
| **Ordinary cases** | Real, resolved cases from the process. Their history becomes the evaluation set. |
| **Edge cases** | The exceptions and variations your Work Brain shows actually happen. |
| **Missing, late or changed inputs** | What the agent does when an input doesn't arrive, arrives late, or arrives in a different form. |
| **Malformed inputs** | Inputs it can't parse or that contradict each other. |
| **Requests it should refuse** | Anything past its red lines or its authority. |

Run the tests against approved test data and keep the evidence for every result.

## Pilot: shadow, then assisted

**1. Shadow**

The agent runs on real work alongside the people doing it. Its output is compared, not acted on.

**2. Assisted**

The agent prepares the work and a person approves it before anything happens. Anything customer-facing stays draft-with-approval.

Measure the pilot on a scoped version of your target metric, and agree in advance what would make you pause it.

## The release decision

Release when quality, controls, acceptance and operation all pass. Each role has its part:

| Role | Before release |
| - | - |
| **AI Builder & Deployer** | Proves the evaluations and rehearses recovery |
| **Functional Champion** | Secures the procedure, the practice and readiness for rollout |
| **Executive Sponsor** | Makes sure the accountable approvers decide |
| **Process Performers** | Show they can do the task, and handle the exceptions, on their own |
| **Within** | Reviews the evidence and coordinates any fixes |

If anything fails, hold the release, fix what's blocking it and run the acceptance tests again.

## Skills built by business users

Skills follow a lighter version of the same discipline:

* The builder approves the outline before the package is written.
* The package is tested with ordinary cases, missing inputs, conflicting evidence and requests it should refuse, and the builder reviews that evidence before installing it.
* A small review group decides what's safe to share and names an owner.
* Every shared skill records its owner, version and evaluation set.

## Where to go next

> **[Run in production and adopt](/user-docs/deliver/run-in-production)**
>
> What has to be true once it's live.

> **[Build an agent with the Within ADK](/user-docs/deliver/build-an-agent-with-the-adk)**
>
> The full sequence from objective to deployment.

> [!NOTE]
>
> **Need help?** Use the in-app chat — click the chat bubble in the bottom-right corner of Within (staffed 24×5) — or email [support@within.ai](mailto:support@within.ai).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.