Triggers and Automation

From Copilot To Worker

Triggers turn an agent from a copilot into a worker. They also remove the human from the loop, which is exactly when bad agent design becomes expensive. The single best thing you can do before enabling a trigger is build the agent assuming the trigger does not exist — meaning every action it takes is something you would be comfortable seeing happen on every matching event without anyone watching.

This page covers the patterns that consistently keep autonomous agents safe.

Narrow The Conditions

Almost every "agent burned through 5,000 credits in two hours" incident comes from a trigger with conditions that are too broad. The fix is always the same: add filters — tags, brands, groups, custom fields — anything that limits the trigger to the tickets the agent was actually designed for.

For Zendesk: in your Zendesk trigger configuration, match on tags like ai-eligible, tier-1-eligible, or specific brands. Do not enable an agent on every new ticket on day one. Start with a narrow tag-based filter, watch the agent for a week, then expand the conditions only after you trust it.

A useful framing: pretend each trigger fire costs $5 to your team's reputation. Would you still fire on every matching event? If not, narrow the conditions until you would.

Use Debounce Settings

Some events fire in flurries — a customer sends six messages in twenty seconds during a Zendesk Messaging conversation. Without debounce, you fire the agent six times: it processes the first message, replies, then the second message arrives, it re-processes everything including its own previous reply, and so on. Six wasted runs, six credits, six chances for the agent to contradict itself.

With a 15-second debounce, the agent waits for the conversation to settle, sees the full thread, and fires once. Much cheaper, much more coherent.

Defaults that work well:

• Messaging triggers (Zendesk Messaging, Slack DM): 15-30 second debounce.
• Comment-added triggers on long ticket threads: 30-60 second debounce if customers commonly send multiple comments back-to-back.
• Ticket-created triggers: usually no debounce. Each new ticket is a discrete event.
• Status-changed / priority-changed triggers: short debounce (5-10 seconds) is harmless.

Scheduled Triggers (Cron)

For agents that should run on a schedule rather than reactively, use the cron trigger type under Macha custom triggers. Useful for daily reports, periodic queue cleanup, or any agent that should run "every Monday at 9am" or "every 4 hours."

Guardrails on scheduled triggers (intentional, important):

• Minimum interval: 1 hour. You cannot run an agent every 5 minutes via the scheduler.
• Daily cap: 24 runs per trigger.
• Org concurrency cap: 3 scheduled triggers running at once across the org.
• Auto-disable after 5 consecutive errors (more on this below).
• Stale lock cleanup at 30 minutes — if a run hangs, the next scheduled fire reclaims the slot.
• Plan limits: trial / starter 0, pro 3, enterprise 20 scheduled triggers.

Watch The First Week

The first seven days after enabling a trigger are when problems show up. Check the agent's conversation history daily. Look for:

• Triggers firing on tickets they should not match. Usually a sign your conditions are too broad. Tighten.
• Agents repeating the same wrong action across multiple events. Almost always an instruction problem, not a tool problem.
• Credit burn higher than expected. Either too many fires (narrow conditions), or the model is too expensive for the workload (downgrade to GPT-5.4 Mini if appropriate).
• Errors coming back from external systems. Connector authentication issues, API rate limits, or write-permission gaps — all surface here.
• Customer-facing replies that would not have passed a human reviewer. If you are not in internal-notes-only mode yet, switch back to it until quality stabilises.

All of these are recoverable on day three. They are expensive on day thirty. Set a calendar reminder.

Trust The Auto-Disable

Macha will auto-disable a scheduled trigger after five consecutive errors. Resist the urge to bump the threshold or override it — five errors in a row almost always means a real problem (a tool credential expired, a connector broke, the agent is stuck in a loop, an external API changed). Fix the underlying issue, then re-enable.

For event-based triggers (webhooks), the equivalent is the connector's auth-failure detection. If a webhook starts failing because the underlying connector lost auth, Macha will deactivate the agents using it and email admins. The agent stays disabled until you manually re-enable, after the connector is healthy again. This is intentional — silent recovery from auth failure is how stale credentials end up being used to do the wrong thing.

Webhook Rejection Tracking

When an external system keeps sending webhooks to a Macha trigger that is no longer active (e.g. you deactivated the trigger but Zendesk still has the webhook configured), Macha tracks the rejection count. After a configurable threshold, Macha returns 410 Gone — a signal to the external system to disable the webhook on its end.

Default thresholds per plan:

• Trial: 20 rejections
• Starter: 50
• Pro: 100
• Enterprise: 200

Practical impact: if you intend to permanently disable a trigger, also clean up the corresponding webhook in the external system. Otherwise the external system will keep firing for a while, accumulating rejection counts, until it gets the 410.

Custom Webhooks

If your event source is something Macha does not have a native trigger for, use a custom webhook trigger. Macha generates a URL and a signing secret; you configure the external system to POST to the URL with the signature header. Common uses: Zendesk triggers with non-standard conditions, internal tools, custom dashboards.

The Macha custom trigger is the same pattern but does not require any specific connector — useful for triggering an agent from a system Macha is not directly integrated with.

Granting Permission Carefully

One last point on autonomy: when a trigger fires, the agent runs without the chat-mode confirmation gate. Tools that would normally pause for human approval execute immediately. This is the entire point of triggers — but it also means tool selection matters more for autonomous agents than for chat agents.

Before enabling a trigger on an agent, look at the agent's tool list one more time and ask: "If this agent calls every one of these tools without anyone watching, am I OK with that?" If the answer is no, remove the tool, or scope the agent's instructions more tightly, or stay in chat mode for now.