Put a typed tool between the model and the system

I'd have the model call small, typed operations instead of building its own network requests, database statements or shell commands. The tool turns a business action into a constrained call to the source system and validates every argument before using it.

A useful tool definition covers:

• what the action does, in plain language
• required and optional fields, with tight types
• allowed values and maximum lengths
• the identity and scope checks it applies
• whether it reads, proposes or changes state
• the error classes it can return
• the evidence it returns on success

Keep each operation narrow. get_case_summary(case_id) is much easier to authorise than query_database(sql), and propose_status_change(case_id, target_status, reason) hands over less authority than update_case(payload). Narrow tools are also easier to evaluate, because the expected outcome has fewer hidden branches.

Do the validation outside the model, in ordinary code. Check identifier formats, permitted transitions, amount bounds, destination domains and current object versions there, and reject unknown properties instead of ignoring them. An agent can send an argument that looks perfectly plausible but was copied out of source material or guessed from an incomplete record.

Return structured errors. I'd separate not_found, not_authorised, ambiguous, conflict, validation_failed, dependency_unavailable and approval_required. A generic error tends to cause repeated calls, and it makes it harder to decide whether a retry makes sense.

Each tool response should include the record version or last-modified marker it used. A later proposal can then bind itself to that version, which stops an approval given against one state of the record being applied after someone else has changed it.

Debug endpoints, unrestricted file readers and raw admin clients should sit under a separate development identity. I'd add a deployment check that fails if any of them are still in the production tool registry.