Perplexity Teammates: Always On, but Allowed to Do What?

By Lazar Milicevic · Published November 7, 2026 · 8 min read

▶ Watch the video version of this article

A lead arrives while you are away. An AI agent reads the inquiry, finds a similar customer in your CRM, and prepares a follow-up—but should it also update the record or send the email? That boundary matters more than whether the agent can write a convincing reply.

Perplexity announced Teammates on November 5, 2026, as agents for ongoing work. The announcement does not establish how reliably they handle a small business’s particular workflow. Here’s exactly how I would scope a lead-intake pilot before giving one access to business tools.

What “always on” changes—and what it does not prove

An ongoing agent can watch work and act without a fresh prompt, which makes it different from a chat you open for each task. It does not establish that the agent runs uninterrupted, completes every handoff, or makes sound decisions with your customer data.

Perplexity’s description of Teammates says they can monitor ongoing work, use context from Projects, skills, and memory, and work through Perplexity Computer. At launch, Teammates were rolling out to Max users on the web; native apps were planned. Check availability in your own account before designing a workflow around them.

The business opportunity is continuity. In a manual lead-intake process, someone reads an email, searches the CRM, checks a service document, decides whether the lead fits, and drafts a response. A standalone chatbot can help with the draft, but you still have to assemble the context and move the result between systems. An ongoing agent might reduce that repeated briefing if it can retrieve the right information and act within the right boundaries.

That “if” is the pilot. Perplexity’s sales example includes finding stalled conversations and preparing follow-ups for review. It is an example of intended use, not evidence that Teammates accurately handles your CRM, inbox, qualification rules, or clients.

Start with a job that is valuable even when the agent cannot send or change anything: prepare an internal lead brief for a human decision. You can inspect that output, compare it with the source records, and stop there if the evidence is weak.

Define one lead-intake job before connecting tools

A useful first Teammate job has a clear trigger, a bounded output, and an explicit stopping point. For lead intake, the trigger is a new inquiry; the permitted result is an internal qualification brief—not an external message or a CRM edit.

Write the job specification before configuring an agent. This is the version I would use as a starting point, then adjust to the business’s actual rules:

job: prepare_lead_qualification_brief

trigger:
  event: new_sales_inquiry

read_sources:
  - original_inquiry
  - relevant_client_records_if_access_is_available
  - current_service_information

allowed_output:
  destination: internal_review_queue
  contents:
    - inquiry_summary
    - matched_record_or_no_match
    - service_information_used
    - proposed_next_action
    - missing_or_conflicting_information

prohibited_actions:
  - send_external_message
  - create_or_modify_crm_record
  - change_project_or_service_documents

human_decision_required_for:
  - external_reply
  - crm_change

escalate_when:
  - customer_identity_is_unclear
  - records_conflict
  - budget_information_is_missing
  - service_fit_is_unclear

This is a job specification, not a claim that Teammates accepts this YAML or exposes every control named in it. Translate the rules into whichever permissions and instructions your account actually provides. If you cannot enforce a critical boundary, do not connect the tool that would let the agent cross it.

The output should make the founder’s decision easier, not hide the work behind a polished paragraph. For each inquiry, require the original message, any matched customer record, the service information used, the proposed action, and what remains unknown. “Looks like a good lead” is not enough if the reviewer must repeat every lookup to check it.

There is also a practical difference between missing information and negative information. If a prospect does not state a budget, the brief should say “budget not provided,” not “budget is too low.” If the CRM returns two possible matches, the brief should show the conflict rather than choosing one silently. Those distinctions determine whether the next step is a reply, an internal check, or no action yet.

Treat workspace context and action permissions separately

Access to context tells an agent what it can see; tool permissions determine what it can change. Review both before enabling a Teammate, because a sound qualification brief may need service documents and customer history without needing permission to send mail or edit the CRM.

Perplexity says Teammates use Computer’s existing tool and Project permissions. That makes the permission review concrete: inspect the Project, the connected tools, and the account under which each connection operates. Do not infer from “can inspect its work” that every action will wait for approval.

