Schedule or webhook? How an AI agent starts

Polling burns capacity discovering nothing happened. Triggers fail silently. The right answer for most unattended workers is both, and the split is not obvious.

Every unattended worker needs something to start it. There are two options, most teams pick one, and picking only one is usually the mistake.

The two, side by side

Read the last two rows together. They are the whole argument for using both.

The cost table nobody runs

The instinct is that faster costs more. For event-shaped work it is the reverse, and the arithmetic is worth doing once.

Take a worker that spends 6 tool calls checking for new work, on a day when 4 real events actually arrive:

The trigger does **less work than the hourly schedule and reacts faster than the minute-by-minute one.** That only happens because polling spends its entire budget discovering that nothing happened, while an event-driven worker does not run at all on a quiet day.

Against real plan limits, the top two rows are not merely wasteful. Free allows 500 tool calls a day and Pro allows 5,000, so a minute-by-minute poller is unaffordable on both, and a 15-minute one does not fit on Free.

So why not trigger everything?

Because triggers travel over a network, and networks drop things. The sending system goes down, a payload arrives malformed, a run errors.

A worker with only a trigger cannot notice it was never called. There is no run, so there is no receipt, so there is nothing to look at. The failure is perfectly silent, which for inbound sales means a lead nobody answered and no record that anything went wrong.

That asymmetry is the real design constraint. A schedule that fails produces a receipt saying so. A trigger that never fires produces nothing at all.

The pattern that actually works

Use the trigger for speed and a low-frequency schedule as the sweep:

• The trigger handles events as they arrive, in seconds.
• The schedule runs twice a day and catches whatever the trigger missed.

For the worker above, a twice-daily sweep costs about 12 extra tool calls and converts a silent miss into a late response. That is one of the better trades available in an unattended system.

Inbound Lead Qualifier is the directory's clearest event-driven kit: it reaches email and CRM and runs on an event, because in inbound sales speed to first response is the variable that moves outcomes. Dynamic Focus-Time Optimizer shows the full pattern, running on demand, on a schedule and on events, so a calendar change rearranges your focus blocks immediately while the schedule still does the 14-day sweep.

When a schedule is simply correct

Not everything is event-shaped, and reaching for a trigger where there is no event to subscribe to is its own mistake.

The third row is the interesting one. Some work has no event to subscribe to, because the condition it responds to is an accumulation rather than a moment. Fragmentation in a calendar is not an event; it is a state that got worse gradually. Polling is the only way to notice.

Choosing a cadence, when it is a schedule

Frequency multiplies everything, so it is worth choosing rather than defaulting.

• Weekly for reports, audits and hygiene passes.
• Daily for digests and overnight triage.
• Hourly for queues that need attention within the working day.
• To the minute is rarely about frequency and usually about alignment: running at 8:55 so output is waiting before a 9:00 standup.

Free allows one schedule per worker, hourly or daily. Pro and Team allow unlimited schedules to the minute. One-time "run once at" schedules are not capped on any plan, including Free.

Schedules run on wall-clock time in your own time zone, so 8am stays 8am through daylight saving rather than drifting by an hour twice a year.

The failure mode to design for

The rule of thumb worth carrying: **a minute-by-minute schedule is usually a webhook nobody wired.**

It is the shape you get when someone wants low latency, does not have an event source configured, and turns the interval down until it feels responsive. The result burns capacity all day, still reacts up to a minute late, and hits the plan cap during the one busy hour when it mattered.

The fix is not a shorter interval. It is finding the event.

The reasonable objection

"Polling is simpler and I will take simpler. A schedule is one field. A trigger is a sender to configure, a secret to hold and rotate, a payload format to agree, and a dependency on somebody else's webhook implementation being correct."

All of that is true, and the cost table above quietly ignores it by counting only tool calls. The honest ledger has a second column:

So the fair statement is not "triggers are better". It is that a trigger buys latency and saves capacity, and pays for it in integration surface. That is a good trade when latency genuinely matters and a bad one when it does not, which is most jobs.

The place the argument really bites is the middle case: an hourly schedule is cheap, simple, and adequate for a great many jobs that people reach for triggers on because triggers feel more sophisticated. If "within the hour" is fine, the simpler thing is also the correct thing, and the cost table is not an argument to the contrary.

Where simplicity stops winning is when the schedule you would need to match a trigger's latency is the one that does not fit the plan at all. Every 15 minutes is 576 calls a day against Free's 500. At that point "simpler" has become "unaffordable", and the integration surface is what you buy your way out with.

When neither is the answer

• The job is genuinely interactive. Run it on demand and stay in the loop.
• You cannot say what a run should do. Cadence is not the problem; the instruction is.
• The work is very low volume. Under a handful of items a week, a person handles them faster than you will tune either mechanism.

FAQ

Should an AI agent run on a schedule or a webhook trigger?

Use a trigger when the job is a reaction that must happen within seconds, and a schedule when the job has a natural rhythm and "within the hour" is fine. Most production workers want both: the trigger for speed, a low-frequency schedule as the sweep that catches missed events.

Is a webhook trigger cheaper than polling?

Usually, yes, and often dramatically. A trigger only runs when something happened, where a frequent schedule spends tool calls all day discovering nothing arrived. A worker handling four events a day costs about 24 calls on a trigger against 576 on a 15-minute schedule.

What happens if a webhook never arrives?

Nothing runs, and nothing is recorded, which is why a trigger alone is risky. A low-frequency schedule alongside it turns that silent miss into a late response for a handful of extra tool calls.

Do WorkerKit schedules follow my time zone?

Yes, wall-clock time in your own zone. A worker set for 8am runs at 8am through daylight saving changes rather than drifting. Free allows one schedule per worker hourly or daily; Pro and Team allow unlimited to the minute.

How are webhook triggers secured?

Each trigger is signed with a secret the calling system includes, verified before anything runs. Secrets can be rotated, and a stale one produces refused calls rather than silent success, so the failure is visible.

Does a triggered run cost more than a scheduled one?

No. A run costs the same however it started: its tool calls against your plan's daily allowance, plus model tokens at provider list price with no markup. See /pricing.