Perplexity Teammates Give AI a Standing Job at Work

Perplexity launched Teammates on November 5 with a job description for AI that extends beyond answering the next prompt. A user gives an agent continuing responsibility for work, such as tracking a project or handling incoming bugs. The agent retains context, runs automations and can bring work back for a person to review. Teammates are available to Perplexity Max subscribers on the web.

The sharpest illustration is an on-call engineering example on Perplexity’s product page. A user asks a Teammate to watch alerts overnight, inspect logs and traces when something breaks, find the cause, and open a proposed code fix with a rollback plan. The instructions say to page the person if a fix needs approval or the cause remains unclear after 15 minutes. In the depicted exchange, an alert follows a billing-service deployment. The agent identifies a configuration change, opens a fix and says it needs approval before it ships.

That is a scripted product example, not a measured account of incident response. It nevertheless lays out the arrangement Perplexity wants customers to consider: the machine takes the watch, gathers information and prepares a response; the person retains the decision to release the proposed fix. The practical question is how much work, and how much judgment, crosses the boundary before that request for approval arrives.

From a Finished Task to a Standing Assignment

Perplexity introduced Computer in February as an agent that could carry out tasks in temporary workspaces that ended when the job did. Teammates build on Computer, but keep a continuing thread and draw on projects, skills and memory already held in Perplexity. That progression explains the change better than the word “coworker” does.

Consider the difference in what a manager must specify. A one-off task has a stopping point: produce an answer, draft a file, finish a job. A standing assignment needs rules for what to watch, when to act again and when to interrupt someone. Perplexity says each Teammate has a persistent thread showing what it is doing and has finished. Its product page also describes roles with a standing brief and instructions for when to bring the user in. Those features could spare a person from repeating context every morning. They also make the original instructions more consequential, because an instruction can shape the next action as well as the current one.

Computer is a useful comparison because Teammates inherit its task-performing capabilities while changing the duration of the assignment. Ending a workspace after a job gives a person a natural opportunity to review the result before starting another. A persistent agent can continue through the next event under the same brief. That says nothing by itself about which product is more accurate or safer. It identifies where a user may need to put deliberate review points back into a workflow that no longer stops on its own.

Multiple roles can work simultaneously within a workspace. Assigning separate agents to engineering, support or operations could keep several jobs moving without a person opening a new session for each. It could also make handoffs harder to follow if nobody knows which agent acted on which instruction. A persistent thread offers a place to inspect an agent’s activity; it does not, on its own, settle who may authorize a change in another team’s system.

Approval is One Boundary, Not the Whole Job

The on-call example draws a clear line at shipping code. Before reaching it, though, the agent has been asked to connect to monitoring, read logs and traces, examine the user’s last 20 merged code changes for style, diagnose a fault and prepare a proposed fix. Those steps require access and choices of their own. The example’s 15-minute rule also gives the agent a point at which it should hand an unresolved problem back to a person.

A prospective user can turn that sequence into a more useful set of questions than “Can it do my job?” What can the agent read? What can it change before asking? Who sees its diagnosis and the proposed rollback plan? If it cannot isolate a problem, does its instruction tell it when to stop and whom to alert? In the product example, approval before shipping answers one of those questions. The scope of the agent’s earlier actions needs its own rules.

There is a strong case for this design when the division of labor works as drawn. An agent that keeps the context of an ongoing project could assemble the information a person needs at the moment a decision arises. For an overnight alert, a proposed fix and rollback plan would give the person something more concrete to examine than an alarm alone. Human approval would then be a useful checkpoint, provided the reviewer can inspect the reasoning and has authority to reject the change.

The same example exposes the cost of a thin checkpoint. If a person receives only a polished recommendation after the agent has narrowed the possible causes, the quality of that decision depends on what the agent chose to examine. A reviewer may need the underlying logs, the proposed code change and the reason other explanations were ruled out. That is an inference about how to review delegated work, rather than a claim that Perplexity’s agent missed anything in the depicted incident.

Perplexity’s other examples make the boundary less uniform. An ads agent is instructed to keep spending within caps, pause weak campaigns and send decisions back to a person; a finance example drafts reminders when invoices become overdue. Pausing an ad, drafting a reminder and deploying a code fix have different consequences, so a single rule called “human in the loop” would conceal more than it explains. A team considering a standing agent would have to decide, action by action, what it may do, what it may merely propose and who can reverse it.

Teammates change the unit of delegation from a request to a responsibility. Perplexity has shown a way to describe that responsibility, maintain context and reserve a shipping decision for a person. The enduring test for a workplace is whether its approval rules cover the work the agent does on the way to asking.