အေးဂျင့်ကို ဘယ်တော့မှ မတွေ့ရလိုသော အခြေအနေများဖြင့် စမ်းသပ်ပါ

A successful demonstration usually follows a cooperative path: the input is clear, the source is available and the expected answer is familiar. A useful release review needs to ask what happens when those conditions change. The difficult examples often reveal more about a workflow than another polished run through the happy path.

Start with the task the agent is meant to support. Define a useful result, the information it is allowed to rely on and the actions that remain outside its responsibility.

Build a small, varied reference set

Include a straightforward example, but do not stop there. Add a missing field, a contradictory source, an irrelevant attachment and a request that should be declined or sent for review. For a catalogue assistant, include two similar products whose distinguishing attribute is absent from one record.

Write down what should happen before running the examples. Sometimes the expected result is a complete draft. Sometimes it is a question, an explicit uncertainty or no proposed action. Treating every pause as a failure would reward the wrong behaviour.

Review the evidence behind the answer

Inspect whether the output distinguishes source facts from suggestions. A fluent description can conceal an unsupported claim, while a shorter result with a clear gap may be more useful to the reviewer.

Keep the original input and the resulting proposal together in the evaluation record. That makes it possible to explain a mistake and compare a later revision without relying on memory. Avoid judging only the wording when the actual risk lies in the selected record, recipient or destination.

Test the boundary of the available tools

An agent should not need broad write access to complete a reading or drafting task. OWASP's excessive agency guidance identifies unnecessary functionality, permissions and autonomy as causes of harmful actions. Use that distinction when reviewing which operations a proposed workflow can actually perform. OWASP's excessive agency guidance

In a controlled test, check that a request outside the task's boundary does not quietly become a new capability. A drafting workflow asked to publish immediately should follow the designed review path, rather than interpreting urgency as authority.

Include interruptions and repeated attempts

Test a source that becomes unavailable and an action whose result cannot be confirmed. The interface should distinguish “not started”, “waiting”, “failed” and “completed” in language the operator can use.

Pay particular attention to retries. A person needs to understand whether trying again will repeat a read, prepare another draft or risk applying the same change twice. The recovery path deserves the same review as the initial action.