Engineering
Which AI workflow should you automate first?
Start with a repetitive workflow whose output you can check, whose mistakes you can contain, and whose current cost you can measure. Not the workflow that gives the most impressive demo.
My order is extraction and classification first, evidence-backed drafting second, bounded internal actions third, and open-ended autonomous work last. A business with different risks should change that order. Buying a tool and then hunting for a use reverses the decision.
1. Extraction and classification
Turning incoming documents into reviewable fields, or sorting requests into defined categories, gives you a clear comparison with the existing process. You can inspect the source, inspect the result, and decide whether it meets the rules.
Extraction cons:
- A valid-looking field can still be wrong. A schema checks structure, not whether the value is supported by the document
- A system that creates a large review backlog is not automatically better than manual entry
Best for: repeat volume, stable categories, and an owner who can adjudicate disagreements. Preserve source evidence and allow an explicit unknown result.
2. Drafts with evidence attached
Internal summaries, proposed replies, and first drafts are useful because a person can review them before anything leaves the company. A draft reply is not a sent reply. A proposed account update is not permission to change the account.
Drafting cons:
- Review becomes harder than writing from scratch if the draft mixes grounded facts with confident invention
Best for: work where gathering information takes time and the final judgment stays with an accountable person. Require links to the underlying evidence.
3. Bounded internal actions
Once the information step works, a narrow action may be worth automating: placing a reviewed item in a queue, creating an internal draft record, or updating an allowed field after validation. Limit the records and fields available to the automation.
Action cons:
- A retry can repeat an action. You need a way to tell a failed response from a failed operation
Best for: narrow workflows with explicit authorization and straightforward reconciliation. Separate what the tool can do, what it is allowed to touch, and how much it may decide on its own.
Leave open-ended autonomy for later
An agent that searches, decides, contacts people, and changes several systems crosses several permission and reliability boundaries in one run. Split that into stages. Verify the research, then the recommendation, then the action. If a deterministic rule solves one stage, keep the rule.
For each candidate, write down volume, current handling time, review burden, consequence of error, reversibility, and integration effort. The first workflow should survive a small real pilot with the same review standards as the existing process.
If you are choosing between workflow ideas, tell me the current process and the failure you most need to avoid.
Message me