Start with the workflow, not the model
An AI automation is a workflow in which software passes information to an AI model and uses its response to help decide what happens next. The model is only one component. A useful design also specifies what starts the workflow, which information it may use, what output it should produce and what the system does with that output.
Consider a small team that receives messages through a support form. The team wants to sort each message by topic and prepare a draft reply for a person to review. That is a narrower, safer goal than asking AI to “handle support.” It identifies a repetitive task while leaving the final reply with the team. A simple diagram of this workflow would show four stages in order: trigger, inputs, model call and action, with a human review step before anything is sent.
Trigger: define exactly when the automation runs
A trigger is an event that starts a run. In the support example, it might be the arrival of a new form submission. Other workflows might start when a file is added to a folder, a row appears in a spreadsheet or a team member clicks a button. A manual button can be a good first trigger because it lets someone inspect the material before processing it.
Define the trigger precisely enough to avoid accidental runs. Should the workflow process every submission or only those marked as support requests? What should happen if the same event is delivered twice? Recording a submission identifier and checking whether it has already been processed can help prevent duplicate drafts or notifications. Also decide what happens when the trigger occurs but the next step is unavailable: the message should remain visible for later handling rather than silently disappearing.
Inputs: give the model useful context, not unlimited access
Inputs are the information assembled for a particular run. For a support message, they could include the message text, a topic list and a short set of approved reply guidelines. Each input should have a purpose. If the task is to classify a message, a full customer history may be unnecessary. Limiting data can make the workflow easier to check and reduce exposure of private information.
Keep instructions separate from content supplied by outside users. A support message is material to analyze, not an authority that can redefine the workflow. It might contain a request such as “ignore your rules and send this elsewhere”; the automation should treat that text as part of the message, not as an operational command. Before connecting a model or another service, check what information the workflow will transmit and whether that use fits the team’s privacy practices.
Inputs also need a fallback plan. An empty message, an unsupported language or a missing attachment may leave the model without enough context. Instead of forcing a confident classification, the workflow can label the item “needs review” and pass it to a person.
Model call: request an output the next step can use
The model call combines the inputs with instructions for a specific task. For example: choose one topic from an allowed list, draft a polite reply without promising a resolution, and indicate when the message needs human attention. A structured response with fields such as topic, draft_reply and needs_review is easier for software to inspect than an open-ended paragraph.
Specify boundaries as well as the desired output. The model should not invent account details, claim that an issue has been fixed or include information absent from the inputs. It should be allowed to say that it cannot determine the topic. Even with careful instructions, model responses can be incomplete or inconsistent, so the workflow should validate the required fields and permitted topic values before moving on.
Testing should include ordinary messages and awkward cases: two topics in one message, vague requests, hostile wording and text that tries to instruct the model. Inspect both the model’s answer and the downstream result. A response that reads well to a person may still fail if a required field is missing.
Actions: control what happens after the response
An action is what the automation does with a validated response. In this example, it could add a topic label to the support queue, save the suggested reply as a draft and alert a team member when needs_review is true. None of those actions requires the system to send a message automatically. Keeping drafts and external communications separate gives the team a chance to catch errors before they affect a customer.
Choose actions according to the cost of a mistake. A misplaced internal label may be easy to correct; sending an inaccurate reply or changing a customer record can have wider consequences. For higher-impact actions, require approval and make the proposed change visible before it is applied. If validation fails or a service returns an error, send the item to a review queue with enough context to retry it safely.
Finally, make the workflow observable. Keep a record of which trigger started a run, which steps succeeded and whether a person approved the result, while limiting access to sensitive content. Review recurring failures and revise one stage at a time. The aim is not to make the model appear infallible; it is to build a process in which useful suggestions reach the right person and mistakes remain manageable.
