Piwi field notes · 2 min read
How to automate repetitive tasks without creating a black box
A practical method for turning a recurring job into bounded tools, a reviewable workflow, and a measurable result.
Start with the decision, not the software
Write the outcome someone can approve: the input, expected artifact, maximum cost, allowed data recipients, and the moment a human must decide. If those constraints cannot be named, automation will only hide ambiguity.
A useful boundary is specific: ‘prepare a draft using approved facts’ is automatable; ‘decide what we should promise customers’ remains an accountable human decision.
Split the job by certainty
Put deterministic transformations—renaming, validation, conversion, checksums, schema checks—into small tools. Keep model reasoning or generation as distinct steps with clear inputs and outputs.
That split makes failure diagnosable. A wrong crop is a transform issue; an unsupported claim is a content-review issue. They should not be one opaque action.
Choose a stop condition before a start condition
Define what makes a run stop: an unapproved destination, a missing source field, a spending limit, a schema mismatch, or a failed safety check. A workflow that cannot stop safely is not ready to run unattended.
Record the tool version, policy decision, artifacts, and reviewer action. The record should make it possible to explain a result without relying on a model’s memory.
Measure the work that remains
Automation is useful when it removes repeatable effort and makes review faster, not when it erases ownership. Track time-to-review, correction rate, cost per accepted result, and the causes of stopped runs.
Use those results to improve or retire a workflow. More automation is not automatically better automation.