> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/overview/test-and-improve-the-agent.md).

# Test Agent behaviour

Validate Agent work on representative cases, review real user feedback and improve the layer that caused the problem.

An Agent is ready for real work when it behaves dependably on representative cases, uses the right systems and evidence, and surfaces uncertainty at the right time.

Use multiple representative cases before treating Agent behaviour as ready for production.

## Representative test cases

Choose cases that cover:

* the normal path;
* the important exception boundaries;
* missing or conflicting information;
* the actions that carry the most consequence;
* the outputs operators actually need.

Define what “correct” means before you run the case.

That can include a system change, a generated file, a recommendation, a deliberate decision to ask a person, or a verified no-action result.

## Execution evidence

Ask more than “did the answer sound right?”

Check:

* Did the intended Skill run?
* Did the Agent query the right source?
* Did it use a weak source when a stronger one was available?
* Did it create the expected file or system change?
* Did it stop at the right human boundary?
* Did the business post-condition actually happen?

Use the session's visible activity and outputs, then use Monitoring when you need deeper execution evidence.

Verify results in the system that owns them. In the synthetic example below, a draft Workflow was run with a known order number and returned that exact value.

![A draft Workflow run returning the synthetic order number used for the acceptance check.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2F2gUPnJDJpeSihezI67Mj%2Fagent-test-run-result.png?alt=media)

## Skill tests

When the behaviour is encoded in a Skill, eligible Project builders can use the Skill's **Tests** surface.

Build a small regression set from representative work. When a change fixes one case, rerun the previously-good cases that could have been affected.

Do not treat an inconclusive or errored test run as proof that the Skill itself is wrong. Establish what actually happened, then correct the relevant layer.

You can also ask the Agent to summarise test evidence in the format you need for review. The example below is an Agent-formatted summary, not the default Tests UI.

![An Agent-formatted test summary comparing the example, expected result and actual result.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fftc0oSXGNiVH46KqJn3U%2Fagent-test-results.png?alt=media)

## Production feedback

Project members can leave persistent Agent-session feedback. Builders can review that feedback alongside the session in Activity.

Use feedback together with:

* the transcript;
* tool and source activity;
* produced files;
* the Skill/version evidence available for the run;
* the actual business outcome.

Feedback and technical status are different signals. A technically successful run can still deserve negative outcome feedback.

When feedback exposes a recurring failure mode, reproduce it as a representative test before publishing the fix where practical.

## Correct the responsible layer

A failure can come from different parts of the setup:

* wrong general behaviour → Project description;
* wrong recurring method → Skill;
* missing or stale structured context → Table or source data;
* weak maintained reference → Knowledge;
* wrong persistent context → Memory;
* unavailable or over-broad system authority → Connection;
* stable sequence needs tighter control → Workflow;
* genuinely human decision → preserve the human boundary.

Avoid fixing every failure by adding another general instruction.

## Publish changes

Corrections and feedback are evidence for a change, not permission for silent self-modification.

A dependable loop is:

**observe → reproduce → change the owning layer → test → review → publish → watch real use**

That is how the Agent gets better without turning production behaviour into an undocumented collection of one-off fixes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.lleverage.ai/build-and-improve/overview/test-and-improve-the-agent.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.