Separate a fixed process from an open-ended task
Consider two requests. The first is to create a task whenever a website enquiry arrives. The second is to investigate that enquiry, assess several sources, identify missing information and propose a next step. The first follows a predictable path. The second requires interpretation.
Anthropic’s architectural guidance distinguishes workflows with predefined paths from agents that dynamically choose their process and tools. It recommends starting with a simple solution and increasing complexity when justified. Read the underlying distinction.
That distinction is useful for a business owner because autonomy has a cost. An agent may need more testing, more monitoring and more careful access controls than a rule that copies a form submission into a customer relationship management system.
Use workflow automation when the rules are clear
Repeatable operations are good candidates for ordinary automation. An approved proposal can trigger an onboarding checklist. A missed internal deadline can trigger a reminder. An order status change can update a support record.
Write the rule as a complete sentence: when this event occurs, check these conditions and perform this action. If the sentence is easy to finish and the exceptions are limited, a fixed workflow may be sufficient.
The work then becomes operational design. Decide which system owns the record, how duplicate events are handled and who sees a failed action. A workflow that runs quietly but drops records is not saving time reliably.
Add AI where interpretation creates value
AI can help when information arrives in varied language or formats. It might summarise an enquiry, suggest a category or extract questions from meeting notes. These are bounded tasks that can fit inside a larger, predictable workflow.
Imagine an enquiry mentioning both a new Shopify store and difficulty handling customer requests. A model could suggest Launch and Automate as relevant categories, while preserving the original message for review. It should not invent a budget, promise a delivery date or decide the commercial scope.
This hybrid approach is often a sensible pilot: let the model interpret the text, let fixed rules handle the record and let a person approve the response. It gives the team a way to learn where AI is useful before widening its authority.
Define permissions before connecting tools
List the actions the system may take. Reading an approved document, drafting a response and changing a customer record are different levels of responsibility. Sending a message or committing advertising spend deserves a deliberate approval rule.
For each action, specify the allowed data, maximum scope and fallback. A research assistant might read a selected knowledge base and create a draft task. It should hand the request to a person if information is contradictory or the required source is unavailable.
Also decide when the system must stop. A limit on retries, tool calls or elapsed time makes an unexpected loop easier to contain. Keep an understandable record of what happened so the team can investigate mistakes.
Run a pilot that can fail safely
Select a set of realistic examples, including incomplete requests, duplicates and ambiguous language. Have the team define acceptable outputs before seeing the model’s answers. Otherwise it becomes too easy to judge success by how convincing the wording sounds.
Measure correct handling, review time, rework and cost per completed task. Compare the pilot with the existing process. A faster draft is only useful if the time saved exceeds the additional checking and correction.
My starting question would be: what is the smallest piece of judgement that slows this process down? Automate around that point, assess the results and expand only when the team can explain why the next level of autonomy is worth it.
What would this look like in your business?
Explore Automate or tell me what you would like to improve.