> For the complete documentation index, see [llms.txt](https://pool-party-xyz.gitbook.io/pool-party-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pool-party-xyz.gitbook.io/pool-party-docs/pool-party-v2-docs/core-concepts/managers-and-strategies.md). # Managers & Strategies A manager designs and runs a pool's strategy. A manager sets the mandate, then actively allocates within it and rebalances over time. The results of those decisions are visible on-chain to every participant. #### **A manager can be a person or an AI** A pool can be operated by a human manager or by an AI agent. From the protocol's point of view they work the same way: they act within the pool's immutable mandate, and the smart contracts enforce the limits. An AI agent gets no special powers; it is bound by the same guardrails as a human. #### **Integrating AI agents** Pool Party is built so that strategies can be run by AI agents. A manager can connect an agent to operate a pool, allocating and rebalancing within the mandate. The deeper technical details live in Developers > DeFAI agents. #### **What a manager can and cannot do** * **Can:** set the mandate, allocate and rebalance within it through adapters, and configure the pool's performance fee. * **Cannot:** hold or withdraw user assets, or act outside the mandate. Custody stays with each user, and the contracts enforce the limits. #### **How managers earn, and why incentives are aligned** A manager earns only a performance fee, charged on a pool's gains and configurable from 10% to 90%. There is no fee just for holding deposits. That structure aligns incentives: a manager is rewarded when the pool produces gains for its users, and earns nothing from performance when there are none. Pool Party takes a share of that performance fee, so the protocol earns the same way the manager does, only when the pool generates gains for its users. #### **Access and identity** Becoming a manager is permissionless: anyone can create and run a pool. Identity verification is optional. A manager can choose to link social accounts to be identified publicly, but it is not required. {% hint style="info" %} Pool Party does not endorse any manager or strategy. A manager's identification, when present, is the manager's own choice and is not a recommendation or endorsement by Pool Party. Evaluate every pool and manager yourself, and always check a pool's performance fee before depositing. {% endhint %} *** *** *** Workspaces and projects are the two containers that organise everything on the platform. Understanding the relationship between them makes the rest of the product much easier to navigate. ## The hierarchy A workspace contains projects. Projects contain deploys, environment variables, and members. ```mermaid graph TD A[Account] --> W1[Workspace: Acme] A --> W2[Workspace: Personal] W1 --> P1[Project: Marketing site] W1 --> P2[Project: Customer portal] W1 --> P3[Project: Internal API] P1 --> D1[Production deploy] P1 --> D2[Preview deploys] ``` ## Workspaces A workspace is the top-level container for a team's work. It owns: * The list of members and their roles * The billing relationship and plan * Workspace-level settings like SSO and audit logs * All projects created within it {% tabs %} {% tab title="Personal" %} Free, single-member workspaces. Good for evaluating the platform, side projects, or solo work. Limited to 3 active projects. {% endtab %} {% tab title="Team" %} Multi-member workspaces with shared billing and a common plan. Most teams should use this. Includes audit logs and member roles. {% endtab %} {% tab title="Enterprise" %} Team workspaces with extras — SSO, SCIM provisioning, custom data residency, and a dedicated support contact. {% endtab %} {% endtabs %} {% hint style="info" %} You can belong to multiple workspaces at once. Switch between them using the workspace picker in the top-left of the dashboard. {% endhint %} ## Projects A project is a deployable unit. Each project has: | Component | What it does | | --------------- | ------------------------------------------------ | | **Source** | The repository or upload that produces the build | | **Builds** | The history of build attempts and their outputs | | **Deploys** | Live versions of the project at a URL | | **Environment** | Variables and secrets specific to this project | | **Domains** | The custom domains pointing at this project | Projects are isolated from each other. Environment variables, secrets, and configurations don't leak across projects in the same workspace. ## When to split into multiple projects A common question: "should this be one project or two?" Use **separate projects** when: * The codebases are different * They deploy independently * They have different sets of secrets * They need different access controls Use **one project with multiple environments** when: * It's the same codebase deploying to different URLs * You want preview deploys per branch * The differences are configuration, not code ## Related {% content-ref url="/pages/fb922e107b31a3e9e9fcf81410029e993b0a9afc" %} [Deposits & Self-custody](/pool-party-docs/pool-party-v2-docs/core-concepts/deposits-and-self-custody.md) {% endcontent-ref %} {% content-ref url="/pages/65332f63d0b6cedd6ac718136ba8d89ec6cc1a4d" %} [Fees & Economics](/pool-party-docs/pool-party-v2-docs/resources/fees-and-economics.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://pool-party-xyz.gitbook.io/pool-party-docs/pool-party-v2-docs/core-concepts/managers-and-strategies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.