# Cofounder Docs > Standalone docs site for the Superoptimizers-hosted Cofounder documentation. This document contains the full content of all documentation pages for AI consumption. --- ## Introduction **URL:** https://docs.cto.cofounder.co/ **Description:** Get started with Cofounder and run your business with agents. ## What is Cofounder? Cofounder is a workspace for running your company with agents. Work is organized into departments, and each department has agents with their own scope, tools, and skills. That might mean a GTM agent that knows your go-to-market playbook, or an engineering agent focused on building product. You hand work to the right agent, and Cofounder keeps it organized in one place. ## Start Here ## Explore The Product --- ## Custom Agents **URL:** https://docs.cto.cofounder.co/agents/custom-agents **Description:** Create your own agents and route work to the right custom agent. ## Custom Agents Custom agents let you turn repeatable work into a reusable agent in Cofounder. Use a custom agent when the same kind of work shows up again and you want it handled with the same instructions, tools, and output format each time. ## When To Add A Custom Agent Use a custom agent when the task is: - Repeated often - Owned by a clear specialty - Best handled with the same instructions every time - Dependent on a known set of tools or approvals - Easier to automate with a focused workflow than with a general-purpose agent Custom agents are a good fit for work such as: - A marketing agent that writes campaign briefs and updates launch docs - An engineering agent that follows your review and testing process - An operations agent that collects data and prepares status updates ## Common Workflows ### Create a custom agent 1. Open **Canvas** and use the `+` button to add a new agent. 2. Give the agent a clear name and purpose. 3. Add the instructions, skills, and tools it should use. 4. Save it as a reusable agent. Use names that describe the job, not the underlying model. For example, **Launch Planner**, **QA Reviewer**, or **Support Triage Agent** are easier to understand than a generic label. ### Route work to the right agent Cofounder can automatically match work to the most appropriate custom agent in your workspace. - A support request can go to a support agent - A launch request can go to a marketing agent - A test failure can go to a QA or engineering agent Automatic matching works best when each agent has a clear purpose and a distinct scope. ## Customize A Custom Agent ### Refine the instructions Instructions are the most direct way to shape how an agent behaves. Use them to define: - The agent’s role - The expected result - The tone and format - Decision rules - What to do when information is missing ### Add skills Skills extend an agent with repeatable behaviors for a specific kind of work. Use skills when the agent needs to: - Follow a checklist - Format output in a specific way - Apply a known process - Handle a recurring task with the same steps each time ### Connect the right tools Custom agents work best when they can access the tools they actually need. For example, an agent might use: - `GitHub`, `Linear`, `Vercel`, or `Supabase` for engineering work - `Notion`, `Google Docs`, `Google Drive`, or `Airtable` for content and planning work - `Slack`, `Gmail`, or `Intercom` for support and communication workflows - `Stripe`, `Metabase`, `PostHog`, or `Attio` for billing, reporting, and go-to-market work ### Schedules And Triggers Schedules and triggers belong to the agent. Use a **schedule** when the same agent should run on a cadence such as every morning, every weekday, or every week. Use a **trigger** when the same agent should run because a trusted source event happened. Typical trigger sources include: - GitHub - Vercel - Linear - Agentmail emails You can add further natural-language instructions to filter which events should actually trigger the agent. ## Next Steps - [Agents Overview](/agents/overview) - [Rules And Skills](/agents/rules-and-skills) - [Integrations Overview](/integrations/overview) --- ## Agents Overview **URL:** https://docs.cto.cofounder.co/agents/overview **Description:** Understand what an agent is in Cofounder, what it consists of, which agents are created by default, and how to add new ones. ## What An Agent Is Agents are the units that do work in Cofounder. Each one is responsible for a particular kind of job. That might be engineering work, go-to-market work, SEO, security, or infrastructure. When you start a task, you are handing that work to an agent with the right scope for the job. Agents are organized inside departments. **Cofounder** is the exception. It is the top-level agent for the workspace, accessible from the side panel. It can help create or route tasks across the workspace instead of acting like a department-specific agent. ## What An Agent Includes Every agent has a few core parts: - **Instructions** that define what the agent owns and how it should behave - **Model** that defines the reasoning engine the agent uses - **Integrations** that define which tools and systems it can use - **Skills** that add reusable guidance for a specific kind of work - **Subagents** that let it delegate narrower parts of a task to another helper agent - **Department** that determines which lane of the company the agent belongs to An engineering agent and a GTM agent should have different instructions, different tools, different skills, and live in different departments. ## Default Agents After onboarding, your workspace includes default agents for the main operating areas. The default set includes: - **Cofounder** - **Engineer** - **Security Engineer** - **Infra Agent** - **GTM Agent** - **SEO Agent** ## Default Agent Roles - **Cofounder** is the top-level workspace agent in the side panel - **Engineer** is for product and app work - **Security Engineer** is for security-specific reviews or changes - **Infra Agent** is for infrastructure, environments, and deployment-related work - **GTM Agent** is for launches, messaging, campaigns, and other go-to-market work - **SEO Agent** is for search and content visibility work Cofounder sits above that layer as the workspace-level agent, while the others are agents for specific kinds of work. ## Adding New Agents You can add new agents when you need an agent that does not already exist in the workspace. Examples include support, operations, finance, recruiting, or a specific internal workflow. New agents usually include: - one clear job - the right integrations for that job - the few skills that actually help - subagents only when the work truly needs delegation ## Agents Vs. Skills Vs. Departments - An **agent** is the worker - A **skill** is reusable guidance attached to that worker - A **department** is the operating area that groups agents and their work ## Next Steps - [Departments](/workspace/departments) - [Rules And Skills](/agents/rules-and-skills) - [Canvas](/workspace/canvas) --- ## Rules And Skills **URL:** https://docs.cto.cofounder.co/agents/rules-and-skills **Description:** Understand the difference between rules and reusable skills, and how they connect back to your agents. ## Skills Skills are reusable guidance assets. Each skill includes: - a name - a description - a `SKILL.md` - optional supporting files From the Skills UI, you can: - create a new skill - import a skill from GitHub - open a skill and browse its files - edit custom skills directly in the app - upload additional files into a custom skill - attach selected skills to an agent from the agent form Built-in skills can be read-only. Custom skills can be edited or deleted. ## When To Use A Skill Use a skill when: - the guidance should be shared across multiple agents - the instructions are deep enough that they deserve their own file - you want supporting reference files, not just one text box Use agent custom instructions when the guidance is specific to one agent and does not need its own reusable package. ## Rules Rules live in the **playbook** system, which is surfaced through the same `Rules & Skills` page. They can be learned automatically from past agent behavior, and you can also add, edit, pin, or delete them manually. When an agent runs a task, Cofounder injects the relevant rules based on the task and context. ## What Rules Are Good For Rules are a good fit for durable operating guidance like: - always verify production-impacting actions before execution - prefer reading existing implementation before proposing a refactor - check deploy state before reporting an incident resolved ## How Rules Differ From Skills Rules: - are playbook items - can be learned automatically or added manually - are injected into agents when relevant to the task - can be pinned, edited, and reused as persistent learnings Skills: - are file-backed guidance packages - can include `SKILL.md` plus supporting files - are attached directly to agents by name - can be built in or custom ## Next Steps - [Agents Overview](/agents/overview) - [Custom Agents](/agents/custom-agents) - [Integrations Overview](/integrations/overview) --- ## What Happens After Onboarding **URL:** https://docs.cto.cofounder.co/get-started/after-onboarding **Description:** Understand what Cofounder sets up during onboarding and how your workspace is organized once you are ready to start work. ## Your Workspace Is Already Structured After onboarding, Cofounder should feel like a working company system, not a blank sandbox. After onboarding, your workspace already has departments for the parts of the business you want to run, agents inside those departments, and the core infrastructure those agents need. ## What Onboarding Sets Up Every onboarded workspace gets: - an **app** GitHub repository for the main app codebase - a **marketing** GitHub repository for the site, launch pages, and growth surface - corresponding **Vercel** projects so app and marketing work can ship to the right deploy target - a managed **Supabase** project for the organization's database and backend operations - starter departments and agents aligned to the way the company runs - a shared **Library** for files that agents and users need to reference across work ## How That Maps To Departments Cofounder organizes work through departments. A department owns a slice of the company, and the agents inside that department inherit the context, tools, and scope that make sense for that lane of work. For example: - the **Engineering** or **Product** department might contain agents that can work in the app repo, inspect PRs, and reason about the main app - the **GTM** or **Marketing** department might contain agents focused on launches, messaging, campaigns, and the marketing repo - infrastructure-aware agents can work against the org's Vercel and Supabase setup when the task needs deploy or backend context ## What Agents Actually Do Next Once onboarding is complete, the normal flow is: 1. Open **Canvas**. 2. Go to the department that owns the job. 3. Choose the agent with the right scope. 4. Give it a concrete task. 5. Review the result, then refine the setup if needed. ## Next Steps - [Quickstart](/get-started/quickstart) - [Library](/workspace/library) - [Departments](/workspace/departments) - [Agents Overview](/agents/overview) - [Managed Services](/managed-services/overview) - [Integrations Overview](/integrations/overview) --- ## Quickstart **URL:** https://docs.cto.cofounder.co/get-started/quickstart **Description:** Go from an empty workspace to a useful first result with two concrete starter flows: shipping a PR review loop or drafting a marketing campaign. ## Start With One Real Job Do not try to set up the whole platform on day one. Pick one useful job, connect the minimum context it needs, and review the result before you scale it up. Two strong starter flows: - **Engineer agent:** put up a PR, then review the preview - **GTM Agent:** draft a marketing campaign you can refine and ship ## 1. Open Canvas And Pick The Agent Open **Canvas**, then choose the starter agent that matches the job: - **Engineer** for code changes, PRs, and preview review - **GTM Agent** for campaign planning, messaging, and launch drafts To launch the task, either hit the `+` button at the bottom of the canvas or ask the **Cofounder** agent in the side panel to create the task for you. ## 2. Launch One Of These Requests ### Engineer Starter Flow Ask for something direct, such as: `Add "Hello world" to the landing page.` ### GTM Starter Flow Ask for something equally concrete, such as: `Draft a marketing campaign for this launch, including the core message, channel plan, and first-pass copy.` ## 3. Review The Agent's Output What you review depends on the agent: - For the **Engineer** agent, Cofounder should put up or merge a PR with the requested change. - For the **GTM Agent**, Cofounder should create an artifact with the marketing campaign. ## Next Steps - [Agents Overview](/agents/overview) - [Custom Agents](/agents/custom-agents) - [Integrations Overview](/integrations/overview) --- ## MCP **URL:** https://docs.cto.cofounder.co/integrations/mcp-toolkits **Description:** Use Composio-powered MCP integrations to connect more apps to your workspace. ## MCP MCP in Cofounder is powered by **Composio**. You can find it from **Integrations**, under the **MCP** tab. From there, you can connect additional apps for your workspace and make them available to agents. ## How It Works 1. Open **Integrations**. 2. Go to the **MCP** tab. 3. Search for the app you want to connect. 4. Complete the connection flow. 5. Use it from the relevant agent once it is available. ## Next Steps - [Integrations Overview](/integrations/overview) - [Agents Overview](/agents/overview) --- ## Integrations Overview **URL:** https://docs.cto.cofounder.co/integrations/overview **Description:** Understand which integrations are already connected after onboarding and which ones you can add later. ## Built-In Integrations Agents already have built-in integrations to **GitHub**, **Vercel**, and **Supabase**. These connect automatically to the managed repos and projects created during onboarding: - the app GitHub repo - the marketing GitHub repo - the corresponding Vercel projects - the managed Supabase project That means agents can start working against your core engineering and infrastructure setup without extra connection work. ## Adding More Integrations You can add additional integrations from the **Integrations** page when agents need access to more of your stack. Common examples include: - **Linear** for issues and project work - **Slack** for team communication - **Notion** for docs and planning - **Gmail** for email workflows - **Intercom** for support - **Stripe** for billing and payments ## Linear After you connect **Linear**, Cofounder can be used as an agent inside Linear and can automatically work on tasks in Linear. That gives you a way to start work from Linear itself instead of only from Canvas. ## Next Steps - [Payments And Stripe](/integrations/payments-and-stripe) - [What Happens After Onboarding](/get-started/after-onboarding) - [Custom Agents](/agents/custom-agents) - [MCP Toolkits](/integrations/mcp-toolkits) --- ## Payments And Stripe **URL:** https://docs.cto.cofounder.co/integrations/payments-and-stripe **Description:** Connect Stripe, sync it into the managed app, and use the Payments agent to add billing to your app. ## Where To Add Stripe Keys Add Stripe from **Settings > Payments**. Org admins can paste: - the Stripe publishable key - the Stripe secret key Cofounder verifies the keys before treating Stripe as connected. ## What Happens When Stripe Is Connected Once the keys are valid: - Stripe shows up as a connected integration for the workspace - Cofounder syncs the Stripe config into the managed app - the app is ready for Stripe implementation work - the Stripe webhook is configured to point at the managed app Test keys stay out of production. Live keys sync to production only. ## Payments Agent From **Settings > Payments**, you can kick off the **Payments agent**. The Payments agent works with you to add Stripe to the app. That can include: - wiring Stripe into the app - adding checkout or subscription flows - setting up billing-related app logic - finishing work when Stripe is already partially connected This is the path to use when you want Cofounder to help implement payments, not just store keys. ## Stripe In The Managed App When Stripe is connected, Cofounder syncs the Stripe configuration into the managed app project. That includes: - the publishable key - the secret key - the webhook signing secret ## Stripe Webhook When you connect Stripe, Cofounder also configures the Stripe webhook for the managed app automatically. The webhook points at the managed Vercel app's Stripe webhook route: `/api/stripe/webhook` If a domain has already been assigned to the app, Cofounder uses that domain for the webhook URL. Otherwise it uses the managed Vercel app URL. The webhook signing secret is then synced into the managed app as well. ## Seeded Webhook Route The managed app starter already includes a Stripe webhook route. That route verifies the Stripe signature and gives the app a starting point for webhook handling. The Payments agent can then help add the app-specific billing logic on top of it. ## Next Steps - [Integrations Overview](/integrations/overview) - [Managed Services](/managed-services/overview) - [Migrations](/managed-services/migrations) --- ## GitHub **URL:** https://docs.cto.cofounder.co/managed-services/github **Description:** Understand how managed GitHub repositories are created during onboarding. ## GitHub During onboarding, Cofounder creates two managed GitHub repositories: - an **app** repository - a **marketing** repository These repositories are private and auto-initialized during provisioning. ## Role GitHub is where the code lives. - the **app** repository holds the main product codebase - the **marketing** repository holds the site, launch pages, and growth surface ## What Cofounder Sets Up After the repositories are created, Cofounder also seeds: - baseline repository config - initial folder structure - `.github/workflows` CI files ## How GitHub Connects To The Rest Of The Stack The managed GitHub repositories are what the managed Vercel projects get linked to during onboarding. They are also the repositories the engineering agents work against when they open branches, make changes, and put up pull requests. ## Import Your Own Repo Some workspaces also let you replace the managed app repo or marketing repo with a repo you already own. That flow lives in **Settings > Advanced**. It covers: - choosing whether the repo is for the app or marketing site - selecting the GitHub repo - making sure the Cofounder GitHub app is installed - linking the managed Vercel project to that repo - setting the root directory - syncing env vars For app repos, it can also keep managed Supabase env wiring, migrations, and the `prod` branch setup aligned. ## Next Steps - [Vercel](/managed-services/vercel) - [Managed Services](/managed-services/overview) --- ## Migrations **URL:** https://docs.cto.cofounder.co/managed-services/migrations **Description:** Understand how database migrations work in the managed app repo. ## Migrations Use migrations for database schema changes in the managed app repo. That includes changes like: - adding tables - changing columns - updating indexes or other schema-level database setup If you are adding tables, this is the workflow to use. In practice, have the **Engineer** agent work on the schema change and add the migration in the app repository. ## Where Migrations Live Migrations live in `supabase/migrations/` in the app repository. ## How The Workflow Works 1. Add the migration file in the app repository. 2. Put up a GitHub pull request with that migration. 3. When that PR is open, the seeded GitHub workflow lint checks the migration files. 4. When that PR is merged into `main`, the seeded staging migration workflow runs automatically. 5. When those changes are later published from `main` to `prod`, the seeded production migration workflow runs automatically. ## Staging And Production - merging a migration PR into `main` applies it to staging - publishing to `prod` applies it to production That keeps migrations lined up with the same staging-to-production flow as the app code. ## Next Steps - [Supabase](/managed-services/supabase) - [Publishing](/publishing/overview) - [Environments](/publishing/environments) --- ## Managed Services **URL:** https://docs.cto.cofounder.co/managed-services/overview **Description:** Understand how managed GitHub, Vercel, Supabase, and Postmark are set up during onboarding. ## Managed Services During onboarding, Cofounder sets up a managed stack for the workspace. That stack includes: - managed **GitHub** repositories - managed **Vercel** projects - a managed **Supabase** project - a managed **Postmark** server These services are linked together during onboarding so agents can start working against them right away. ## Access Users get access differently depending on the service: - **GitHub**: users are given access to the managed repositories during onboarding - **Vercel**: users are invited to the managed Vercel projects during onboarding - **Supabase**: Cofounder manages the project for the workspace, but users are not invited into Supabase yet - **Postmark**: Postmark is managed for the workspace in the background ## What Gets Managed - **GitHub** holds the app and marketing repositories - **Vercel** runs the app and marketing projects, plus staging environments - **Supabase** provides the managed backend, with staging and production for the app - **Postmark** handles transactional email and sending-domain setup ## Pages - [GitHub](/managed-services/github) - [Vercel](/managed-services/vercel) - [Supabase](/managed-services/supabase) - [Migrations](/managed-services/migrations) - [Postmark](/managed-services/postmark) - [Publishing](/publishing/overview) --- ## Postmark **URL:** https://docs.cto.cofounder.co/managed-services/postmark **Description:** Understand how Postmark handles transactional email in Cofounder. ## Postmark During onboarding, Cofounder provisions a managed Postmark server for the workspace. It also prepares the default email setup for the workspace. ## Role Postmark handles transactional email for the workspace. - it powers product emails like sign-in links and other system email - it connects sending domains to the managed app setup - it gives Cofounder a managed email provider instead of making users wire this up themselves ## Domain Sync When a domain is assigned in `Settings > Domains`, Cofounder can sync that domain to Postmark as well. The user still needs to activate the domain for Postmark before email can send from it. ## Next Steps - [Settings: Domains](/settings/domains) - [Managed Services](/managed-services/overview) --- ## Supabase **URL:** https://docs.cto.cofounder.co/managed-services/supabase **Description:** Understand how the managed Supabase project is created and what Cofounder configures automatically. ## Supabase During onboarding, Cofounder sets up a managed Supabase backend for the workspace. That gives the workspace a production setup and a staging setup for app work. ## Role Supabase is the managed backend for the app. - it powers the database - it handles auth - it gives the workspace a production backend and a staging backend ## What Cofounder Configures After setup, Cofounder configures Supabase for the app. That includes: - the app site URL - auth redirect URLs - the staging auth redirect URL Cofounder also connects the app Vercel project to the managed Supabase backend. ## How Supabase Connects To The Rest Of The Stack Supabase is wired into the managed app setup, auth configuration, and later domain/email setup. When a domain is assigned, Cofounder updates the managed Supabase auth config so the site URL and redirect URLs match the domain. ## Import Your Own Supabase If you already have a Supabase project, Cofounder can import it into the workspace. You can connect your Supabase account, choose the project, and map production and staging. If your project already has both environments, you can map them directly. If not, you can import production first and add staging later. If branch creation is available, Cofounder can also create a persistent staging branch for you. ## Next Steps - [Migrations](/managed-services/migrations) - [Postmark](/managed-services/postmark) - [Managed Services](/managed-services/overview) --- ## Vercel **URL:** https://docs.cto.cofounder.co/managed-services/vercel **Description:** Understand how managed Vercel projects are created during onboarding. ## Vercel During onboarding, Cofounder creates two managed Vercel projects: - one for the **app** - one for **marketing** Each project is linked to its corresponding managed GitHub repository. ## Role Vercel is where the app and marketing site get deployed. - the **app** project runs the product - the **marketing** project runs the site and launch surface - staging environments give the workspace a separate place to test changes ## What Cofounder Sets Up For each managed project, Cofounder: - links the GitHub repository - sets the production branch - creates a staging environment ## What Else Gets Synced To Vercel Managed Vercel projects are where Cofounder pushes: - Supabase environment variables for the app - Postmark environment variables for email The onboarding flow also configures automation access on the managed Vercel projects so agent-driven deployment workflows can run. ## Next Steps - [Supabase](/managed-services/supabase) - [Managed Services](/managed-services/overview) --- ## Environments **URL:** https://docs.cto.cofounder.co/publishing/environments **Description:** Understand how staging and production work for publishing. ## Environments During onboarding, Cofounder sets up staging and production for the managed app stack. Staging is where changes get reviewed and tested before they go live. Production is what powers the live app. ## Staging And Production For the app: - **GitHub** uses `main` for staging work and `prod` for production - **Vercel** has a staging environment and a production deployment - **Supabase** has a staging backend and a production backend For marketing: - **GitHub** uses `main` for staging work and `prod` for production - **Vercel** has a staging environment and a production deployment ## How They Link Together For app publishing: - code changes live on `main` - Vercel uses the staging setup for review - the app can run against the staging Supabase backend After publish: - the code is on `prod` - Vercel serves the live production app - the live app continues running against the production Supabase backend Marketing publishing follows the same GitHub and Vercel flow, without the managed Supabase backend. ## Next Steps - [Publishing](/publishing/overview) - [Managed Services](/managed-services/overview) --- ## Publishing **URL:** https://docs.cto.cofounder.co/publishing/overview **Description:** Understand how publishing works across GitHub, Vercel, and Supabase. ## Publishing Publishing is how changes move from staging to the live app or website. You can publish from the publish button in Canvas, or ask **Cofounder** to publish for you. In either case, Cofounder runs the publish flow for the app or marketing repository you selected. ## How Publishing Works When you publish, Cofounder creates or reuses a GitHub pull request from `main` to `prod`. That pull request is the publish step. It gives you one place to review status, checks, and whether the selected target is ready to go live. Once that pull request is merged: - the `prod` branch becomes the current production branch - Vercel updates the live production deployment for that target - the live app or website reflects the published changes ## Environments Publishing uses the staging and production environments that Cofounder sets up during onboarding. ## Next Steps - [Environments](/publishing/environments) - [Migrations](/managed-services/migrations) - [Managed Services](/managed-services/overview) - [GitHub](/managed-services/github) - [Vercel](/managed-services/vercel) --- ## AI Settings **URL:** https://docs.cto.cofounder.co/settings/ai-settings **Description:** Set global AI behavior, choose models, and configure coding and browser agent settings. ## AI Settings Use **Settings > AI Settings** to configure how Cofounder behaves across the workspace. ## What You Can Set This page includes: - auto-merge for PRs created by coding agents - suggested task generation - global prompt personalization - model selection - browser agent test credentials - coding model provider credentials ## Global Prompt Personalization You can add global instructions that should apply across chats and agents. Use this for things like tone, formatting preferences, review preferences, or how you want assumptions handled. ## Model Selection You can choose which models power the main agent experiences in the workspace. That includes the main conversation flow, the coding path, and the browser agent path. ## Browser Agent Credentials You can add credentials for the **Browser Agent** to use when testing the app. Those credentials are meant for app testing only. ## Coding Model Providers This page also lets you connect coding-specific providers such as **Codex** and **Kimi Code**. Those credentials are only used by the coding subagent. ## Related Pages - [Secrets](/settings/env-files-and-secrets) - [Workspace](/workspace/canvas) --- ## Domains **URL:** https://docs.cto.cofounder.co/settings/domains **Description:** Buy domains from Cofounder, manage DNS and nameservers, and assign domains to your app and email setup. ## Domains You can manage domains directly from Cofounder. From this page, you can: - search for domains - buy a domain from the site - import an existing domain - transfer a domain in - view domains your org already owns - edit DNS records - update nameservers - manage auto-renew ## Propagation Takes Time After you buy a domain or change nameservers, it can take a while for DNS and nameserver changes to propagate. Expect that to take anywhere from a few minutes to a few hours. During that window, parts of the setup may still show as pending while providers catch up. ## Assigning A Domain When you assign a domain, Cofounder wires it into the managed app and marketing setup created during onboarding. That assignment sets up: - the apex domain on the managed marketing project - `staging.` on the managed marketing staging environment - `app.` on the managed app project - `staging.app.` on the managed app staging environment It also updates the managed Supabase auth configuration so the app site URL and auth redirect URLs match the assigned domain. The same assignment also registers the domain with Postmark and prepares the DNS records needed for email sending. ## Inbox Domains Your domains can also be used for agent inboxes. In `Settings > Inbox`, you can choose which of your domains should be available as inbox domains for agents. Once a domain is ready there, you can assign inbox addresses to agents on that domain. ## Email Sending With Postmark Assigned domains are also used for transactional email through Postmark. When the sending domain verifies, Cofounder turns on Postmark-backed SMTP for the managed Supabase projects. It also syncs the Postmark configuration into the managed Vercel projects, including: - the Postmark server token - the Postmark server ID - the message stream IDs - the default from address If the domain is using managed Vercel nameservers, Cofounder can also auto-create the Postmark DNS records. Otherwise, Cofounder shows the records you need to add manually. ## Related Pages - [Inbox](/settings/inbox) - [Secrets](/settings/env-files-and-secrets) - [Integrations Overview](/integrations/overview) --- ## Secrets **URL:** https://docs.cto.cofounder.co/settings/env-files-and-secrets **Description:** Upload secrets for your app, choose which Vercel projects and environments to sync them to, and make them available to agents. ## Secrets Use this page to upload secrets for your app. When you add a secret, you can choose which **Vercel** projects and environments it should sync to. You can also choose to make a secret available to agents. Secrets made available to agents are accessible inside the agent sandbox. ## What To Set - add the secret value - choose the Vercel projects it should sync to - choose the environments it should sync to - decide whether agents should be able to use it in their sandbox ## Related Pages - [Domains](/settings/domains) - [Integrations Overview](/integrations/overview) --- ## Inbox **URL:** https://docs.cto.cofounder.co/settings/inbox **Description:** Set up Agentmail inbox domains, provision inboxes for agents, and let agents work over email. ## Inbox Use **Settings > Inbox** to give custom agents their own email addresses. This setup uses **Agentmail**. ## Start With A Domain Before you can provision an agent inbox, you need a domain first. Start in **Settings > Domains** to buy a domain from Cofounder, import one, or transfer one in. After that, go to **Settings > Inbox** and choose which domain should be used for agent inboxes. ## Inbox Domain Setup Takes Time Inbox domain setup is not instant. After domain or nameserver changes, Agentmail still needs time to provision and verify the inbox domain. During that window, the inbox domain can show as pending or still checking setup. ## Provision An Inbox For An Agent Once an inbox domain is ready, you can provision an inbox for a custom agent. In **Settings > Inbox**, pick the agent, choose the inbox-ready domain, set the inbox handle, and provision the inbox. That gives the agent its own email address on your domain. ## What Happens After Provisioning When an inbox is provisioned for an agent: - Cofounder creates the inbox for that agent - the agent automatically gets an Agentmail email trigger for new incoming mail - the agent can send and receive email through that inbox You can still change the agent's trigger behavior later from that agent's schedules and triggers setup. ## What Inbox Settings Control Inbox settings let you manage: - which domains are available for agent inboxes - which agent gets which inbox address - the inbox handle and display name - whether that inbox is enabled Disabled inboxes still exist, but they stop processing incoming email. ## Related Pages - [Domains](/settings/domains) - [Custom Agents](/agents/custom-agents) --- ## Canvas **URL:** https://docs.cto.cofounder.co/workspace/canvas **Description:** Use the canvas as the live workspace for tasks, agents, reviews, and related work. ## What Canvas Is Canvas is the main operating surface for Cofounder. It is the default landing page for an organization and the fastest way to understand what is active, what is blocked, and what should happen next. ## What You Can See On The Canvas Depending on what is running, the canvas can show: - active tasks - departments - work waiting on review ## Using Canvas ### Launch work Start a new task from the canvas and assign it to an agent. ### Work at the department level The current canvas also supports department-oriented views. ### Review live work If a plan or tool action needs attention, the canvas is where that review often becomes visible. ## Next Steps - [Previews And Feedback](/workspace/previews-and-feedback) - [Tech Tree](/workspace/tech-tree) - [Departments](/workspace/departments) - [Agents Overview](/agents/overview) --- ## Departments **URL:** https://docs.cto.cofounder.co/workspace/departments **Description:** Understand the departments in Cofounder, which default agents live in them, and what each department contains. ## Departments Each department owns a part of the company and groups the agents, context, rules, tasks, and artifacts for that area. ## After Onboarding After onboarding, your workspace is seeded with the main departments the company runs through. The day-to-day departments are: - **Engineering** for app, product, infrastructure, security, and payments work - **Sales** for go-to-market and customer-facing revenue work - **Marketing** for SEO and marketing-site work - **Ops** for operational workflows and recurring reporting - **Finance** for billing, collections, and finance workflows - **My Agents** for agents you create yourself ## Default Agents By Department The default agent setup maps into departments like this: - **Engineering**: `Engineer`, `Security Engineer`, `Infra Agent`, `Payments Agent` - **Sales**: `GTM Agent`, `Support Agent` - **Marketing**: `SEO Agent` - **Ops**: `Ops Agent` - **Finance**: `Finance Agent` - **My Agents**: custom agents you create, plus uncategorized agents ## Inside A Department A department contains: - **Agents** for the work that belongs in that lane - **Tasks** for the active and completed work tied to those agents - **Department Rules** for instructions that should apply across that department - **Department Context** for durable background information that agents in that department should share - **Artifacts/Files** for outputs and working files created by that department's work Files in the Library still need a department association, even though every agent can access every Library file. The department acts as a routing hint, not an access boundary. ## Department Rules Department rules are for instructions that should apply to every agent in that department. Examples: - how the department should prioritize work - what quality bar matters - what to avoid - what counts as done ## Department Context Department context is for background information that should be shared across agents in that department. Examples: - product constraints for Engineering - audience and positioning notes for Sales or Marketing - reporting definitions for Ops - billing and close process notes for Finance ## My Agents `My Agents` is the catch-all department for agents you create yourself. ## Next Steps - [Library](/workspace/library) - [Canvas](/workspace/canvas) - [Agents Overview](/agents/overview) - [Rules And Skills](/agents/rules-and-skills) --- ## Library **URL:** https://docs.cto.cofounder.co/workspace/library **Description:** Use the Library tab to upload, browse, and share files across all agents in the workspace. ## What The Library Is The Library is the shared file system for your workspace. Every agent can access every file in the Library. That makes it the default place for documents, uploads, generated files, and other reference material that should stay available across tasks. ## How Departments Work In The Library Every file in the Library must be associated with a department. That department does not limit access. All agents can still read the file. Instead, the department acts as a hint about which lane of work the file is most closely related to. For example, a pricing model might live under Finance, while a launch brief might live under Marketing. ## What Users Can Do In The Library Tab In the Library tab, users can: - upload files into the shared library - view all files currently in the library - pin important files so they stay surfaced at the top of the file list for that file's department - use department association to understand which files are most relevant to which kind of work ## Pinned Files Pinning a file in the Library tab keeps that file at the top of the list for its department. This is a visibility feature, not an access-control feature. Pinned files are still regular Library files. All agents can still access them, and the file still belongs to the same department as before. Pinning simply makes the file easier to find when someone is browsing that department's files. This is useful for files that people need to come back to often, such as: - core strategy docs - recurring templates - team reference material - important spreadsheets - current working briefs If a department has multiple pinned files, they appear before the department's unpinned files. ## What Agents Do With Library Files Agents can use Library files as shared context across the workspace. Any file an agent creates should be automatically saved to the Library, so it stays available for future work and for other agents that may need it later. That means the Library becomes the durable record for generated outputs like reports, docs, exports, plans, and other working files. ## Why This Matters The Library keeps workspace knowledge from getting trapped inside one task or one agent. Because every agent can access the same shared file system, work can move between departments without losing the files it depends on. ## Next Steps - [Departments](/workspace/departments) - [Canvas](/workspace/canvas) - [Agents Overview](/agents/overview) --- ## Previews And Feedback **URL:** https://docs.cto.cofounder.co/workspace/previews-and-feedback **Description:** Review PR previews in the workspace and send feedback back to agents. ## Previews And Feedback When an agent puts up a PR, Cofounder can show the preview right in the workspace. This gives you a faster way to review what changed without leaving Canvas. ## What The Preview Is For engineering work, the preview is the staged version of the PR. You can review the app or site as it currently exists in that branch before deciding what should happen next. ## Agentation Previews also support [**Agentation**](https://www.agentation.com/). That is the feedback layer attached to the preview, so you can comment directly on what you are seeing. ## Adding Feedback Use the Agentation bar in the bottom right of the preview to start annotating. From there, you can leave feedback on the UI and point to the part of the page you want changed. ## How Feedback Gets Worked On That feedback can be handed back to agents as follow-up work. In practice, that means you can review the preview, leave comments, and have an agent keep working from that feedback instead of starting over in a separate flow. ## How To Use It This works best when: - an Engineer agent has already put up a PR - you want to review the result in the preview - you want to leave direct feedback on the UI - you want the agent to keep iterating on those changes ## Next Steps - [Canvas](/workspace/canvas) - [Tech Tree](/workspace/tech-tree) - [Publishing](/publishing/overview) --- ## Tech Tree **URL:** https://docs.cto.cofounder.co/workspace/tech-tree **Description:** Use the Tech Tree as a guide for moving through Cofounder and building out your business. ## Tech Tree The Tech Tree is a guide for moving through Cofounder's different features and building out your business. It gives the workspace a structured path instead of a blank starting point. ## What It Has The Tech Tree is organized into: - **Stages** like idea, foundation, build, launch, and growth - **Tracks** across areas like product, engineering, design, research, operations, revenue, and support - **Nodes** for specific steps in the journey ## Node Status Nodes can show up as: - **Available** when you can work on them now - **In Progress** when work for that step is already underway - **Completed** when Cofounder sees that the step has been finished - **Locked** when another step still needs to happen first ## Kicking Off Work You can open the Tech Tree from Canvas. For steps that are agent-backed, you can launch the work directly from the Tech Tree and Cofounder will start the task with the right seeded agent. Some steps are not agent runs. Those can be manual actions, approvals, or system-managed steps. ## How Items Get Checked Off Tech Tree items get checked off as Cofounder sees the workspace change. That can include things like: - completed tasks - approved work - created artifacts - connected integrations - managed infrastructure or configuration being set up As that evidence appears, nodes move forward from locked or available to in progress and completed. ## How To Use It The Tech Tree is useful when you want a clearer sense of what to do next across both the product and the business. It also feeds suggested next steps, so Cofounder can point you toward the next available node instead of making you figure it out from scratch. ## Next Steps - [Canvas](/workspace/canvas) - [Departments](/workspace/departments) - [Agents Overview](/agents/overview) --- ## Links - [Support](mailto:support@generalintelligencecompany.com)