What to test in a tool-using AI application

A tool-using AI application has at least four systems to test: model behavior, deterministic policy, connector behavior and the resulting business side effect. A successful chat response proves very little about the complete path.

The test strategy should combine pure logic tests, contract tests, production-shaped integration tests and a small number of controlled end-to-end evaluations. Each layer owns a different failure class.

Build the test matrix around consequences

Classify every tool operation as read-only, reversible write, external communication, destructive action or decision affecting people. The consequence determines the required evidence and release gate.

Begin with the highest-consequence operations. A read-only summary needs accuracy and data-boundary tests. An external message adds recipient, approval, duplicate and recovery tests.

Keep deterministic logic out of expensive evaluations

Path validation, permission matrices, account resolution, quota math, state transitions and text normalization can be ordinary unit tests. These tests should run on every change and need no model or network.

Skybridge extracts high-risk decisions into small functions where possible. The continuous-integration suite checks security and routing contracts, while the application build verifies that the tested code still composes.

This leaves model evaluations for behavior that genuinely depends on language or uncertain reasoning. Spending model calls to test a URL allowlist is slower and less reliable than asserting the function directly.

Test tool selection with controlled fixtures

Create a set of requests with expected allowed tool sets. Do not require one exact call sequence unless the sequence is part of the contract. Two paths can be valid if they produce the same permitted result.

Include ambiguous prompts, missing data, conflicting instructions and irrelevant connected tools. Add retrieved documents containing instructions addressed to the model. The expected behavior should state whether the system asks, refuses, reads more context or prepares an approval.

Score the decision and the final result separately. A correct answer obtained through an unauthorized tool is a failed test.

Test permissions at every action edge

Use real application identities in development. Verify workspace membership, role profile, connection access and action authority at request time. Try direct API calls that bypass the visible interface.

Test read and write disagreement deliberately. An unnamed read may inspect several approved accounts and label results. An unnamed write should refuse to guess. Test a user whose permission is revoked after an approval request was created.

The policy test should inspect the connector call that would leave the system, not only the model's text.

Test approvals as concurrent processes

Create, approve, reject, revise and expire proposals. Open one request in two sessions and produce conflicting decisions. Confirm that only one legal transition succeeds.

For revision, verify that the old payload can no longer execute and the replacement requires a new decision. Approve a proposal whose connector later fails, then check that the evidence preserves both the approval and the failed execution.

Use a mail scanner simulation that fetches the approval page. A page read must never perform the decision.

Test connector failure and uncertain outcomes

Mock clean errors, timeouts, rate limits, malformed responses and partial batches. Then run against a development account with production-shaped pagination and payload sizes.

The hardest case is a timeout after the remote system accepted the write. Retrying immediately may duplicate the side effect. Test idempotency keys, remote-object lookup or a reconciliation queue before automatic replay.

Connector contracts should include response shaping. A tool that returns an entire mailbox or document collection can exceed model context and expose unnecessary data even when the API call succeeds.

Make development unable to harm production

End-to-end tests need real orchestration, but they should not gain production authority. Use isolated data, development credentials, blocked connector writes and redirected notifications.

Skybridge's development pattern enforces the write block at egress so chat, automation and approval paths receive the same protection. Tests can assert the typed simulated result and the recorded blocked attempt.

Add browser and release tests for the operator path

API tests miss unreadable approval screens, broken run histories and visual state confusion. Use browser automation for stable operator flows: sign in, create a test action, review it, inspect the result and locate its evidence.

Skybridge keeps a Playwright harness pointed at development and can attach test specifications to changes. Human review remains useful for exploratory behavior and new interaction patterns; repeatable acceptance moves into code once understood.

Release against a written acceptance record

For each production system, record the tested version, environment, data shapes, tools, roles, expected failures, rollback and residual limits. A green general test suite does not prove one customer's exact integration path.

NIST's AI Risk Management Framework calls for documented testing, evaluation, verification and validation under conditions similar to deployment. The NIST AI RMF Core provides a useful public reference for that discipline.

Testing is complete when the business action, enforcement and recovery path have evidence. Pair this matrix with the production-incapable development environment and the agent tool authority model.