AI Actions Inside Workflows

An AI action is a single step inside a workflow that sends some context to a language model, gets an answer back, and makes that answer available to every later step. It is not a conversation. Nobody is talking to it. It runs once, produces a value, and the workflow carries on.

The point of it is judgment in the middle of automation. Classic automation can only branch on things it can compare: a tag exists, a field equals a value, a date has passed. An AI action lets a workflow branch on things that need reading: what this inquiry is actually about, whether this reply is a yes, which of five services the free-text field describes, how urgent a message sounds. The output lands in a variable you then test with ordinary conditions.

The right mental model is a very fast contractor who does one small reading task and hands back a note. You give them the material, you tell them exactly what shape the answer should take, and you decide in advance what you will do with each possible answer. Everything that makes this reliable comes from constraining the output: ask for one label from a closed list, not an opinion. Operators who treat it as an open-ended assistant get prose they cannot branch on; operators who treat it as a classifier with a fixed vocabulary get automation that holds up.

The task

• The instruction, written as a single job with a stated output format
• The context you pass in: inbound message text, a form or survey response, custom field values, conversation history, call transcript or summary
• Whether the step returns a short label, a longer piece of text, or several named values at once

Output shape

• A closed list of allowed answers for classification tasks, including a fallback option such as unclear
• Length limits for summaries and drafts
• Where the result is stored: a workflow variable for use later in the same run, or written to a custom field for use anywhere

Common step types

• Classify: pick one label from a list: intent, service line, urgency, language, lead quality
• Extract: pull structured values out of free text: a city, a date, a budget range, a referral source
• Summarize: compress a long thread or transcript into a few lines for a human to read
• Draft: produce reply text for a human to approve, or for a later send step

Control around the step

• Conditions before the step so it only runs where it is needed
• Branches after it that read the output value
• Fallback path for empty, unexpected or failed output
• Whether the result is logged to a note on the contact for auditability

1. Write down the decision the workflow needs to make and the exact list of outcomes. If you cannot list the outcomes, you are not ready to add an AI step.
2. Confirm plain conditions genuinely cannot do the job. A form with a dropdown does not need an AI classifier; a form with a free-text box does.
3. Gather real examples of the input, at least a dozen, including the messy ones. These are your test cases.
4. Add the AI action to the workflow at the point where the information exists. Placing it before the data arrives is the most common structural mistake.
5. Pass in only the context the task needs. More context is not better; irrelevant history makes classification less consistent.
6. Write the instruction as one job plus one output rule, for example: choose exactly one of these five labels, and if none fits, return unclear.
7. Include the fallback label in the list. Without it the step will force a guess into one of your real categories.
8. Store the result in a variable, and also write it to a custom field if later workflows or smart lists need it.
9. Add the branches that read the output. Give every allowed label a branch, and give the fallback a human step, not a silent end.
10. Add the error path for a failed or empty response so the contact does not fall out of the flow unnoticed.
11. Test with your real examples one at a time, reading the workflow execution log to see the exact output for each.
12. Tighten the instruction where labels came out wrong, then re-run the same set so you can tell whether you improved it or just changed it.
13. Decide whether drafted text sends automatically or waits for approval. For a first build, route drafts to a human.
14. Go live on a narrow segment, review the execution logs for the first batch, then widen.

AI actions live inside the Workflow builder, read from Contacts and Conversations, and usually write to custom fields, pipeline stages or tasks. They are the connective tissue between unstructured input and structured automation.

Routing free-text inquiries

A contact form has a single how can we help box. An AI step classifies the text into one of the client's service lines, writes the label to a field, and the workflow assigns the lead to the right team, applies the matching tag and starts the correct nurture sequence. Before this step, every inquiry went to one inbox and was sorted by hand.

Interpreting campaign replies

A reactivation SMS goes out. Replies hit a workflow that classifies each one as interested, not now, wrong person or opt-out. Opt-outs are honoured immediately, the interested go to a rep's task list, and the rest return to nurture with a future date. One AI step replaces a person triaging hundreds of one-line replies.

Call and thread summaries for handover

When a voice call or a long chat ends, an AI step summarizes the transcript into a few lines and writes it to a note on the contact, with the summary also pasted into the task assigned to the rep. The rep opens one task and knows the history without reading the transcript.

• Open-ended output breaks branching. If the step can return anything, your conditions will miss. Always constrain to a closed list for anything a branch reads.
• No fallback label means invented certainty. Forced to choose, the step will put ambiguous input into a confident wrong category. Include unclear and route it to a human.
• It is not deterministic. The same input can occasionally produce a different label. Do not use an AI step for anything that must be exactly reproducible, such as financial or clinical determinations.
• Garbage in, confident garbage out. Passing an empty field or a one-word message still produces an answer. Gate the step with a condition that the input actually exists.
• Latency and volume. Each AI step adds time to the run and consumes metered usage. Running one on every contact in a large list is slow and costly; condition it tightly.
• Auto-sending drafted text is the riskiest default. A drafted reply that goes out unreviewed is your client's voice saying something you have not read. Start with approval.
• Do not stack several AI steps in a row. Each one adds variance, and debugging a chain of three is painful. Collapse them into one step returning several named values where possible.
• Silent failures. If the step errors and there is no error branch, the contact simply stops progressing, and nothing surfaces it. Add the branch.
• Sensitive data. Be deliberate about what you pass in. Health, financial and identity details in the context of an AI step is a decision to make with the client, not a default.
• Prompt drift across clients. Cloned workflows carry the original client's categories. Re-read every AI step after duplicating a build.