Projects

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

Project Settings covers the project-level basics: name, members, and project-wide configuration.

​

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.
• It can use the project’s connectors, skills, and MCP servers.
• It runs in its own environment, 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. See 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