Automating Agents With Triggers: Events, Webhooks & Schedules

What a trigger is, in plain support terms. Strip away the branding and a trigger is simply the condition that starts an automated workflow without anyone clicking a button. Every help desk and automation platform has them, and they behave the same way regardless of vendor: Zendesk fires a trigger the instant a ticket is created or updated, iPaaS tools like Workato or Zapier start a "recipe" the moment a webhook lands, and scheduling systems kick off a job at a set time. Across all of them, support triggers fall into three broad families — something happened (an event), something called in over HTTP (a webhook), or the clock struck (a schedule). What differs between products is the action that follows. In a traditional help desk the action is a fixed rule that sets a field or sends a macro. In Macha, the action is an AI agent that reads the context and decides what to do.

So those same three families map exactly onto Macha. A trigger is the event that fires an agent autonomously, with no human in the loop. There are exactly three kinds, and the whole automation surface of the product is built on them:

• Event triggers — your helpdesk or Slack fires the agent (a new Zendesk ticket, a customer reply, a Slack mention).
• Webhook triggers — any external system fires the agent over HTTP, via a unique signed URL Macha generates for you.
• Scheduled triggers — the clock fires the agent on a recurring cron interval (every hour, every morning, every Monday).

This is a pillar overview of all three: what each one is for, concrete examples that actually ship, and — because firing an AI agent at your live queue is not risk-free — an honest section on the guardrails and the cases where you should not reach for a trigger. One thing to keep straight up front: Macha is an agent layer that sits on top of the helpdesk you already run (Zendesk, Freshdesk, Gorgias, Front). Triggers don't replace your helpdesk's own automations — they hang off them, so the routing and SLAs you've already built keep working.

Why triggers, and not just "automation rules"

Most help desks already have automations: if-this-then-exactly-that rules that set a field or send a canned macro. Triggers are different in one important way — what fires isn't a fixed action, it's an agent. The trigger says "something happened," and the agent then reads the full context of what happened, reasons about it against the instructions you wrote in plain language, and decides what to do — reply, look something up via a tool, tag and route, escalate, or stay quiet. That's the shift the broader industry keeps describing: not "if this, then that," but "when this happens, here's what I want you to figure out and do."

So the trigger is deliberately dumb and the agent is smart. Your job when wiring automation is just to pick the right moment — and that's the choice between the three types below.

1. Event triggers — let the helpdesk fire the agent

Event triggers are the ones you'll use most. Each connector you've added publishes a set of native events, and you attach an agent to the ones that matter. When that event happens in your helpdesk, Macha receives it (over a webhook it manages for you behind the scenes) and runs the agent against that record.

The events available depend on the connector. From Macha's connector definitions, the current line-up looks like this:

The two you'll reach for first are New Ticket — which fires on the first customer message, before any agent has replied — and Customer Reply, which fires on every subsequent customer comment.

Concrete example: run an agent on every new ticket. This is the canonical autonomous flow. A "front-line" agent is attached to Zendesk's New Ticket trigger. Every time a customer opens a ticket, the agent reads the subject and body, checks the knowledge base, and either drafts a reply for a human to approve or — if you've enabled the write tools — posts the answer and sets the status itself. Triage agents wire to the same event with a different job: read the ticket, apply a category and priority, and route it to the right group. Most of Macha's 44 published use cases hang off exactly this one event.

One detail worth knowing because it'll bite you otherwise: high-velocity events can fire an agent several times in a few seconds (think a customer pasting three messages in a row). Every event-driven trigger therefore has a Debounce chip — set a delay in seconds and Macha collapses a burst of events into a single run once the queue goes quiet. Messaging defaults to 15 seconds and Slack DMs to 10; everything else defaults to 0 (off) so you opt in deliberately. As a safety net, a debounce bucket force-fires once it accumulates 25 events or waits 10× its window (capped at 2 minutes), so a malformed event source can never hold an agent hostage.

2. Webhook triggers — let anything fire the agent

Event triggers only cover the systems Macha has a connector for. The custom webhook trigger removes that limit entirely: Macha generates a unique webhook URL with a signing secret, and any system that can send an HTTP POST can now fire your agent. No connector required.

This matters because the whole industry has settled on webhooks as the real-time alternative to polling. Polling means repeatedly asking a system "anything new yet?" — slow, wasteful, and always a little stale. A webhook flips the model: the source system pushes the event to you the instant it happens. For support automation that's the difference between reacting in seconds and reacting on your next poll cycle.

Two ways teams use it:

• Your own backend. A new signup hits your app, your order system flags a failed delivery, your monitoring tool detects an outage — POST to the Macha URL and an agent runs with that payload as context. The full raw payload is preserved on the resulting conversation for audit, and for Zendesk/Freshdesk webhooks Macha pulls the ticket_id and subject out of the payload so the run shows up with a readable title in agent history instead of a bare "Custom Webhook."
• Inside your helpdesk's own rules. Every connector also exposes a Custom Webhook trigger specifically so you can drive it from your helpdesk's native automation. You build a Zendesk trigger (or a Front rule, or a Gorgias HTTP integration) in your own Admin Center with whatever conditions you like, point its "send a webhook" action at Macha's URL, and now you control exactly which tickets reach the agent — VIP tag only, specific brand only, business hours only. The native trigger does the filtering; the Macha agent does the thinking.

That second pattern is the one most ops teams graduate to, because it keeps your existing, audited helpdesk logic in charge of which records flow to AI.

3. Scheduled triggers — let the clock fire the agent

