01 / BOUNDED AUTOMATIONUse deterministic workflows when they suffice
A feed event can begin a fixed process without requiring dynamic planning. Use a deterministic path where the steps are known and reserve interpretation for the portion that benefits from it. Define the allowed task from trusted configuration. The source text should not grant itself authority to create new tools, targets, or objectives.
02 / BOUNDED AUTOMATIONMake actions safe to retry deliberately
Assume an interruption can occur after an external action succeeds but before your worker records the result. Give each proposed effect a deliberate identity and recovery rule. Check whether an action already exists before retrying. Local event deduplication is only one part of the complete path to a user-visible outcome.
03 / BOUNDED AUTOMATIONDefine budgets, approvals, and stop conditions
Keep analysis, policy validation, approval, and execution as distinct stages. A reviewer should see the exact proposed effect and its target. Set limits on steps, time, and repeated attempts, and provide a readable stopped state. Expanding autonomy should solve a demonstrated problem without making the permission boundary harder to inspect.
Prepare a proposal without executing it
Start with one event type and one allowed suggestion, such as proposing an internal review task from a release note. Validate the proposal’s target and evidence, then require approval before any external effect. Test duplicate events and a restart at the execution boundary. Expand the workflow only when you can explain what it will do, what it cannot do, and how it stops.