What integration contract should be agreed before a simulated complaint pilot starts?

Begin with the interface the agent already expects. Map its operations to the proposed environment: get_case, search_evidence, add_finding and submit_referral may have different names, but their business effects need an explicit contract. Specify required arguments, response shapes and structured error codes.

Agree how identity and role permissions enter each call. A role identifier in the prompt is not sufficient if the tool layer accepts every action. The adapter should establish which operations are allowed for the current run and return a distinguishable permission error when an action falls outside that scope.

Define test boundaries for outbound effects. Customer messages and operational updates can terminate inside generated environment state, where reviewers can inspect them. Document whether any buyer-owned system is involved and what state the pilot is authorised to change.

Finally, agree how a run starts, ends and resets. A pilot contract can identify the initial fixture, terminal conditions, trace export format and cleanup behaviour. Run a small contract check before the substantive tasks: load a case, perform a permitted action, inspect its recorded effect and reset. This establishes that the harness and environment interpret the same operation consistently.