A trigger (webhook) is push-based: the source calls you the instant something happens — cheap and low-latency. Polling asks "anything new?" on a schedule — simpler to build, but wastes calls and adds up to one full interval of delay. Most platforms (Zapier, n8n, ByteChef-style tools) support both and prefer webhooks when the source offers them.
A Fetch or Send step is deterministic: same input, same output, easy to test and retry. An agent step embeds an LLM that plans, calls tools, and returns fuzzy output. Best practice: constrain the agent to a schema (structured JSON out), keep it sandwiched between deterministic steps, and validate its output before anything irreversible runs.
Networks fail, so workflow engines retry failed steps (often with exponential backoff). That's only safe if steps are idempotent — running twice has the same effect as once. Techniques: idempotency keys on writes, "upsert" instead of "insert", and never retrying a payment step without a dedupe token.
Agent-as-step (this demo, and ByteChef's open-core model): the workflow owns control flow; the agent handles one fuzzy task (classify, summarize, extract). Predictable, auditable, cheap. Agent-as-orchestrator: the agent decides which workflows/tools to call — flexible for open-ended goals, but harder to test and bound. Rule of thumb: if you can draw the flow in advance, make the agent a step.