Test the agent against real business cases.

Approve the rule before writing the test.

Use an acceptance test to check whether the agent follows an approved business rule. A past case provides the situation to test; its outcome may not be the right answer.

Compare the policy, recorded action and expert’s explanation. Ask the process owner to resolve differences before choosing what counts as a pass.

Add these tests to your unit, security and model-quality tests. Keep those other checks in place.

Use only information available at the decision.

Do not give a Monday decision information from a complaint that arrived on Wednesday. Keep the original timestamps and records.

If historical stock, permissions or policy versions are missing, record the gap. Label any scenario you create to fill it as fictional, not a replay of the real case.

Separate recorded facts, links you have inferred and inputs you have created. Check this separation especially when the same system drafts both the rule and its tests.

Check the required action and result.

List what the agent must do, what it must not do and which alternative actions are acceptable. Allow different tool sequences when they satisfy the same rule.

Check approvals and changes in the system, as well as the customer-facing response. Keep later business results separate from the immediate result of the action.

Test the cases that change the decision.

• Complete information: Check that the agent performs the allowed action.
• A limit is reached: Check the price, amount or approval threshold.
• Information is missing: Check that the agent asks for it instead of guessing.
• Records conflict: Check that the agent identifies the conflict and requests a decision.
• Approval is missing: Check that the agent stops and asks the right person.
• A rule has changed: Check that the agent follows the version that applies to the case.

Choose cases with different decisions and consequences. Rewording the same easy case does not test a new rule.

Have someone check the expected answers.

Ask the person accountable for the business rule to review what the agent should do. Add a second reviewer when the consequences justify it. Assign disputed answers to someone who can resolve them.

Keep some cases out of development and use them only for testing. Record any result you cannot assess. Do not count an unresolved expectation as a pass.

Run tests without changing real customer records.

Use mock tools or an isolated test system for refunds, account changes and messages. State which actions the test can perform and what permissions it has.

Record the case, approved rule version, expected behavior, agent version and actual result separately. Mark a missing result as “not run.”

Use FieldSignal to prepare the case records, rules and tests. Adapt them to your chosen test tools and agree any required system connections and file formats before the pilot.

Inspect a sample test.

Read the replacement example. Check its inputs, required action, forbidden actions and expected result.

Download the fictional decision and test package. The JSON illustrates the test structure. It contains no test-run score.