Perplexity has added Automations to its Computer agent. The feature runs assignments on a schedule or in response to events from Slack, Gmail, Outlook, Linear, and GitHub, while using previous runs as context.

Carrying context across runs makes Computer more useful for recurring work. A weekly project update can track unresolved blockers, while a pricing report can compare current figures with earlier findings instead of rebuilding its baseline every Monday.

Run history becomes working context

Each Automation combines instructions, a trigger, connected resources, and its run history. When a job starts, Computer can consult files, app connectors, Projects, and previous output before completing the next assignment.

A conventional scheduler usually launches a predefined command at a specified time. Computer can interpret new material, research related information, generate an output, and take permitted actions. That flexibility expands the range of possible workflows while making access controls and review gates more consequential.

Automations replace Perplexity’s older Scheduled Tasks interface. Existing scheduled jobs appear in the new panel and can be migrated when opened.

Triggers can watch time and events

Automations can start at a fixed time, after an event in a connected application, or when an event meets specified conditions. A Gmail trigger, for example, can run only when a particular sender requests a decision.

Missed-update checks give Computer a monitoring role. The agent compares expected events with activity since its previous run, then flags overdue work or missing responses.

Setup centers on access and review

Users can create an Automation from Computer’s omnibar or through the Automations panel. Configuration follows four steps:

  1. Describe the recurring assignment and expected output.
  2. Select a schedule or application event as the trigger.
  3. Connect the required accounts, files, and Projects.
  4. Specify which actions require human approval.

Perplexity includes several operational controls for teams deploying these jobs:

  • Connector permissions: Administrators can restrict the data Computer can access and the actions it can take, including access to shared inboxes and production GitHub organizations.
  • Run records: Users can inspect an Automation’s instructions, status, trigger history, and generated output.
  • Credit usage: Monitoring for triggers consumes no credits. Credits apply when Computer runs an assignment.
  • Migration: Existing Scheduled Tasks remain available through the Automations interface and can be migrated individually.
  • Availability: Automations are available to Computer users.

Three workflows fit the model

Perplexity’s examples focus on recurring knowledge work that often spans workflow tools, scripts, and manual follow-up:

  • Customer reply drafts: Monitor messages from a named Gmail account, consult earlier exchanges and connected files, and prepare responses for review.
  • Engineering changes: When a Linear issue receives a designated label, inspect the repository, implement the change, and open a pull request for human review.
  • Project decisions: When a decision appears in a Slack channel, update the decision log, identify any superseded decision, and flag affected tasks.

Perplexity adds an agent runtime

Perplexity launched Computer as a multi-model agent platform that can research, write code, deploy projects, and manage workflows using 19 specialized AI models. The product has since expanded through an enterprise offering, a Windows client, and a fully local Portable Computer for Nvidia DGX Spark and RTX hardware.

Automations add scheduling, event listeners, and persistent run context to that platform. Teams that currently combine workflow services, cron scripts, and manual checks can express some of those processes as a single agent assignment with connected data and approval controls.

Production evaluations will need to verify several behaviors that determine whether recurring agents remain dependable over long periods:

  • State quality: Does the agent preserve relevant context without carrying obsolete assumptions into later runs?
  • Failure handling: How does the workflow respond to duplicate triggers, interrupted runs, retries, or partially completed actions?
  • Approval boundaries: Do review gates consistently stop sensitive emails, code changes, and account updates before execution?
  • Auditability: Does the run history provide enough detail to reconstruct each trigger, decision, and action?