- Owning agent — the agent the automation runs as. Each run uses that agent’s permissions.
- Instructions — when it runs and what it does, written in plain English. The trigger is read from this text.
- Granted tools — the exact tools it can use, listed on the approval card and fixed when you approve.
Automations vs. agents
Automations run without anyone there; agents are conversational — you chat with them across multiple turns. If the action should always happen the moment the trigger fires, use an automation. The Agents page carries the full comparison.How automations run
An automation runs only while its status is Active and it shows the Enabled badge. When an event occurs, every matching automation runs independently. Every run performs the same fixed steps you approved. The automation doesn’t interpret the event or make judgment calls at run time, so write instructions as concrete conditions and actions — ‘if the subject contains “support”’, not ‘if it looks like a support request’. Each run has a 60-second limit and can make up to 100 tool calls; exceeding either fails the run. A run that is interrupted before it finishes is retried without repeating the actions that already completed. A run that fails is not repeated; actions completed before the failure stay in effect. An automation acts only through Bizzy tools. It can search the web and read public pages when its owning agent allows those tools, but it cannot make direct requests to other URLs or services. A schedule described in the instructions (“Every Monday at 9am, …”) runs the automation on that schedule instead of on an event. Times are in UTC.Automation lifecycle
Regenerating an automation, or changing its instructions through the API or
MCP, sends it back through Pending Evaluation and Pending Approval. It
doesn’t run again until you approve the new version. An automation that has
completed or expired keeps new instructions without being regenerated.
Permissions
The tools you approve are the only tools the automation can use, and each run also requires every one of them to be set to Allow on the owning agent. If any granted tool is now Ask or Deny, the run fails before doing anything, and the error names the tool. Tools set to Ask are never available to an automation. Permission changes apply to the next run; a run already in progress keeps its starting permissions. Adding permissions to the agent never expands what an automation can do — regenerate it and approve the new version to change that. Email is the exception to “already in progress”: a message the run queued is checked again before each send attempt. Turning the automation off, pausing it, deleting it, letting it expire, or changing the agent’s emailTemplates › send permission stops email not yet sent. Reaching Completed still lets the final allowed run deliver its email. See Sending email. If the owning agent is deactivated, every run fails until you reactivate it. An agent can’t be deleted while it owns automations — see Deleting an agent.Loop protection
An automation never re-triggers on its own actions. If an automation updates a contact and is also set to run when a contact is updated, its own update doesn’t start it again. Chains are limited to three automations in a row. When one automation’s actions trigger another, and that one triggers a third, the automation that would run fourth is set to Paused and Disabled instead of running, and everyone in your business receives the Automation paused notification in-app — and by email unless they’ve turned that off (see Notifications). A paused automation stays off. Review it, then click Resume on its detail page to enable it for future events or scheduled runs. To change what it does, see Changing an automation.Related topics
Create your first automation
Create an automation and approve the tools it can use
Tutorial: turn support email into tasks
A working inbound-email automation, end to end