> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Projects

> A project is the workspace for one domain of work — its files, tables, SOPs, integrations, and the agent that works them.

A **project** is the unit of work in cloudsquid. It holds one domain of work — Order Entry, AP Invoice Audit, Customer Master Data — with everything that process needs in one place, and an agent that operates inside it.

If you're used to thinking in tools, think of a project as the desk of one team member: their filing cabinet, their reference data, their written procedure, their inbox, and their access badges.

## What's in a project

<CardGroup cols={2}>
  <Card title="Files" icon="folder">
    Folders and files: incoming documents, your `SOP.md`, exports, and anything the agent produces. The agent reads and writes here.
  </Card>

  <Card title="Tables" icon="table">
    Reconcile tables (where processes run), storage tables (your master data), extraction tables (document structuring).
  </Card>

  <Card title="Workflows" icon="git-merge">
    Triggers, syncs, and pushes — the deterministic plumbing around the process.
  </Card>

  <Card title="Connect" icon="plug">
    Connectors, skills, and MCP servers available to this project's agent.
  </Card>
</CardGroup>

**Project Settings** covers the project-level basics: name, members, and project-wide configuration. {/* ⚠️ VERIFY: exact contents of the Project Settings modal */}

## The agent lives in the project

There is no separate "agent object" to configure. Every project has an agent you talk to in the chat panel, and it operates on that project:

* It sees the project's **files and folders** — including your SOP.
* It can query the tables it has been **granted** access to. Grants are per reconcile table, in **Data Access** — see [Governance](/concepts/governance).
* It can use the project's **connectors, skills, and MCP servers**.
* It runs in [its own environment](/concepts/agent-runtime), so it can actually work: run SQL, analyze a spreadsheet, open a PDF, draft an email.

The project boundary is a real boundary. An agent in `Order Entry` cannot read `Payroll`'s files or tables.

## SOPs live in Files

The project's procedure is a Markdown file, `SOP.md`, at the root of the project's Files. The agent loads it automatically and follows it.

**One project = one process = one SOP.** The project *is* the process scope. That's what makes "which rules applied to this case" always answerable, and it's the rule that decides how you carve up your work:

* A **different process** means a **different project**.
* **Steps of the same process** are **tasks in one reconcile table**, sharing the one SOP — not projects, and not separate tables.

Supporting documents — routing rules, code lists, worked examples — can live alongside `SOP.md` as separate files, referenced from it so the agent knows to open them. See [SOPs](/concepts/sops).

See [SOPs](/concepts/sops) for how to write one and how the agent helps.

## The agent produces deliverables into the project

The agent doesn't only fill in table rows. Ask it for something in the chat — a summary of last week's cases, a reconciliation report, a cleaned-up export — and it does the analysis and writes the file into the project's Files, where you (and your team) can download it.

This is on demand, not a scheduled job: you ask, it produces. Give the outputs a home — a `Reporting` folder in Files keeps generated deliverables out of your incoming documents.

## When to split into multiple projects

Use one project per **process and audience**. Split when:

* **The reference data differs.** Order matching needs customer and item master; invoice audit needs POs and receipts. Different data, different grants.
* **The procedure differs.** A project has one `SOP.md`, so two genuinely different procedures are always two projects. This is the clearest signal of the four.
* **The reviewers differ.** Project boundaries are also access boundaries — put a process where the people who review it can reach it and others can't.
* **The connected systems differ.** Keep an ERP-connected process separate from an unconnected sandbox.

Keep them together when it's the same process at a different volume or in a different language — that's one project, and often one reconcile table with more tasks.

## Where to go next

<CardGroup cols={2}>
  <Card title="Tables" icon="table" href="/concepts/tables">
    Reconcile, storage, and extraction tables — and how they chain.
  </Card>

  <Card title="SOPs" icon="file-lines" href="/concepts/sops">
    Teaching the agent your process in plain Markdown.
  </Card>

  <Card title="The agent runtime" icon="microchip" href="/concepts/agent-runtime">
    What the agent can reach and how it does the work.
  </Card>

  <Card title="Governance" icon="shield-check" href="/concepts/governance">
    Data access grants, approval gates, and the audit trail.
  </Card>
</CardGroup>