How to Use Perplexity Spaces: A Step-by-Step Guide

To use Perplexity Spaces, open the Projects area, create a new Project, give it one clear purpose, add focused instructions and relevant material, then ask related questions inside it. Perplexity now calls these workspaces Projects, although older guides and the official URL still use “Spaces.” The current product is designed to keep research, instructions, files, and related work together, making it useful for students, researchers, creators, and teams managing an ongoing topic.

The key is focus: build one workspace around one outcome, test it with a small query, and check the source material behind important answers.

What Are Perplexity Spaces?

Perplexity describes Projects as dedicated workspaces for organizing, collaborating on, and managing research. A Project acts as a centralized knowledge hub using custom AI instructions, file search, and task management. In practical terms, that makes it a persistent home for work that would be awkward to manage across disconnected chats. See Perplexity’s current Projects guide.

A Project is a good fit when your questions share context—for example, studying one course, researching a report, or developing a content series. A standalone question that needs no follow-up usually does not require its own Project.

How to Set Up a Perplexity Space

The current official setup begins by clicking the Projects icon in the left panel and selecting + New Project. Perplexity documents that first step here.

From there, use this workflow:

1. Define one outcome. Try “Compare evidence for my report on remote learning,” not simply “Research.”
2. Use a recognizable name. Name the Project after its subject or deliverable so you can find it later.
3. Write custom instructions. Specify the audience, response format, tone, and evidence standard. Perplexity says Project instructions apply to every interaction and can shape the assistant’s tone, domain, or reasoning style. Review the official feature description.
4. Add relevant context. Keep the source set narrow enough that every item serves the Project’s goal.
5. Ask a test question. Request a short summary, an outline, or a list of unanswered questions before assigning a large task.
6. Refine the setup. If the response is vague or poorly structured, improve the instructions or remove distracting context and test again.

Here is a compact visual for the setup loop:

One goal → Custom instructions → Relevant material → Test query
    ↑                                                ↓
    └──────────── Review and refine the setup ───────┘

A reusable instruction might say: “Write for a non-specialist reader. Organize the answer with descriptive headings. Distinguish source-backed facts from interpretation, and do not guess when information is missing.”

Key Features and How to Use Them

Projects combine several elements that are most useful when they support one another:

Project goal
├── Instructions: audience, tone, format, boundaries
├── Context: files and other relevant source material
├── Sessions: focused questions and follow-ups
└── Sharing: controlled access for readers or contributors

Custom instructions reduce repetition. Put stable requirements there rather than restating them differently in every prompt.

Files and prompts give the workspace project-specific context. Perplexity’s getting-started guide recommends adding prompts and files to a Project and tailoring it for teamwork or shared research. Read the official getting-started guidance.

Sessions let you break a large topic into manageable questions. Keep each session focused on one subproblem, such as summarizing a document, identifying contradictions, or developing the next section of a report.

Sharing supports collaboration without making every Project public. Projects are private by default, and the Share control can grant view access to invited members, eligible organization members, or anyone with the link. Check Perplexity’s sharing options. Before sharing, review the selected access level and the material inside the Project.

Practical Workflows

Choose the next step based on what you want the Project to do:

For a research Project, begin with “What are the main subquestions?” rather than asking immediately for a finished report. Next, request a structured summary of the available material and identify conflicts or missing information. Investigate those gaps individually, then ask for a synthesis. This sequence makes review easier because each step has a narrow purpose.

For a team Project, separate research support from project tracking. Use the workspace to explore sources and develop conclusions, but record owners, deadlines, and approvals in the system your team uses for operational accountability.

Build prompts that use the Project context

A Project becomes more valuable when each prompt tells the assistant what to do with the shared context. A reliable prompt can contain four parts:

1. Task: State the action—compare, summarize, question, outline, or revise.
2. Scope: Identify the material or topic the answer should cover.
3. Output: Define the structure, audience, and approximate level of detail.
4. Quality check: Ask for uncertainties, conflicts, or missing inputs to be identified.

For example, instead of asking, “What does this material say?” try: “Compare the two approaches described in the project material. Write for a beginner, use a two-column table, and finish with any disagreement between the sources.” The second version gives the task a boundary and creates an output you can inspect.

