AI automation starts with a clear workflow
A team copies data between several tools. Someone checks the details, adds missing context and prepares the next step. These handoffs are a useful starting point for automation. My first question is what should reliably exist at the end of the process.
Research checked: 2026-09-09 · Cover: AI-generated illustration
Start with a specific result
‚We need something with AI‘ does not yet describe a task. A checked list of suitable contacts, with sources and a prepared next step, is much more concrete. It defines inputs, processing and output. Only then does it make sense to decide where rules are enough and where a language model helps.
A workflow does not need an agent at every step. Checking a data format, detecting an existing record or changing a status are often deterministic operations. A model can help where text needs interpretation, information needs synthesis or a proposal needs drafting.
The distinction at a glance
- GoalDefine outcome and limits
- HandoffClarify data and ownership
- AcceptanceTest representative cases
The handoffs are part of the product
In my projects, integrations and interfaces belong to the same problem. An outreach tool must prepare results so the next step is clear. A content platform must turn signals into a reviewable plan. A CRM must show what has already been handled and who needs to act next.
A successful model response alone does not complete that loop. If a result is not linked to the right record, errors are buried in server logs or nobody can approve the next action, the team still has to carry the process. Status, questions and failure handling therefore belong in the initial design.
Place approvals where they protect something
Actions have different consequences. Reading information is different from sending a message or overwriting a record. Permissions should fit each operation and be checked on the server. A sentence in a prompt does not replace that check.
A useful first scope often focuses on preparation: research, organise, draft and place the sources next to the result. A person reviews the work. Whether subsequent steps may run automatically depends on observed failures and the consequences of an incorrect action.
- Which data may the system read and process?
- Which changes need approval?
- How is a failed run detected and retried?
- What happens when a source is missing or an integration changes?
Test with real examples
Tests should include typical cases, incomplete details, duplicate records and conflicting sources. A useful comparison measures the whole process: how much rework remains, whether results can be traced and whether the team knows when a person must decide.
The linked projects show different implementations of these questions. The right architecture for a new project depends on its data, permissions and working context. A concrete workflow, a few typical examples and an explanation of what currently takes time are enough to start a conversation.
