Automations
AI workflows that run on a schedule or on demand, without you in the loop.
What automations are
An automation is a multi-step AI workflow that runs without you present. You define the logic once, set a trigger, and PandaOS executes it on your behalf, whether that is every weekday at 8 AM or whenever you press a button.
Think of it as combining the visual flow-building of tools like n8n with the reasoning power of an AI model. Each step in the flow can think, decide, call an external app, or delegate to an agent, so the automation handles work that would otherwise require you to sit in front of the screen.
Three ways to build an automation
PandaOS offers three creation paths depending on how much control you want:
-
Describe - Write what you want in plain language ("every Monday, summarize last week's support tickets and email the summary to the team"). PandaOS assembles the flow for you: choosing the right nodes, wiring them together, and configuring the trigger. You can review and edit the result before activating.
-
Build - Lay the flow out yourself in the visual builder, choosing each node and connecting them manually. This is ideal when you already know the exact sequence of steps and want full control over branching and logic.
-
Schedule - Start from the trigger side. Pick a recurring schedule first, then fill in what should happen each time it fires. Useful when the timing matters most, like a daily morning briefing or an end-of-week report.
Triggers: when automations run
Every automation begins with a trigger that determines when it runs. An automation can carry up to five triggers, and any one of them starts the flow, so the same workflow can run on a schedule and when an email arrives.
-
Cron - Runs on a recurring schedule you define, such as every hour, every weekday at 9 AM, or the first of every month. PandaOS uses standard cron expressions under the hood, but you set them through a human-readable picker. A cron-triggered automation runs unattended; you can check results later in the run history.
-
Manual - Runs only when you explicitly start it. This is useful for workflows you need on demand but not on a fixed schedule, like generating a client report when a project wraps up, or pulling fresh analytics before a meeting.
-
App event - Runs when something happens in a connected app: a new email arrives, a calendar event is about to start, a file lands in a Drive folder, a Trello card moves, a GitHub pull request opens. PandaOS polls the app on your behalf and fires the flow when the event matches.
-
Webhook - Runs when an external system posts to a URL that PandaOS generates for the automation. The URL carries a secret, stored encrypted and scoped to this device, and the posted body is available to every node as
{{trigger.payload}}(up to 64 KB).
Apps that can trigger an automation
App-event triggers are available for the apps below. Each provider ships its own set of events and filters, so you narrow a trigger down to exactly the cases you care about rather than firing on everything.
| App | Example events |
|---|---|
| Gmail | New email arrived, email with attachment, email starred, filtered by label, sender or subject |
| Google Calendar | Event created, event starting soon |
| Google Tasks | Task added, task completed |
| Google Drive | File created or modified in a folder |
| Google Chat | New message in a space |
| GitHub | New issue, new pull request, new commit |
| Trello | Card created or moved |
| Supabase | New or changed rows |
| Database | New or changed rows in a connected database |
| Vercel | Deployment finished |
You also choose how often PandaOS checks (from every minute up to once a day) and a firing gate that decides what counts as one event: every match fires, once fires a single time and then stays disarmed until you reset it, or cooldown suppresses re-fires for a number of minutes. Suppressed events are dropped rather than queued, and PandaOS remembers which items it has already seen, so restarting the app or waking from sleep never replays a backlog.
Database and Supabase triggers run your own SQL on a schedule and fire on its result: any rows returned, a row count above or equal to a number, a count crossing a number (once per crossing), or the first row changing since the last check.
Node types: what each step can do
The flow itself is a chain of nodes, each performing one unit of work. You connect them in sequence (or branch them with conditions) to build the full workflow.
-
AI - A reasoning or generation step. The AI model receives the output of the previous node as context and produces text, a decision, structured data, or a summary. Use this for anything that requires understanding or synthesis: drafting emails, extracting key points from a document, classifying incoming data, or deciding what to do next.
-
App - An action in one of your connected apps. This is where the automation interacts with the outside world: sending an email through Gmail, creating a Trello card, inserting a row in Supabase, or posting to Slack. App nodes use the same integrations you have connected in PandaOS settings.
-
Agent - Delegates part of the workflow to one of your Agents. Agents can handle multi-step reasoning tasks that go beyond a single AI node, like researching a topic, writing and refining a draft, or coordinating across multiple tools. If a step needs autonomy rather than a single prompt-response, use an Agent node.
-
Condition - Branches the flow based on a result from a previous node. For example, if the AI node classified a support ticket as "urgent," the condition routes it to an immediate notification path; otherwise, it queues it for the weekly summary. A condition branches either on a plain expression or by asking the model to judge the previous output, so you can build logic without writing code.
-
Output - Delivers the finished result somewhere. Choose a toast notification, a dated file (
YYYY-MM-DD-name.mdin a folder you pick), an existing file that the run appends to or replaces, or a new chat in a project, so the run lands as a conversation you can pick up and continue. An optional template controls what gets written; without one, the accumulated run output is used.
Run history and cost tracking
Every automation keeps a complete run history. Each entry shows when the automation ran, whether it succeeded or failed, and lets you inspect the output of every individual node in the flow. If a step failed, you can see exactly where and why, including the tool calls that were attempted and any partial output produced before the failure.
Runs also track cost per execution. Because automations use AI model calls and app actions, each run has a measurable token and credit cost. The history view surfaces this so you can monitor whether a frequently-running automation is staying within your expected budget, and optimize expensive steps if needed.
Automations build on the same Skills and app integrations you already use in chat, so anything PandaOS can do interactively, it can also do on autopilot.