When a new AI tool makes a task possible, the temptation is to build a workflow around it immediately. Connect the inputs, add a prompt, send the output somewhere, and watch the steps run. There is satisfaction in seeing a process execute on its own. The more difficult question is whether the process should exist in that form, and whether its output helps someone make a better decision.
My work spans go-to-market operations, rapid product development, and tools such as LLM APIs, AI agents, MCP, and n8n. At Morsa, I designed outbound infrastructure across Attio, Lemlist, Clay, email, and LinkedIn. That work includes sourcing, enrichment, deduplication, sequencing, and pipeline management. It is a useful reminder that the quality of a system depends on how its parts fit together, not just how capable each tool is.
Map the work before choosing the tool
A useful starting point is to describe the process without naming any software. What information enters? Who needs it? What decision comes next? Which steps require an interpretation, and which are mostly copying, checking, or moving information? If the process is difficult to explain in plain language, adding more connections usually makes it harder to understand rather than easier to operate.
For example, an outbound process is not simply a sequence of messages. It begins with a view of which companies might benefit from the product and why. It involves finding the right people, checking the information, avoiding duplicate outreach, recording responses, and keeping the next action clear. Automating only the sending step can accelerate a process whose earlier assumptions have never been examined.
Give every output a purpose
An enrichment step should produce information that changes a decision or improves a conversation. Otherwise, it may create the appearance of research without making the work more useful. The same is true of a generated summary. A long paragraph can be impressive while hiding the one fact a person needs. The standard should be usefulness at the next step, not the quantity of text or the number of fields populated.
I find it helpful to imagine the person receiving the output. What are they trying to do at that moment? What would they have to verify before using it? What context would prevent a misunderstanding? These questions make the requirements clearer. They also reveal where a small structured record can serve the workflow better than a broad, fluent explanation.
Decide where a person stays involved
Different tasks deserve different levels of autonomy. Formatting a record and sending a message to a customer do not carry the same consequences. A system can prepare information, suggest an action, or take that action directly. Choosing among those levels is part of designing the workflow. It should be deliberate rather than a side effect of which integrations happen to be available.
For work that affects another person, I want the review point to be easy to see. The reviewer should understand what the system used, what it produced, and what remains uncertain. Human oversight becomes less meaningful when the evidence is scattered or the output is too dense to inspect. Good automation should make judgment easier to exercise, including the judgment to stop the process or choose a different approach.
Plan for ordinary failure
A useful system needs an answer for incomplete information, duplicate records, and a service that does not respond. These are ordinary operating conditions. If every exception creates a mystery, the workflow has transferred effort into troubleshooting. A small amount of clarity about status and ownership can make a large difference to the person who has to maintain it.
I would rather have a narrower process with visible failure states than a broad process whose success is difficult to verify. A clear record of what happened supports both trust and improvement. It helps a team distinguish a bad input from a bad instruction, a temporary service failure from a flawed assumption, and a completed action from something that merely looked successful.
Measure what the automation makes possible
Time saved is a useful measure, but it is not the only one. A workflow might help someone follow up more consistently, enter a meeting with better context, or spot a mismatch earlier. Those changes matter because they affect the quality of the work that follows. Counting automated steps alone can miss the benefit and reward unnecessary complexity.
The question I want to keep asking is simple: what can the person do better now? If the answer is unclear, the system may need a smaller scope or a different purpose. My interest in AI comes from its ability to remove friction between an idea and useful work. The strongest result is a process that is easier to understand, more dependable to operate, and more respectful of the judgment people bring to it.
Have a different perspective? I’d like to hear it.
Continue the conversation