Describe one complete run
Start with a task you can already explain, such as collecting new product references or turning meeting notes into a draft. Write the input, the steps and the expected output. “Help with research” is too broad to inspect; “return an exact model, its source and the unanswered questions” gives you a result to check.
If you cannot describe what a good output contains, clarify the task before choosing an agent. Automating an unclear assignment makes the uncertainty harder to see.
Mark rules, judgment and consequences
Separate the steps with explicit rules from the steps that require interpretation. A fixed calculation or duplicate identifier check can be deterministic. Explaining a tradeoff requires reasons you can inspect. Publishing or sending the result changes something outside the draft.
For a research workflow, that may mean automated collection, code checking required fields, a reviewed explanation, and a separate release decision. The boundaries matter more than how impressive a single autonomous run looks.
Run it where failure is easy to contain
Begin with a small, non-sensitive sample and a draft-only output. Keep the manual method available. Give the task only the access needed for that stage; collecting evidence does not require permission to publish it.
Write a stop condition before the trial. Missing sources, a disputed identity or an unexpected external action should stop the workflow or reach the person responsible. External text is material to inspect, not an instruction that grants the agent more authority.
Review the exceptions and the result
Check whether the output meets the condition you wrote at the start. Record where a person had to reconstruct missing information or correct a repeated mistake. Those are parts of the process still needing work.
Keep routine notifications quiet and surface the exceptions that require a decision. Adopt the automation only when its output, boundaries and recovery path are clear enough to own.
Automation boundary sheet
| Part of the workflow | What to define |
|---|---|
| Input and output | A bounded task and an inspectable result |
| Explicit rules | Checks that should be applied consistently |
| Judgment | Reasons a reviewer needs to see |
| External action | Who authorizes sending, publishing or changing state |
| Failure | Stop condition, owner and manual fallback |