Follow-up questions should narrow or challenge the first answer, not simply request “more detail.” Useful follow-ups include:

• “Which source supports the second conclusion?”
• “What assumption would change this recommendation?”
• “Rewrite this explanation for someone new to the topic.”
• “List the unresolved questions before drafting the final section.”
• “Separate facts from suggestions in the response.”

This approach also makes earlier work easier to retrieve. If session names and questions refer to a particular decision or subtopic, you can return to that thread instead of searching through a long general conversation.

Use a review checkpoint

Create a review checkpoint before turning research into a deliverable. At that point, list the claims you expect to use, the material behind each one, any disagreement among sources, and the questions still unanswered. Then inspect the original material for every claim that affects a decision.

A simple checkpoint can use four labels:

The labels are your organizational method, not automatic product statuses. Their purpose is to prevent a polished synthesis from hiding uncertainty in the underlying work.

For collaborative research, assign a human reviewer to each high-impact section. Team members can use the same Project context, but shared access does not replace responsibility for checking conclusions. Record what was approved and when outside the AI response so the decision remains easy to audit.

Best Practices and Troubleshooting

Keep the scope narrow. If one Project starts serving unrelated goals, split it. A focused context is easier to prompt, search, and review.

Use a short Project brief at the top of your working notes:

• Outcome: What will exist when the work is done?
• Audience: Who will use it?
• Included: Which topics and sources belong here?
• Excluded: Which tempting side topics should be ignored?
• Definition of done: What must be checked or approved?

Review this brief when the work changes. If the outcome changes substantially, update the instructions and run another small test before continuing.

Turn instructions into acceptance criteria. “Write a useful report” is subjective. “Write five short sections for beginners, identify assumptions, and end with three open questions” is testable.

Check important claims. Open the supporting material and verify names, dates, quotations, calculations, and conclusions before reusing an answer. Fluent wording is not proof of accuracy.

If an answer is too generic, name the audience, desired depth, format, and decision the response should support.

If the answer overlooks your material, point to the relevant file or topic, reduce unrelated context, and confirm the intended material is inside the Project.

If answers vary across sessions, move stable requirements into the custom instructions and use a consistent prompt template.

Also compare the prompts themselves. Two questions that appear similar may ask for different audiences, time periods, or kinds of evidence. Standardize those inputs before deciding that the responses are inconsistent.

If collaborators cannot access the right content, reopen Share and check the chosen view or contributor settings. Remember that default privacy is a safeguard; access must be configured deliberately.

Before sharing, use a quick access checklist:

1. Remove material that the recipient does not need.
2. Check whether the recipient should view the work or contribute to it.
3. Select the narrowest sharing option that fits the task.
4. Confirm that the Project contains no notes intended only for the author.
5. After the collaboration ends, review whether access is still needed.

For organization-managed accounts, local policies may add requirements beyond the controls visible in the Project. Follow those policies when deciding what can be uploaded or shared.

If the interface says Projects rather than Spaces, you are in the right place. Follow the current Project labels instead of older tutorial wording.

If the Project becomes cluttered, pause before adding more material. Remove duplicates, separate unrelated work, and create a concise recap of the active goal. Then start the next session with a specific subquestion rather than asking for a broad summary of everything.

If an answer cites the wrong part of a source, restate the scope and name the relevant document or section. Open the cited material yourself and verify that it actually supports the sentence. If it does not, revise or remove the sentence instead of trying to prompt the system into defending it.

If the output format keeps drifting, provide a small template. For example, request the same four headings—Summary, Evidence, Open Questions, Next Action—in every status update. A fixed template makes differences between sessions easier to spot.

If a task feels too large, divide it into discovery, evaluation, and synthesis. First map the available information; next assess individual items against shared criteria; only then request a combined answer. Smaller stages make it easier to locate where an error or unsupported assumption entered the workflow.

Next Steps

Create one narrowly scoped Project for a real task. Add a short instruction block, include only relevant material, and ask for a summary plus three unanswered questions. Review the response, refine the setup, and expand the work only after that small test succeeds.

If you want a guided next step for building practical AI habits, explore Coursiv AI lessons.

Frequently asked questions