Perplexity’s Projects documentation also draws an important distinction: inviting someone to a Project does not grant access to another member’s personal memory or connected accounts. In other words, shared Project context is not the same thing as access to a founder’s inbox or CRM connection. Test what the Teammate can retrieve in your setup rather than assuming a shared workspace exposes everything—or nothing.

Before a pilot, make a small permission inventory:

The last two rows are deliberate. An internal brief is a useful pilot precisely because it can reveal retrieval and reasoning problems before those problems become customer-facing changes.

Perplexity advises pausing agents before irreversible actions where that option is available, and uses drafting a reply without sending it as an example. That is good design guidance, but it is not a guarantee that Teammates impose universal approval on every email, CRM change, purchase, or deletion. Confirm the available control for each connected tool. If sending cannot be reliably withheld, leave the email-sending connection out of this pilot.

Test evidence and correction time on historical inquiries

A first evaluation should use inquiries for which you already know the correct next step. Start with a small set as an initial pilot, not as a reliability threshold, and check each output against your own source records.

Choose a set that includes an obvious fit, a duplicate inquiry, an existing customer, and an ambiguous request. Remove or protect sensitive information as appropriate for your business and the tools you are testing. For each case, write the expected decision before reading the agent’s output; otherwise, it is too easy to accept a plausible-sounding answer after the fact.

Score the brief on three separate questions:

Use a timer for the manual process and for agent-assisted review. Include the time spent finding omitted evidence, fixing record matches, and rewriting the proposed reply. Real numbers, no estimates: if the agent produces a brief quickly but you must reconstruct its reasoning, it has not yet saved the work that matters.

Keep the test record simple:

Case ID:
Expected next step:
Agent's proposed next step:
Evidence correct? Yes / No / Incomplete
Exception identified? Yes / No / Not applicable
Manual handling time:
Agent review and correction time:
Notes:

Do not reduce the result to a single “accuracy” percentage from a small set of cases. Read the failures. An agent that mishandles a duplicate may create unnecessary follow-up; one that confuses an existing customer with a prospect may produce an inappropriate message. Those cases tell you what to change in the job, permissions, or source documents.

If the briefs repeatedly lack a necessary CRM field, that may be an access problem rather than a reasoning problem. If they cite outdated service information, fix the source-of-truth problem before adding more instructions. If they cannot reliably flag ambiguity, keep the task at draft-only—or stop the pilot.

Design the handoff for when the agent is wrong or paused

A production handoff needs a way to inspect work, redirect it, and know what has not been completed. “Always on” is not a completion guarantee: tasks may pause, including when credits run out, and the checked material establishes no uptime promise for your workflow.

Perplexity says users can inspect a Teammate’s work, take over its desktop, or redirect it while it works. Those are useful intervention options. They do not replace a business process for detecting an inquiry that never reached review.

For a lead brief, define the handoff state explicitly:

• New: The inquiry exists, but no brief is ready.
• Ready for review: The brief links back to the inquiry and shows its evidence.
• Needs clarification: The agent found missing or conflicting information.
• Approved: A person chose the next action.
• Closed without action: A person confirmed that no follow-up is needed.

The key is that “the agent started working” must not be mistaken for “the lead was handled.” Keep the original inquiry visible in the system your team already checks. During the pilot, reconcile incoming inquiries against completed briefs so a paused task cannot quietly become a missed lead.

Before expanding beyond drafts, ask a harder question: what happens if the same inquiry is processed twice? A duplicate brief is inconvenient; duplicate CRM changes or external replies are harder to unwind. Build the review queue around a stable inquiry reference, and have a person resolve duplicates before any write action. Only consider broader autonomy after the draft-only workflow has earned trust in your own records.

Where bizflowai.io fits

At bizflowai.io, my work is building practical AI automations for small teams. The same engineering standard applies here: define the handoff, connect only the context the job needs, and measure whether the finished output reduces human work. Teammates may be one way to run that job, but the workflow test—not the announcement—decides whether it deserves more responsibility.

Want more like this?

For practical AI automation for solopreneurs and small teams, visit bizflowai.io.

Lazar Milićević is a senior engineer who builds AI automations that ship.