You try an AI workflow once. The input is clear, the output looks useful, and you decide it is ready.

Before you connect it to real customer work, try a less convenient request.

Test the workflow with complete, missing, and conflicting information. The useful question is not just “Can it write a good answer?” Ask whether it knows when to draft, when to ask, and when to stop.

Use a task you can inspect from beginning to end: draft an inquiry reply, summarize a meeting into proposed actions, or prepare a homepage section from an approved brief.

Keep the test in draft mode with fictional details. Do not send messages, publish pages, or modify customer records while you explore how the workflow behaves. If the workflow cannot separate preparation from execution, test an isolated copy or run the steps manually.

For this issue, imagine a workflow that drafts replies to website inquiries. It receives a request and an approved service brief. A person reviews the reply before sending it.

Decide what a useful answer must do before you read the generated answer. Otherwise, a polished paragraph can persuade you to accept a result that missed the job.

For our fictional reply workflow, the basic rules might be: use only the supplied offer details; do not invent availability; identify a missing requirement that affects the response; and keep the output as an unsent draft.

Then try these cases:

Complete: draft within the supplied facts. Missing: ask for the detail that matters. Conflicting: pause and flag the disagreement.

This is a starter test worksheet, not a CORA product screenshot or proof that a workflow is reliable.

Supply a clear request and a consistent approved brief. For example: a fictional founder wants a three-page website; the brief lists the relevant service and says the team confirms scheduling after a scope review.

Expected behavior: the draft acknowledges the request, describes the relevant service accurately, and asks for the next agreed detail. It does not promise a start date that the brief never supplied.

Check the facts, the next step, and the draft’s status. A friendly tone does not compensate for an unsupported commitment.

Remove information that changes what the workflow should say. Perhaps the request asks, “Can you migrate it?” without identifying the current site platform or what needs to move.

Expected behavior: the workflow asks a focused question instead of claiming it can migrate everything. It can still acknowledge the request; it should not fill a consequential blank with a confident guess.

Not every missing detail should block a draft. Define which gaps matter for this job. A missing preferred greeting is different from a missing scope requirement.

Give the workflow a request that conflicts with the approved brief. For example, the request asks it to confirm ongoing support is included, while the supplied offer explicitly excludes ongoing support.

Expected behavior: it identifies the disagreement and leaves the commitment for a person to resolve. It should not quietly change the offer or tell the customer that support is included.

Record where the conflict came from and what clarification the reviewer needs. Keep internal review notes separate from any customer-facing draft.

For each case, save the sample input, the expected behavior, the actual output, the workflow version, and your decision: pass, fail, or unresolved. Use concrete reasons such as “invented a delivery date,” not just “felt wrong.”

If you change the prompt, source brief, tool settings, or workflow steps, run the same cases again. Add a new case when you encounter a different failure. Keep the original expectation unless you deliberately change the task and document why.

Repeat cases where the output varies. Passing three examples does not establish an error rate, cover every failure, or remove the need for human review. Treat the set as a starting point for finding obvious problems—not a certification.

You can explore CORA’s website-and-workspace positioning here. The inquiry-reply workflow above is illustrative. This issue does not announce a shipped CORA testing suite, automatic conflict detector, or customer-facing sending capability.

We have not established a measured reliability improvement from these checks in CORA. The practical promise is smaller: you will have an inspectable record of how your chosen workflow handled the cases you actually tried.

Today’s move: choose one unsent, unpublished workflow. Write one complete input, remove one important detail for the second case, and introduce one clear conflict for the third. Define the expected behavior before running them.

Reply with the behavior you would want your workflow to stop and ask about—use fictional details, not private customer information.

— Dravya Bansal
Do it on CORA