How should complaint handling be represented as an executable process?

Treat the complaint as a process with explicit transitions, rather than a document whose status field can be edited freely. A generated environment can expose actions such as acknowledge_case, request_evidence, refer_for_review and close_case. Each action should describe the business conditions under which it is valid.

A case record might contain case_id, current_state, accountable_role_id, investigation_status and closure_basis. The transition definition can specify required evidence and permitted roles. Closing a case could require a recorded decision and completion of the associated remedy action under the supplied policy.

This distinction matters because a successful database write is not necessarily a valid business action. An unrestricted update_case tool could accept a closed status even when the investigation remains unresolved. An executable model can reject that transition and explain which precondition is missing.

Keep tool results and process results separately inspectable. The tool may execute correctly while the requested transition is inappropriate. Evaluation hooks can capture the attempted action, the evaluated preconditions and the resulting state. That gives developers a way to diagnose whether the agent misunderstood the process or the integration failed to enforce it.