Automation requests often begin with the output
Why a requested output is only the visible edge of the judgement, evidence, exceptions, and ownership that make automation work.
TLDR
- Requests for automation commonly arrive as an output: make the report, answer the email, update the record.
- The output hides the evidence, choices, exceptions, and ownership that produced it.
- Before automating, reconstruct the decision and define what happens when the normal path fails.
We keep seeing automation requests begin at the end of the work.
“Prepare the report.” “Answer the enquiry.” “Update the record.” “Send the reminder.” These are legitimate outcomes, but they are not yet descriptions of the work that produces them.
The visible output compresses a series of less visible decisions: which sources count, how recent they must be, which inconsistency matters, what tone is appropriate, who owns the result, and when the case should leave the normal path.
An illustrative composite makes the gap clear. A team asks to automate a weekly status report. The apparent task is to populate a template. In practice, someone also decides whether a delayed item is genuinely at risk, whether an informal promise should appear, whether two systems disagree because one is stale, and whether the update needs escalation before circulation. Producing the document is easy to specify. Producing the right account of the situation is not.
If discovery begins and ends with the output, the system inherits unstated assumptions. It may perform the happy path impressively while failing exactly where professional judgement matters.
A better starting point is to reconstruct the decision around the output:
- What event starts the work?
- Which evidence is authoritative, and how is freshness checked?
- What choices are being made, even if they feel routine?
- Which exceptions change the path?
- Who can approve, correct, or stop the result?
- Where does the final outcome become part of organisational memory?
This does not mean documenting every gesture before using AI. It means finding the minimum operating account needed to distinguish a known procedure from delegated judgement. Guidance on agent design similarly recommends using the simplest workable pattern and adding autonomy only when the task genuinely requires flexible decision-making 2. NIST’s framework asks organisations to map context and risk before managing the system 1.
The output is useful evidence of what people want. It is not a sufficient specification of how the work should happen.
See what makes AI useful in professional work.
Sources
/ Start
Start with one business outcome. Expand from there.
Begin with a focused review rhythm, workflow, or team where better operating context would immediately change the quality of preparation and judgment.