Perplexity Automations Carry Recurring Work Forward With Run History
Perplexity Academy’s guide to Computer Automations argues that recurring work can be handled as a persistent job rather than restarted from scratch each time. Users define the outcome, connected tools and review points, then set the job to run on a schedule or when an event occurs in a supported app; Computer uses the assignment and its history to carry the work forward. The guide also stresses that permissions govern what Computer can do, while credits are used when it performs the work—not while it waits for a trigger.
An automation is a recurring job with memory
Some work does not end when an individual task is finished. It keeps coming back: preparing a briefing, responding to customers, or keeping records current. Perplexity’s Automations hand that ongoing work to Computer as a job that runs on a schedule or in response to an event.
Unlike a one-time request, an automation does not start from scratch each time it runs. Computer uses the assignment and the job’s history, drawing on connected tools, files, projects, and prior work to pick up where it left off. The automation keeps running until it is paused or removed.
Choose a time or an event to start the work
A scheduled task starts at a chosen time. One example is a daily 8 a.m. finance-industry digest that calls out investments, consolidations, and key takeaways. A schedule suits work that should happen regularly, such as a Monday pipeline report or a daily briefing.
A trigger-based automation starts when a condition is met in a supported application. For example, a new email from Pinnacle Manufacturing asking for a decision could prompt Computer to summarize the request, identify its deadline, and notify Maya. Other possible starting events include a new Gmail message or a message in a selected Slack channel.
Setting up an event trigger means connecting the required account, choosing the relevant source, and adding conditions to narrow which changes should start the job. The trigger determines when Computer begins; the assignment determines what it should do.
Write the assignment around the outcome and the handoff
An automation can be started from the Computer omnibar or from the Automations page by selecting “New automation.” In either case, begin with the job to be handled, rather than just naming an app or a trigger.
The release-notes example makes the assignment concrete: when a pull request merges into main, read the changes, draft a customer-facing release note, update the related Linear issue, and prepare a product summary for approval before sharing it in Slack. That instruction specifies an outcome, the tools involved, where the work should go, and a point at which a person must review it.
Those details define the boundary between preparation and action. A useful assignment says not only what Computer should produce, but also when it may act and when it should bring the work back for approval. The connector’s permissions also affect whether Computer can perform an action or only prepare a draft.
Use run history to inspect and manage the job
In the release-notes example, a run can read the merged code, check what it documented previously, draft the next release-note entry, update the Linear issue, and prepare a Slack summary of the pull request. The run history lets users see what Computer produced and how the job has progressed.
An automation’s instructions and status remain available on its detail page. There, users can inspect run history and outputs, edit the assignment as the work changes, pause the automation while the job is on hold, or run it immediately rather than waiting for its next scheduled time or event.
Permissions and credits set practical limits
Connector permissions determine what Computer can access and which actions are available. They also determine whether Computer can act or must prepare a draft for review. The automation’s intended workflow therefore depends on both its instructions and the permissions granted to its connected apps.
Watching for a trigger does not use credits. Credits are used when Computer does the work after the trigger fires. The distinction is between monitoring for the condition and carrying out the assignment: waiting does not use credits, while doing the work does.