Workflow filters skip irrelevant events before agents run

Any code or agent workflow can now carry an optional filter.ts: a cheap, deterministic check that decides whether a run happens at all, and on what input. A busy webhook or poll trigger no longer wakes an agent for every event. A code check costs roughly a tenth of a cent; an agent run costs 40 to 250 times that before it does any work, so on a noisy trigger the filter decides most of the bill.

The same mechanism is also a custom trigger: paired with a schedule, a filter can poll any source that has no built-in trigger, skip what it has already seen, and run only on new items. The trigger picker has a new Custom option that writes the schedule and filter for you.

How it works

• Same context as the workflow. The filter runs in the sandbox with the workflow's credentials, settings, databases, and firewall rules, and returns skip with a reason, or run with an input.
• Filtered is a success. Skipped events end with a filtered status, never count toward auto-disable, and show their reason in history.
• Fails open. An error, a 60-second timeout, or no decision means the workflow runs anyway; a filter is an optimization, never access control.
• Evidence in the document. The filter block shows 7-day counts, the last five rejections, and a "too strict?" warning after 25 events with no passes.