Build and Debug the First Draft

Use Live Test to inspect the first behavior quickly. Then keep the situations that matter as reusable cases in Test Suite.

Live Test helps you explore. Test Suite helps you compare a version against judgment you want to preserve.

Step 1: Run the real situation in `Live Test`

Open the workspace.
Select AI agents.
Open the Agent.
Use the Live Test panel in Agent Editor.
Enter the real situation from your job brief.

Read the result as work, not only as prose:

Did the Agent understand what the user was trying to accomplish?
Did it ask for information it actually needed?
Did it produce a useful next step or result?
Did it avoid unsupported facts, promises, or actions?
Did it hand off when expert judgment was still required?

Continue one scenario or start a clean test

Live Test saves sent conversations. Use the history selector to reopen an earlier test, or choose Start new test when the next variation must not inherit previous messages.

Continue the same history for a multi-turn scenario where earlier answers matter.
Start a new test for independent variations, model comparisons, or regression checks.
Rename histories so another reviewer can recognize the scenario.
Delete a history only when it is no longer evidence you need. The creator or a member with workspace resource-management permission can rename or delete it.

Test voice input when the workflow needs it

When the current Agent model supports audio input, use Record voice message to speak a test request. Allow microphone access, stop the recording, review the attached audio, and send it as you would another message.

If recording is unavailable, check the selected model and browser support. Voice recording tests what the Agent can understand; Text to Speech is a separate tool for turning the Agent's answer into audio.

Step 2: Try nearby boundaries

Add a few variations that are close enough to expose the design:

Important information is missing.
The request is outside the first scope.
A confident answer would create risk.
A tool or source is unavailable.
A person should take over.

The behavior to observe depends on the job:

Work pattern	Core behavior	Useful boundary check
Answer and handle	Gives the approved answer or completes the supported next step	Avoids an unapproved exception and offers the correct handoff
Guide and judge	Asks the right questions and gives a practical next step	Does not overstate certainty when the situation needs expert review
Review and deliver	Applies the stated quality criteria to the submitted work	Identifies missing evidence instead of inventing it

At this stage, you are exposing the first design. You are not proving that the Agent can handle every variation.

Step 3: Save must-pass situations in `Test Suite`

Create reusable cases for behavior that must remain correct.

Each case requires:

Input: The user message or task to run
Standard: Checkable requirements for the AI response

Optional fields include:

Note: Context for reviewers
Ideal Response: A useful example when wording or structure matters

A clear Standard is usually more important than a perfect sample response. It should tell another reviewer what the response must do, must avoid, and when it must hand off.

How many cases do you need?

Use the amount of evidence required for the next decision:

Decision	Evidence to prepare
Is the first behavior worth continuing?	The real situation plus a few nearby boundaries
Is a controlled pilot ready?	Must-pass cases selected by frequency, consequence, tool use, and handoff risk
Can the next version be published?	Affected cases plus broader regression cases when the change may alter existing behavior

There is no universal case count. A high-consequence workflow may need more boundary coverage than a broader but low-risk internal helper.

Step 4: Run the cases and read failures

Run the cases with the appropriate evaluator. When using Content Compliance, read the result as pass or fail against the Standard.

Review failures before editing the Agent:

If the answer is acceptable, the Standard may be unclear or incorrect.
If the Standard conflicts with a source, decide which one is authoritative.
If required facts are missing, add or clean the relevant Knowledge Base content.
If the Agent had the facts but made the wrong decision, tighten the relevant instruction.
If an action failed, inspect the tool configuration and its invocation boundary.
If the situation is outside the first scope, keep the safe fallback instead of forcing a broad answer.

Make failures useful

A failed case is evidence about the current design. Diagnose whether the problem is the expected behavior, instructions, knowledge, tool, or scope before changing anything.

Step 5: Make the smallest relevant fix

Ask Copilot from beside the failed result, or inspect the case and Agent directly.

This case failed. Diagnose whether the issue is the Standard, source material, tool behavior, or Agent instruction. Suggest the smallest change that improves this pattern without overfitting to one case.

Apply the focused change, rerun the failed case, and rerun broader cases when the change could affect behavior that already passed.

Decide whether a controlled pilot can proceed

Before treating successful cases as permission to launch, make the release decision explicit. A controlled pilot is ready only when:

The first job and its excluded scope are written down.
Each common situation and each high-consequence boundary has a named case with a checkable Standard.
Required tools, sources, and handoffs have passed in the situations where they matter.
Known failures or untested situations have a safe fallback, or remain outside the pilot.
A named release approver accepts the remaining risk, and a named operator owns live handoffs and incidents.

If any item is unresolved, keep the Agent in draft or narrow the pilot. The gate is a team decision supported by test evidence; a green result by itself does not define acceptable risk. See Publish Only the Verified Scope for the release workflow.