Keeping AI tool use inside a defined workflow

A model can interpret a request or propose an action. The application still needs to decide whether that action is permitted, whether its inputs are valid and how to recover if execution fails. Those checks belong in executable application rules.

Define the permitted steps

Describe the workflow as states with named transitions. For each state, specify the available tools, required inputs and completion conditions. A document process might move from received to extracted, validated, approved and exported. An invalid transition should be rejected before a tool runs.

Validate meaning as well as shape

A schema can check that an amount is numeric. It cannot establish that the amount is correct or that the caller may spend it. Check business rules and permissions independently. Treat retrieved text and tool responses as data rather than authority to change those rules.

Design for interrupted execution

Bound retries, execution time and the number of tool calls. Where supported, use idempotency keys to avoid duplicate writes. Record whether an action was proposed, approved, started or completed so recovery does not depend on the model remembering what happened.

Place approval at the action boundary

For consequential changes, show the reviewer the exact operation, destination and values. Bind approval to that proposed action and invalidate it if material inputs change. A generic approval earlier in the conversation should not silently authorize a different operation.

Test failure paths

Exercise malformed outputs, stale permissions, timeouts and partial successes. Verify that rejected actions do not reach the tool and that logs support reconstruction of the sequence. State machines make permitted behavior explicit, but they do not guarantee correct inputs or eliminate every failure.

This engineering note describes an approach, not a new experimental result. Performance claims require a documented test setup and reproducible measurements.