# Workflow filters skip irrelevant events before agents run

> An optional filter.ts runs before a workflow, decides in code whether a run happens, and ends rejected events as filtered instead of waking an agent.

Sep 3, 2026. Topics: Workflows, Agents. https://www.generalinput.com/changelog/2026-09-03-workflow-filters

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.