How Do AI Trigger Polling and State Management Work?

Last updated: April 1, 2026

AI triggers let you describe what you want to monitor — across any combination of apps — and your agent builds a custom watcher that checks on a schedule and alerts you when something new happens. This article walks through how that actually works behind the scenes, step by step.


What AI Triggers Can Do

Before diving into how they work, here are a few examples of what you can set up just by describing it to your agent:

  • "Alert me when a Salesforce deal moves to Closed Won and the contact hasn't been emailed in 7 days." — Watches Salesforce for deal stage changes and cross-checks Gmail history.

  • "Notify me when someone posts in Slack #support and nobody replies within 30 minutes." — Monitors Slack messages and checks for reply activity over time.

  • "Let me know when our pipeline total drops more than 20% since the last check." — Remembers the previous total and compares it to the new one.

  • "Watch for new Jira tickets where the reporter also has open GitHub PRs." — Combines data from two services to decide when to fire.

You describe what you want in plain language. The agent figures out the rest. But what does "the rest" actually look like?


Step 1: Your Agent Writes the Code For You

When you ask your agent to create a trigger, it doesn't just save your words as a rule. It actually writes a custom script tailored to your request.

Here's what the agent does during creation:

  1. Figures out which apps are needed. "Salesforce deal + Gmail history" means the agent needs access to both. If either isn't connected, it asks you to connect it first.

  2. Discovers what data is available. The agent queries each app to find the exact tools it can use — which fields exist, what filters are supported, what data comes back.

  3. Writes a script. Based on your request, the agent writes Python code that knows how to check for your specific condition. This code is custom to your trigger — it's not a generic template.

  4. Tests it. The script runs once in a secure sandbox to make sure it actually works with your real data and credentials. If something's wrong (bad credentials, API error), the agent tells you before activating.

This is the only time AI is involved. The agent uses its intelligence to understand your request and write the code. After this point, the AI model is not called again during polling — which is why triggers are so cheap to run.


Step 2: The First Check — Learning What "Normal" Looks Like

Once the trigger is active, it runs its first check. But here's the key thing:

The trigger will not fire on its first check. This is by design.

Think of it like this: if you tell your agent "alert me when I get a new email from @partner.com," and you already have 200 emails from that domain — the trigger needs to know those 200 emails already exist. Otherwise it would fire 200 times on day one.

So the first check is a baseline capture:

  1. The trigger checks your apps and sees the current state of things — the latest emails, the current deals, today's pipeline total.

  2. It saves that as the starting point: "This is what the world looks like right now."

  3. It does not fire. Nothing is "new" yet — everything is "existing."

From the second check onward, anything that wasn't in the baseline is treated as new, and the trigger fires.

This is why Test Now shows "Empty" right after creation

If you click Test Now immediately after creating a trigger, it will return Empty. That's the baseline being captured — not a bug. To verify your trigger works:

  1. Click Test Now once (captures baseline).

  2. Go create something new in the monitored app (send an email, add a record).

  3. Click Test Now again — it should now return Fired with the new item.


Step 3: Every Check After That — Spot the Difference

Now the trigger is running on its schedule — every 5 minutes, every hour, whatever you set. Each check follows the same simple logic:

  1. Fetch fresh data from your connected apps.

  2. Compare it to what was saved last time. Are there new emails? Did a deal change stage? Did the pipeline number drop?

  3. If something is new → fire. The trigger sends the new data to your agent, which acts on it using the prompt you configured.

  4. If nothing is new → do nothing. Save the current snapshot and wait for the next check.

That's it. Fetch, compare, fire or wait. Every check follows this pattern.


How the Trigger Remembers What It's Already Seen

The "compare it to what was saved last time" step depends on the trigger keeping a small memory between checks. This memory (called state) is different depending on what you're monitoring:

What you're watching

What the trigger remembers

New emails

The IDs of emails it's already seen

CRM record changes

Record IDs + when they were last modified

Spreadsheet updates

A fingerprint of each row's content

Pipeline totals

The dollar amount from the last check

Slack messages without replies

Message IDs + timestamps

This memory is intentionally minimal. The trigger stores just enough to answer the question "is this new?" — not full records or API responses.

What happens over time?

The trigger keeps a sliding window of up to 5,000 entries. When it hits that limit, the oldest entries are automatically dropped. For most use cases — emails, deals, Slack messages — 5,000 entries covers weeks or months of activity.


What Prevents the Same Item From Firing Twice?

Two safety nets work together:

  1. The trigger's own memory. Since it tracks what it's already seen (email IDs, record IDs, etc.), it naturally skips items it reported on last time.

  2. A secondary check. Even if the same item somehow gets flagged as "new" twice (edge case from a race condition), a separate system catches duplicates before they reach your agent. Same item → silently dropped.

In practice, duplicate fires are extremely rare.


What Happens If Something Goes Wrong

Triggers are designed to be resilient, but things can go wrong — an app's API might be down, your credentials might expire, or the check might take too long.

Situation

What happens

A single check fails

The system retries up to 3 times automatically.

3 checks in a row fail

The trigger is auto-deactivated to protect your credits. You'll see it marked inactive in your Tasks section.

A check takes too long

There's a 10-minute hard limit per check. If it runs over, it's stopped.

The next check is due but the current one is still running

The next check is skipped (not queued). Only one check runs at a time per trigger.

You run out of credits

Polling pauses automatically. It resumes when credits are available.

A trigger fires 20+ times in 10 minutes

The circuit breaker kicks in and deactivates the trigger. This usually means the trigger is misfiring on every check.

Re-enabling a deactivated trigger

  1. Go to your agent's Tasks section.

  2. Find the inactive trigger.

  3. Fix the root cause (reconnect credentials, check if the service is up, simplify the trigger if it's misfiring).

  4. Re-enable from the three-dot menu, or tell your agent "re-enable the [trigger name]."


Why AI Triggers Are Cheap to Run

A common question is whether each check involves an AI call. It does not.

The AI is used once — when you create the trigger — to write the code. After that, every check is just that code running in a sandbox. No AI model, no LLM, no token costs. This is why:

  • Checks run in 3–15 seconds.

  • Performance doesn't depend on AI model speed or availability.

The AI model only gets involved again when the trigger fires and your agent processes the event — that's a separate agent interaction with its own cost.


Quick Reference

Item

Detail

Minimum check frequency

Every 5 minutes

Maximum check frequency

Once a week

First check behavior

Captures baseline, does not fire

State memory limit

5,000 entries (oldest auto-trimmed)

Check timeout

10 minutes hard limit

Failures before deactivation

3 consecutive

Circuit breaker

20+ fires in 10 minutes → auto-deactivated

AI model during checks

Not used. Pure code execution.


Still Need Help?

If this didn't resolve your issue, reach out to support at support@gumloop.com.

Related Docs