Not every job is a reaction to a single ticket. Some are recurring sweeps: a daily digest, a weekly report, a periodic sync. For those you don't want an event — you want a clock. Scheduled triggers run an agent on a recurring cron interval.

Concrete examples, straight from Macha's use-case library:

• Daily support-metrics summary in Slack — every morning at 9:00, an agent pulls yesterday's ticket numbers and posts a digest to your team channel.
• Weekly refund report — Mondays at 9:00, an agent compiles the week's refunds (via the Stripe connector) and posts the breakdown.
• Keep knowledge sources synced — an agent re-checks source pages on a regular interval so the knowledge base your other agents answer from doesn't drift.
• Hourly trending-topics alert — every hour, an agent scans recent tickets and flags any emerging spike to the team.

Because a runaway clock-driven agent could burn credits or hammer an API, scheduled triggers ship with firm guardrails: a minimum 1-hour interval, a 24-runs-per-day cap, and an org-wide concurrency limit of 3 simultaneous scheduled runs. A scheduler polls on a 60-second loop, and any scheduled trigger that fails 5 times in a row auto-disables itself and emails you rather than silently looping on a broken integration. (This is also why debounce doesn't apply to scheduled triggers — there's no event burst to collapse; the cron is the cadence.)

Scheduled triggers are a metered resource on your plan: Professional includes 3, Enterprise includes 20. You can see and manage all of them in one place.

How the three compare

Most production setups use all three at once: event triggers handle the live queue, a couple of webhook triggers cover the systems without connectors, and one or two scheduled triggers run the reporting.

Guardrails — because a trigger means no human approves the run

Handing an agent the keys to your live queue deserves caution, and Macha builds the brakes in rather than assuming you'll remember them.

• Confirmation on high-impact triggers. Turning on a heavy trigger like New Ticket or Every Customer Message pops a confirmation modal explaining the blast radius before it's live, and leaves a persistent advisory card on the agent page so the risk stays visible.
• Draft before send. You don't have to give an agent write access on day one. Leave the reply tools off and the agent drafts for human approval; turn them on only once you trust it. (Sub-agents follow the same rule: they can write replies and updates when running via a trigger, but stay read-only during interactive chat.)
• Pause is non-destructive. Toggling an agent off doesn't delete its Zendesk webhooks or triggers — it flips them to inactive on Zendesk's side, keeping the same resource IDs, so any trigger you built in your own Admin Center that references Macha keeps working untouched when you resume. Even deleting an agent only deactivates its triggers (preserving webhook secrets) and parks it in Trash for 30 days.
• Every autonomous run is auditable. The full raw webhook payload is saved on each autonomous conversation, alongside the extracted ticket ID, subject and requester, so you can always reconstruct why an agent ran.

When NOT to use a trigger

Triggers are powerful, which is exactly why they're the wrong tool for some jobs:

• You haven't tested the agent yet. Don't attach a live event trigger to an untested agent. Build it, run it in chat or test mode first, watch it reason on real tickets, then wire the trigger. A trigger means nobody is checking the output before it goes out.
• The job is a one-off analysis, not a reaction. If you want to read your whole ticket history once and pull out structure — "what share of last quarter was billing?" — that's a Study, not a trigger. Triggers are for ongoing automation; Studies are for bulk analysis.
• You need sub-hourly scheduling. The minimum scheduled interval is one hour. If you genuinely need something every five minutes, drive it from an event or an external webhook instead of the cron.
• The action is irreversible and high-stakes. Issuing refunds, deleting records, closing tickets en masse — keep a human in the loop (draft-only, or route to a person) until you've watched the agent handle the edge cases. The estimate-and-confirm pattern Macha uses elsewhere exists precisely because automation should never surprise you.

A quick note on cost, since automation runs add up: every agent run spends credits per AI action (roughly 0.5–9 credits depending on the model, with the default GPT-5.4 Mini at 1). A debounced event trigger and a sensible schedule both exist partly to keep that predictable — a chatty webhook with no debounce is the fastest way to spend more than you meant to. See the pricing page for how credits map to plans.

FAQ

What's the difference between an event trigger and a webhook trigger? An event trigger uses a native event Macha's connector already understands (a new Zendesk ticket, a Slack mention). A webhook trigger is a generic signed URL that any system can POST to — use it when there's no connector for the source, or when you want your own helpdesk rules to decide which records reach the agent.

Can one agent have multiple triggers? Yes. A single agent can listen to several events at once, plus a webhook, plus a schedule. The agent reads the context of whatever fired it and acts accordingly.

Will a trigger reply to customers automatically? Only if you give the agent write tools. With those off, a triggered agent drafts internally for human approval. High-impact triggers also surface a confirmation modal and a standing advisory before they go live.

How often can a scheduled trigger run? On a recurring cron interval down to a minimum of one hour, capped at 24 runs per day, with at most 3 scheduled runs executing concurrently across your org. Five consecutive failures auto-disable it and email you.

What happens to my triggers if I pause an agent? They're set to inactive, not deleted — webhook secrets and resource IDs are preserved, so resuming the agent brings everything back exactly as it was.

How many scheduled triggers do I get? Professional includes 3 and Enterprise includes 20. See the pricing page for current plans.

Start automating

Triggers are where an agent stops being a tool you open and becomes a teammate that works on its own. Pick the moment — an event, an external signal, or the clock — and the agent does the rest. Start a 7-day free trial, no credit card required, connect your helpdesk, and attach your first trigger; the Triggers docs have the full step-by-step.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.