​

Projects

Projects provide isolated configuration environments for different applications, clients, or use cases. Each user has a default project that is automatically created. API keys, widget apps, and tasks are scoped to specific projects. Projects belong to an organization, enabling team collaboration with role-based access control.

​

Why Use Projects?

​

Project Structure

Each project contains:

• MCP Servers - Model Context Protocol server configurations
• Skills - Custom agent skills and behaviors
• Settings - Model selection, auto-execute mode, workspace paths
• Tool Policies - Per-tool approval policies
• Subagents - Enable/disable built-in subagent capabilities
• Prompts - Custom system prompt additions
• API Keys - Scoped to this project only
• Widget Apps - Scoped to this project only
• Conversations - Chat conversations scoped to this project

​

How to Organize Your Projects

The right project structure depends on your organization. The key principle: each project defines what the agent can access and what it’s allowed to do. Different teams, audiences, and risk profiles should map to different projects. Here is how a typical company sets up 3 projects to cover customer-facing, internal operations, and business intelligence use cases.

​

Project 1: Customer-Facing Support Agent

Audience: Your end customers, interacting via the embedded widget on your website or app. What the agent does: Handles order inquiries, processes returns, issues refunds, sends confirmation emails — the routine 60–70% of support volume that doesn’t require human judgment. Why a separate project: Customer-facing agents need the tightest controls. They should only access customer-relevant systems (orders, payments, email) and never reach internal tools like your CRM, monitoring, or data warehouse. Strict tool policies prevent the agent from taking destructive actions without approval.

---

​

Project 2: Revenue Operations

Audience: Sales reps, customer success managers, and marketing ops, interacting via the widget embedded in your CRM dashboard or internal tools portal. What the agent does: Prepares call briefings by pulling data from CRM, email, support, and analytics. Runs churn risk analysis across account portfolios. Sets up scheduled alerts for pipeline changes and campaign performance. Drafts outreach emails for at-risk accounts. Why a separate project: Internal teams need broader data access (CRM, analytics, support history) than customers should ever see. But they still need approval gates on write operations — you don’t want the agent sending emails or posting to Slack without a human confirming the content first.

---

​

Project 3: Business Intelligence & Reporting

Audience: Business analysts, department heads, and executive team, interacting via the widget on an internal BI dashboard or analytics portal. What the agent does: Runs ad-hoc data analysis against your data warehouse. Generates executive summaries with charts and visualizations. Monitors KPIs and posts automated reports. Processes uploaded spreadsheets and CSVs to produce consolidated reports and anomaly detection. Why a separate project: Analysts and executives need direct access to your data warehouse and BI tools — systems that neither customers nor the sales team should reach. The agent runs SQL queries and Python analysis in the sandbox, which requires a more capable model. Scheduled tasks automate the recurring reports that currently consume hours of analyst time every week.

---

​

Example Organization

​

Team Collaboration

Projects live inside an organization. Every user belongs to one organization, and all projects are scoped to that organization. This enables team-based access control with two levels of roles.

​

Organization Roles

When you sign up, a personal organization is automatically created with you as the admin. You can then invite team members via email from the Console.

​

Project-Level Access

Organization admins have implicit admin access to every project. For regular members, access is granted per-project: To manage project members, go to the Members tab in the project settings on the Console.

​

Invitation Flow

1. An org admin sends an invite from the Console — an email is sent with a registration link
2. The invited person registers using the link — their email is pre-filled and they automatically join the organization
3. The admin then grants the new member access to specific projects

​

Design Principles

When deciding how to split your projects, follow these guidelines:

• Separate by audience. Different user groups need different MCP servers, tool policies, and models. A customer should never share a project with your engineering team.
• Separate by risk profile. Customer-facing projects need strict approval policies. Internal analytics projects can be more permissive for read operations. Match the controls to the blast radius.
• Separate by data access. A project’s MCP servers define what the agent can reach. Don’t give the customer support agent access to your data warehouse. Don’t give the BI agent access to your payment gateway.
• Least privilege by default. API keys, conversations, widget apps, and scheduled tasks don’t cross project boundaries. Regular org members only see projects they’ve been explicitly granted access to.
• Start with one, split when needed. Begin with a single project for your primary use case. Add projects as you onboard new teams or audiences with different requirements.

​

Default Project

Every user has a default project that is automatically created. When using legacy endpoints (like POST /api/users/:username/api-keys), resources are automatically assigned to the default project.

​

Getting Started