Section 1
Trigger model: polling or webhook
This determines both latency and cost, and it is often buried in the documentation. A polling trigger checks a source on an interval. Simple, universally supported, and it means your automation has an inherent delay equal to the polling window. On task-based pricing, polling can also consume quota while doing nothing useful. A webhook trigger fires when the event happens. Faster and cheaper at volume, but it requires the source system to support outbound events and it requires you to handle duplicates, because webhooks are frequently delivered more than once. If your use case is customer-facing, latency is a product decision and polling intervals are the constraint. If it is internal batch work, polling is usually fine and cheaper to reason about.
Section 2
Pricing units decide the winner more often than features
Platforms in this category meter differently, and the difference is not cosmetic. Some charge per task, where a task is roughly one action. Some charge per run of an entire workflow regardless of the number of steps. Some charge per step. Some self-hosted options charge nothing per execution and charge you in infrastructure and attention instead. The consequence: a workflow with many small steps is expensive on per-step pricing and cheap on per-run pricing. A workflow triggered constantly is expensive on per-run pricing. Model your actual volume against each pricing scheme before you choose, using the busiest month you expect rather than the average. This one calculation reorders most shortlists.
Section 3
Error handling is the real product
Everything runs when the inputs are clean. Compare platforms on what happens when they are not. Ask: does a failed step retry automatically, and with what backoff? Can you branch on failure, or does the run simply stop? If step four fails after steps one to three wrote data, is there any way to roll back or must you write compensating logic yourself? Are failures visible without opening each run? Related: idempotency. If a trigger fires twice, does your workflow create two records? Most platforms will not solve this for you. Whether they give you the tools to solve it, such as deduplication keys or lookups before writes, varies widely.
Section 4
State, versioning, and the team problem
Single-step automations are easy on every platform. Difficulty arrives with state and with more than one person editing. State: can a workflow wait for an approval, resume days later, and remember its context? Long-running human-in-the-loop processes are common in real businesses and poorly supported in several popular tools. Versioning: can you see what changed, who changed it, and roll back? A workflow edited live in production by whoever last had a problem is a genuine operational risk, and some platforms have no history at all. Environments: is there a way to test without touching production data? If not, your test runs are real emails to real customers, and eventually one goes out. Permissions: can you restrict who edits the automation that touches billing?
Section 5
Data, hosting, and the exit
NIST frames AI risk management around trustworthiness, design, evaluation, and use, which in platform selection translates into a short set of due diligence questions. Where does execution happen, and can you pin the region? What is retained in run logs, given that logs on an AI workflow contain the prompts and therefore the personal data? How are credentials stored, and can a workflow editor read them? Does the vendor or its model provider train on what passes through? Then the exit. Export your workflow definitions and look at what you get. If it is a proprietary blob that only imports back into the same product, the switching cost is your entire automation estate. Self-hosted options score well here and cost you in upkeep. There is no free position, only a chosen one.
Section 6
Choosing, and knowing when you chose wrong
Score candidates on: latency required, expected monthly volume against each pricing model, error handling depth, versioning, environment separation, data residency, and exit format. Weight them by which failure would hurt most in your business rather than by which feature demos best. Then watch for the signals that you have outgrown the choice. Costs rising faster than volume. Workflows that have become too large to reason about. Repeated incidents caused by an edit nobody can trace. More than a few hours a month spent debugging runs. Any of those means the platform is now the constraint. The communication side is in [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation). A wider view of the category is in [Exploring the AI Automation Landscape: Tools and Platforms](/blog/exploring-the-ai-automation-landscape-tools-and-platforms), and the startup shortlist in [Top AI Automation Tools for Startups in 2026](/blog/top-ai-automation-tools-for-startups-in-2026).