# 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.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 Marketing Agent that has learned how you want go-to-market work handled, 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 ## Docs Access Cofounder has access to all of these docs. ## Explore The Product --- ## Custom Agents **URL:** https://docs.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. 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 The agent editor lets you configure the agent's main working contract. Depending on the agent, you can set: - the agent name - custom instructions - skills - connected apps and integrations - department ownership - scheduled tasks ### Update an agent from chat You can ask an agent to update its own instructions, integrations, skills, or routines. User-created and cloned agents can also change departments. Default system agents keep their assigned departments. For example: > Update your instructions so you always include a launch checklist at the end of campaign plans. The agent applies supported configuration changes to itself. For broader company preferences or changes that belong to another agent, use Cofounder or the relevant agent editor instead. ### 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 ### Routines And Scheduled Tasks Routines are repeating jobs for an agent. Use a routine when the same agent should check in on a schedule, such as every morning, every weekday, or every week. One agent can have multiple routines. For example, the same operations agent might run a daily status update, a weekly metrics review, and a monthly cleanup checklist. Each routine can have its own: - title - instructions - cadence - optional criteria for when it should actually run - last result summary - next focus - enabled or paused state Agents can suggest routines when they notice work that repeats, but they should ask before creating or changing one. You can also manage routines yourself from the agent editor. You can add a routine, edit it, pause it, resume it, delete it, or run it once. If a routine has criteria, **Check now** checks whether there is something useful to do before starting the agent. Use separate routines when the timing, instructions, criteria, or expected output are different, even if the same agent should do the work. ## Next Steps - [Agents Overview](/agents/overview) - [Skills](/agents/skills) - [Integrations Overview](/integrations/overview) --- ## Design Agent **URL:** https://docs.cofounder.co/agents/design-agent **Description:** Use the Design Agent for brand systems, visual assets, decks, email templates, and UI kits. ## What The Design Agent Is For The Design Agent owns brand identity, visual systems, decks, email templates, and UI kits. Use it when you need design output that should follow the company's brand system rather than a one-off visual draft. Good Design Agent tasks include: - logo directions after brand setup is locked - branded pitch decks and internal decks - email templates - UI kits, component guidance, and design tokens - visual system refinements - brand-aligned image directions and asset sets For campaign strategy, messaging, naming, or marketing assets, use the **Marketing Agent**. For implementation-heavy UI changes in the app repo, use the **Engineer**. ## How To Start Open **Canvas**, choose **Design Agent**, and describe the asset or system you want. Strong requests include the intended audience, format, brand constraints, and where the output should be used: - `Create logo directions from the locked brand kit.` - `Create a branded pitch deck for seed investors.` - `Create three email templates for onboarding, activation, and renewal.` - `Generate a UI kit with tokens, component rules, and examples.` - `Refine the brand system for a more enterprise-facing sales motion.` ## What It Uses When available, the Design Agent inspects the pinned locked brand-kit image first and treats it as the primary brand source. Imported or manually authored `DESIGN.md` files and other Library artifacts remain secondary guidance. That keeps new assets aligned with the current visual system instead of restarting brand work from scratch. ## What It Creates Common outputs include: - logo direction notes and visual options - deck artifacts - email template artifacts - UI kit guidance - design-token recommendations - component examples and usage rules - image directions or generated visuals Generated files and artifacts should land in the **Library** so the team can review and reuse them. ## Review Before Using Externally Review brand and design assets before sending them to customers, investors, prospects, or production channels. Check that the work matches the current brand system, uses the right claims and numbers, and fits the audience before publishing or sharing. ## Next Steps - [Library](/workspace/library) - [Marketing Agent](/agents/marketing-agent) - [Engineer Agent](/agents/engineer-agent) - [Agents Overview](/agents/overview) --- ## Engineer Agent **URL:** https://docs.cofounder.co/agents/engineer-agent **Description:** Use the Engineer for product code, app changes, debugging, PRs, and local verification. ## What The Engineer Is For The Engineer owns product and app implementation work. Use it when the task needs code changes, repository investigation, debugging, tests, migrations, previews, or a pull request. Good Engineer tasks include: - fixing bugs in app or backend flows - building product features - changing UI, routing, APIs, jobs, or data flows - adding or updating database migrations - debugging failed previews, builds, tests, or deploys - implementing Stripe, billing, checkout, subscriptions, or webhooks - making technical SEO or site changes that require repository edits For campaign strategy, naming, content, or creative assets, use the **Marketing Agent**. For brand systems, decks, email templates, or UI kits, use the **Design Agent**. For ICP, outbound, customer development, or pipeline work, use the **Sales Agent**. ## How To Start Open **Canvas**, choose **Engineer**, and describe the product or code outcome you want. Strong requests include the expected behavior, affected area, repo context, constraints, and verification you want: - `Fix the checkout error when a user changes plans. Add tests and open a PR.` - `Add a settings toggle for workspace notifications and verify it locally.` - `Debug why the preview build is failing and send the smallest safe fix.` - `Add the Supabase migration for saved reports, then update the app UI.` - `Implement Stripe checkout for the new plan and verify the happy path.` ## What It Does The Engineer can inspect the repository, change files, run commands, run tests, start the app locally, use local Supabase, and open a PR when the work is ready. For user-facing changes, ask it to verify the affected flow in the sandbox before handing the work back. The Engineer should report what it tested, what passed, and any remaining manual review needed. ## Current App Stack Support The managed app platform currently works best for **Next.js** apps. The app repository, Vercel previews, Supabase wiring, publishing flow, and sandbox browser verification are primarily built around that path. Mobile app functionality is currently being implemented through **React Native** and **Expo** integration. For now, mobile app requests should be treated as in-progress platform support rather than the same default flow as Next.js app work. ## Testing Changes Locally The Engineer can test app changes in a sandbox before you review a PR. That means it can make a change, run the app locally, open the app in a browser, and check the affected flow before handing the work back to you. This is especially useful for: - product flows that need clicking through - UI changes that should be checked visually - forms, dashboards, and authenticated screens - database-backed features - Supabase migrations or schema changes For browser testing, the Engineer opens the local version of the app inside its sandbox and interacts with it like a user. It can load changed pages, click through flows, fill out forms, check desktop and mobile layouts, and fix issues it finds before asking you to review. You can ask for this directly: - `Test the signup flow in the sandbox before opening the PR.` - `Click through the dashboard and make sure the new empty state looks right.` - `Check this change on desktop and mobile.` - `Run the app locally and include screenshots of the tested flow.` If the app requires a login, use a dedicated test account instead of your personal account. When browser verification hits a login form and no saved credentials match, the Engineer can prompt you in the task to **Save Credentials**. That prompt stores the email or username and password securely for browser automation on that site. You can skip the prompt if you want the Engineer to create a local-only test user or seed data instead. If browser verification runs into a login wall, missing account, missing organization, or empty test data, the Engineer should keep going when it can do so safely. It should use saved browser credentials, start local Supabase, create a local-only test user or seed data, and retry the browser flow instead of stopping at the first setup issue. ## Local Supabase Verification When a change depends on the database, auth, or storage, the Engineer can run Supabase locally in the sandbox. Local Supabase gives the Engineer a safe backend for testing app behavior without touching production data. The Engineer can use it to: - apply and test migrations - confirm new tables or columns work with the app - create test data - test login and auth-dependent flows - verify database-backed UI before the PR is ready for review For schema changes, the Engineer should still put migrations in the app repo and send them through the normal review and publishing flow. For authenticated flows, ask the Engineer to create a local-only test user before browser testing. If the agent changes `seed.sql`, it should run `supabase db reset` against the local Supabase stack before retrying the browser flow so the running database sees the new seed data. You can copy and paste this: ```text Set up a local-only test user for this app using seed.sql. Then run supabase db reset locally so the seed is applied. Run the app with local Supabase and use that test user to browser-test the changed flow end to end. Do not use my personal account. Use non-sensitive test data, and include the local test login plus what you verified in your final summary or PR notes. ``` ## Database Viewer The database viewer lives on Canvas as the **Database** artifact in the **Engineering** workspace. Use it to browse tables in the managed Supabase project from inside Cofounder. It also lets you upload a CSV file directly into one of those tables without leaving the Engineering workspace. The Database artifact lets you: - browse tables in the managed Supabase project - open a table and see its records - upload a CSV file into the currently opened table To upload a CSV: 1. Open **Canvas**. 2. Open the **Engineering** workspace. 3. Open the **Database** artifact or **Database** tab. 4. Pick a schema and open the table you want to import into. 5. In the table view, click **Upload CSV** in the header. The import flow walks through file selection, header mapping review, and import. Rows are appended to the table. Existing rows are not touched, and the import does not truncate or replace data. CSV imports expect a standard `.csv` file with a header row. Headers must match columns on the target table, and the importer rejects unsupported mappings such as generated columns, unsupported identity columns, array columns, unknown columns, or missing required columns. Empty cells for non-text columns are treated as "not provided", so column defaults and nulls still apply. If some rows fail validation, Cofounder reports row-level errors so you can fix the CSV and run the import again. ## Previews And Feedback When the Engineer is ready for review, Cofounder can show a preview right in the workspace. The preview is the review surface for the finished work. You can open the app or site as it exists for that change before deciding what should happen next. Previews also support [**Agentation**](https://www.agentation.com/). Use the Agentation bar in the bottom right of the preview to leave feedback directly on the UI and point to the part of the page you want changed. That feedback can be handed back to the Engineer as follow-up work. In practice, you can review the preview, leave comments, and have the Engineer keep working from that feedback instead of starting over in a separate flow. Markdown artifacts also support direct comments. Open a Markdown artifact, switch between **Preview** and **Source** when needed, select text or comment on the whole document, then send the comments to the artifact's chat. Cofounder keeps the selected quote, surrounding context, and current version with the message so the Engineer can make a scoped edit or reply when the request is ambiguous. Before a change reaches shared staging, the Engineer can also run the app in a sandbox and test the affected flow in a browser. For database-backed changes, it can use local Supabase to verify the app behavior before asking you to review. ## Requesting a deploy and staging When the work is ready, the Engineer can request a deploy. That handoff: - prepares the finished work for the app or marketing target - asks you to approve **Publish to Staging** - ships the change to staging on approval That is the publish-to-staging step. Production still uses the workspace **Publish** flow after staging looks good. See [Requesting a deploy](/publishing/request-deploy) and [Publishing](/publishing/overview). ## Plan First When The Change Is Risky Choose **Plan** when the engineering change is large, risky, or touches several systems. Plan mode is useful for: - schema or migration work - auth, billing, permissions, or security-sensitive changes - work across frontend, backend, and infrastructure - unclear bugs where the fix path is not obvious After you approve the plan, the agent can continue into implementation. ## Review Before Shipping Review the preview, migration notes, and test notes before approving staging or production. Pay extra attention to: - database migrations and data changes - auth, billing, secrets, and permissions - user-visible UI changes - external service changes - tests the agent could not run ## Next Steps - [Requesting a deploy](/publishing/request-deploy) - [Publishing](/publishing/overview) - [Migrations](/managed-services/migrations) - [Agents Overview](/agents/overview) --- ## Marketing Agent **URL:** https://docs.cofounder.co/agents/marketing-agent **Description:** Use the Marketing Agent for campaigns, positioning, creative assets, launches, and marketing-site planning. ## What The Marketing Agent Is For The Marketing Agent owns campaign, content, creative, positioning, growth, marketing-site work, and the task work inside the [Marketing Department](/workspace/marketing-department). Use it when you want to turn a marketing question into durable outputs you can review, reuse, and share across the workspace. Good Marketing Agent tasks include: - launch plans and campaign briefs - positioning, messaging, and naming work - channel plans, launch calendars, and content systems - landing-page briefs and marketing-site recommendations - marketing decks, one-pagers, images, social assets, audio, and short videos - measurement plans and SEO briefs For sales pipeline, outbound, ICP, or customer-development work, use the [Sales Agent](/agents/sales-agent). For brand systems, decks, email templates, or UI kits, use the [Design Agent](/agents/design-agent). For broad app, backend, infrastructure, or risky code changes, use the [Engineer](/agents/engineer-agent). ## How To Start For a one-off marketing task, open **Canvas**, choose **Marketing Agent**, and ask for the outcome you want. For an ongoing marketing loop, open the [Marketing Department](/workspace/marketing-department) and complete setup so Cofounder can recommend channels, activate Marketing Missions, set operating intensity, and create the first task. Strong requests include the audience, goal, channel, source context, and review format: - `Create a launch campaign for our new team inbox feature. Audience: seed-stage founders. Include the core message, channel plan, launch calendar, and first-pass copy.` - `Build an investor update deck from last month's metrics. Keep it board-ready and easy to revise.` - `Generate three hero image directions for our homepage, then recommend the strongest one for the current positioning.` - `Create a 15-second launch teaser for this release.` - `Turn this campaign brief into an SEO brief with query themes, target pages, proof points, and measurement expectations.` ## What The Marketing Agent Can Generate The Marketing Agent is not limited to planning. It can also create marketing assets and save useful outputs to the **Library**. Common outputs include: - **HTML** decks, presentations, mini-sites, and rich one-pagers that render directly in Cofounder for review and iteration - standalone marketing images generated with **GPT Image 2**, **Nano Banana**, or **Gemini** for hero art, ad creative, and editorial illustrations in square, landscape, or portrait formats - **Gamma** assets only when you specifically need a Gamma-native template, share link, or fallback export path - original campaign music with **ACE-Step** for jingles, sonic logos, intro/outro cues, and background music beds when the ACE-Step runtime is configured - short AI-generated videos with **Seedance** for teaser-style marketing assets and launch visuals - campaign briefs, messaging matrices, channel plans, launch calendars, content systems, social bundles, Marketing Mission operating documents, measurement plans, and SEO briefs - publishing-ready drafts when the right integrations are connected, while keeping live sends and posts review-gated Generated files and artifacts should land in the **Library** so you can review them, reuse them, and bring them into later agent tasks. These are best used when you already know the outcome you want, even if the first draft still needs iteration. Example requests: - `Build me an HTML investor update deck from last month's metrics.` - `Generate a landscape hero image for our landing page, minimal style.` - `Sketch three variants of a pricing page for me.` - `Create an original sonic logo and intro music bed for this launch.` - `Create a short teaser video for this launch.` ## Ask For The Outcome Ask for the result you want, not the tool you think should create it. Cofounder will choose the best available format for the job and save reviewable work in the **Library**. You can still ask for a specific format when it matters, such as a deck, one-pager, image set, social draft pack, or launch teaser. Good format-specific requests: - `Build an investor update deck from these metrics.` - `Create a 10-slide launch narrative with speaker notes.` - `Turn this campaign plan into a one-page internal brief.` ## How It Works The Marketing Agent starts from the context available in your workspace, then creates the most useful next artifact for the request. Inside the Marketing Department, the agent can also work from the department operating plan: selected channels, active Missions, cadence/intensity, prior drafts, approval history, and analytics signals. That might be a strategy brief, a draft pack, a visual direction, a campaign plan, or a brief for another agent. Not every workspace has every integration connected, so the agent should use what is available and make any missing context clear. ## Review Before Publishing The Marketing Agent can prepare assets and publishing drafts, but you should review anything that leaves the workspace. Review before: - sending email campaigns - scheduling or publishing social posts to one or more connected accounts - changing a live marketing site - using generated claims, customer quotes, pricing, or performance numbers - sharing decks or assets with external audiences A single social card can target multiple connected accounts. Cofounder tracks each destination separately, so review the per-account result before treating the publish as fully done. See [Marketing Department](/workspace/marketing-department#publish-to-multiple-accounts). This review step is part of the normal workflow. It lets the agent move quickly while keeping final judgment with the team. ## Next Steps - [Marketing Department](/workspace/marketing-department) - [Library](/workspace/library) - [Quickstart](/get-started/quickstart) - [Engineer Agent](/agents/engineer-agent) - [Design Agent](/agents/design-agent) - [Sales Agent](/agents/sales-agent) - [Agents Overview](/agents/overview) - [SEO Agent And Departments](/workspace/departments) --- ## Agents Overview **URL:** https://docs.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 - **Integrations** that define which tools and systems it can use - **Skills** that add reusable guidance for a specific kind of work - **Department** that determines which lane of the company the agent belongs to An engineering agent and a Marketing Agent should have different instructions, different tools, different skills, and live in different departments. ## Default Agents After onboarding, Cofounder is available from the side panel and your workspace is seeded with agents for the main operating areas. The seeded default agents are: - **Operations Agent** - **Engineer** - **Marketing Agent** - **Design Agent** - **Sales Agent** - **Support Agent** - **Ops Agent** - **Finance Agent** ## Default Agent Roles - **Cofounder** is the top-level workspace agent in the side panel - **Operations Agent** handles broad tasks and routes work to the right tools or agents - **Engineer** is for product and app work - **Marketing Agent** is for launches, messaging, campaigns, and marketing asset generation such as HTML decks, images, UI concepts, music, and short videos - **Design Agent** is for brand systems, decks, email templates, visual assets, and UI kits - **Sales Agent** is for ICP, outbound, customer development, pipeline, and GTM execution - **Support Agent** is for support replies, ticket triage, and support workflow improvements - **Ops Agent** is for reconciliation, recurring reporting, and operational cleanup - **Finance Agent** is for collections, close support, billing inbox triage, and finance reporting Cofounder sits above that layer as the workspace-level agent, while the seeded agents are 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 ## Skills On Default Agents Default agents keep the built-in skills that ship with them. You can still open a default agent and use **Edit skills** to attach extra uploaded or custom skills for that agent. Those added skills can be removed later without changing the agent's built-in skill set. Use this when a default agent needs one more playbook for your company, but you do not want to create a separate custom agent yet. ## 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 - [Engineer Agent](/agents/engineer-agent) - [Marketing Agent](/agents/marketing-agent) - [Design Agent](/agents/design-agent) - [Sales Agent](/agents/sales-agent) - [Departments](/workspace/departments) - [Skills](/agents/skills) - [Canvas](/workspace/canvas) --- ## Sales Agent **URL:** https://docs.cofounder.co/agents/sales-agent **Description:** Use the Sales Agent for ICP, outbound, customer development, pipeline, and GTM execution. ## What The Sales Agent Is For The Sales Agent owns sales and go-to-market execution. Use it when the task involves ICP, target accounts, customer development, outbound, qualified pipeline, follow-up, consult calls, pitches, negotiation, or account handoff. Good Sales Agent tasks include: - defining positioning from market and competitor research - finding qualified accounts and buyer contacts - preparing outbound domains and inbox setup - drafting and sending approved cold outreach - scheduling consult calls - qualifying opportunities - reviewing consult notes and pitch feedback - preparing negotiation or close plans - onboarding a newly closed account For campaign creative, brand direction, content, or marketing-site work, use the **Marketing Agent**. For technical SEO or site implementation, use the **Engineer**. ## How To Start Open **Canvas**, choose **Sales Agent**, and describe the sales outcome you want. Strong requests include the target segment, source context, desired CRM updates, and whether external outreach should be drafted or sent: - `Define our ICP and positioning for mid-market fintech teams.` - `Gather qualified prospects for our ICP and save reliable account notes.` - `Draft cold outreach for these accounts, but do not send until I approve.` - `Review this consult transcript and update the opportunity next steps.` - `Prepare negotiation options for this deal.` ## How It Works The Sales Agent starts from existing product, company, research, CRM, contact, email, calendar, and task context when those sources are connected. It should keep sales records current as work happens. That includes Accounts, Contacts, Opportunities, and Activity when reliable facts, owners, next steps, or follow-up history are available. The agent should not invent accounts, contacts, replies, pipeline status, or customer evidence. ## Review Before External Actions External actions stay review-gated. Review before the agent: - sends cold outreach or follow-up - changes calendar events - updates important opportunity status - marks a deal as closed - commits to pricing, scope, or customer promises The Sales Agent can draft the message, sequence, meeting plan, or CRM update first. Approve the action when you are ready for it to happen. ## Next Steps - [Marketing Agent](/agents/marketing-agent) - [Agents Overview](/agents/overview) - [Company](/workspace/company) - [Library](/workspace/library) --- ## Skills **URL:** https://docs.cofounder.co/agents/skills **Description:** Create reusable guidance packages and attach them to your agents. 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. You can also manage skills from an agent panel or agent editor: - custom agents can add or remove the skills attached to them - default agents can add or remove extra uploaded skills without changing the built-in skills that ship with that default agent The **Skills** tab starts with create and import actions. If your workspace has no skills yet, Cofounder shows an empty state with those same actions. ## Use Skills In Prompts You can add a skill to a prompt by typing `/` in the prompt composer and choosing a skill from the menu. Selected skills appear inline in your message. Cofounder uses those skills as guidance for that specific request, without requiring you to edit the agent first. You can include more than one skill in the same prompt. For example: ```text /research compare these competitors, then /copywriter turn the findings into a landing page section ``` ## 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. ## Next Steps - [Agents Overview](/agents/overview) - [Custom Agents](/agents/custom-agents) - [Integrations Overview](/integrations/overview) --- ## What Happens After Onboarding **URL:** https://docs.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 ## Design Onboarding Design onboarding helps your workspace leave setup with a usable brand direction, not just a blank Design Agent. During design onboarding, you can choose a starting vibe, add reference images, describe what the brand should feel like, and generate a brand kit. You can review earlier brand-kit versions before locking one in. When the brand kit is ready, you can copy or download the brand-kit image. Cofounder saves the design context for future Design Agent work and then moves you into the first Canvas handoff. If you need to move on before brand setup is complete, you can skip design onboarding and come back to design work later. ## Current App Platform Support Today, the managed platform mainly supports web apps built with **Next.js**. That is the default path for the app repository, Vercel deployment flow, Supabase wiring, previews, publishing, and Engineer Agent verification. Mobile app functionality is currently being implemented through **React Native** and **Expo** integration. Until that support is fully available, treat mobile app builds as in-progress platform support rather than the same mature path as Next.js apps. ## Multiple Organizations Multiple organizations are available on paid subscriptions. Each organization requires its own subscription. The $15 free credit applies only to the first organization on your account. If you create or join additional organizations, those organizations do not receive a separate $15 free credit. ## 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 ## What Agents Actually Do Next Once onboarding is complete, the normal flow is: 1. Open **Canvas**. 2. Check the **Company** view to understand stack status, active agents, and any available metrics. 3. Use the **Roadmap** or suggested next tasks when you want a guided next step. 4. Go to the department that owns the job. 5. Choose the agent with the right scope. 6. Give it a concrete task. 7. Review the result from the task detail page or the Canvas attention queue, then refine the setup if needed. ## Next Steps - [Quickstart](/get-started/quickstart) - [Company](/workspace/company) - [Tasks](/workspace/tasks) - [Library](/workspace/library) - [Departments](/workspace/departments) - [Agents Overview](/agents/overview) - [Managed Services](/managed-services/overview) - [Integrations Overview](/integrations/overview) --- ## Quickstart **URL:** https://docs.cofounder.co/get-started/quickstart **Description:** Use department onboarding to start Engineering, Marketing, Sales, or Design workflows. ## Choose The Department Open **Canvas**, then choose a department workspace or open the **Roadmap** and pick an available department step. Department onboarding choices include: - **Engineering** when you want to build or change the app - **Marketing** when you want a launch plan, campaign, content, or marketing-site work - **Sales** when you want ICP, outbound, consult notes, or pipeline work - **Design** when you want brand identity, decks, email templates, or UI kits The exact label can vary by workspace, but you are looking for the onboarding task for that department, such as **Build your app**, **Run marketing campaign**, or **Send email outreach**. If you are not sure which department onboarding to start, ask Cofounder in the side panel: `Which department onboarding should I start based on our current company setup?` ## Start The Department Onboarding Task Start from the department workspace, the Roadmap step, or the **+** menu on Canvas. Attach any files the department needs and use **Auto Assign** if you want Cofounder to pick the right agent. Example requests: - **Engineering**: `Build the first version of the app flow and open a PR with a preview.` - **Marketing**: `Run the first launch campaign workflow and create the draft pack for review.` - **Sales**: `Define the ICP, find the first target accounts, and draft outreach without sending it.` - **Design**: `Set up the brand identity and save the brand kit for future work.` ## Review The Department's Output The output should match the department you chose: - **Engineering** should produce a PR, preview, test notes, or implementation plan. - **Marketing** should produce a campaign brief, draft pack, copy, or marketing artifact in the **Library**. - **Sales** should produce ICP notes, account research, outreach drafts, CRM updates, or next-step recommendations. - **Design** should produce brand assets, a brand kit, deck material, templates, or design guidance. Open the task detail page or Canvas attention queue, then approve, request changes, or ask the agent to keep going. ## Move To The Next Department When you are ready to continue, go back to the **Roadmap** or **Canvas** and pick the next department. Add integrations, files, and department context as the next workflow calls for them. ## Next Steps - [Departments](/workspace/departments) - [Roadmap](/workspace/roadmap) - [Agents Overview](/agents/overview) - [Engineer Agent](/agents/engineer-agent) - [Marketing Agent](/agents/marketing-agent) - [Sales Agent](/agents/sales-agent) - [Design Agent](/agents/design-agent) --- ## Linear **URL:** https://docs.cofounder.co/integrations/linear **Description:** Connect Linear so Cofounder can work from Linear issues and send progress back to Linear. ## What Linear Lets Cofounder Do Adding the Linear integration lets Cofounder work from the issues your team already writes in Linear. Once Linear is connected, Cofounder can: - read Linear issue titles, descriptions, teams, and linked files - turn assigned Linear issues into Cofounder work - route that work to the right Cofounder agent - link Cofounder tasks back to Linear issues - send progress updates back to Linear with a link to the live Cofounder session Use Linear when your team wants to keep planning work in Linear and have Cofounder do the work. ## Assigning Linear Work To Cofounder After Linear is connected, you can send work to Cofounder from Linear by assigning or delegating a Linear issue to the Cofounder Linear agent. That issue becomes a Cofounder work request. Cofounder uses the issue title, description, links, files, and comments to understand what to do. A good Linear issue for Cofounder should include: - a clear title - what you want done - any important product, engineering, or customer context - links, screenshots, or files Cofounder should inspect - how you will know the work is done You do not need to copy the issue into Cofounder chat. Assigning the issue is enough. ## What Happens After Assignment When a Linear issue is assigned to Cofounder: 1. Linear sends the issue to Cofounder through the connected Linear integration. 2. Cofounder reads the issue and turns it into instructions for the agent. 3. Cofounder creates or reuses a session for that Linear issue. 4. Supported files from the Linear issue are copied into the agent session. 5. Cofounder routes the work to the right agent. 6. Linear gets a reply with a link to the live Cofounder session. The Linear issue stays in Linear. The Cofounder session is where the agent does the work, asks follow-up questions if needed, runs tools, writes code, creates artifacts, opens PRs, or finishes the task. ## What Shows Up In Linear Cofounder sends updates back to Linear so teammates can follow the work from the issue. Depending on the issue and task state, Cofounder can: - move the issue into an active state when work starts - add the Cofounder session as a link on the issue - post a reply with a live session link - comment when Cofounder starts work - keep the Cofounder task linked to the Linear issue This lets your team track the work in Linear while Cofounder works in the Cofounder workspace. ## Cofounder Tasks And Linear Issues Linear and Cofounder can stay linked in both directions: - Work can start in Linear and become a Cofounder task or session. - Work can start in Cofounder and link back to Linear when Linear sync is enabled. - Cofounder can create a new Linear issue when no matching issue exists. - Cofounder can reuse an existing Linear issue when it finds a clear match. This is useful when your product and engineering teams already use Linear to track work. ## When To Assign Linear Issues To Cofounder Assign work from Linear to Cofounder when: - the issue is already written in Linear - your team wants Linear to stay as the place where work is tracked - Cofounder should pick up the issue and route it to the right agent - teammates need a link from Linear to the active Cofounder session Use Cofounder chat or the Tasks canvas instead when the work starts as a conversation, needs more scoping before it becomes an issue, or is not tied to Linear. ## Next Steps - [Integrations Overview](/integrations/overview) - [Custom Agents](/agents/custom-agents) - [Roadmap](/workspace/roadmap) --- ## MCP **URL:** https://docs.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.cofounder.co/integrations/overview **Description:** Understand Cofounder's native integrations, managed app connections, and MCP server support. ## Integrations Overview Cofounder integrations let agents work with the tools your company already uses. Some integrations are connected automatically as part of the managed app setup. Others can be added from **Integrations** when you want agents to access more of your stack. ## Managed App Integrations For managed app work, Cofounder connects the core engineering stack during onboarding: - **GitHub** for app and marketing repositories, pull requests, reviews, and code changes - **Vercel** for staging and production deployments - **Supabase** for managed app databases, auth, storage, migrations, and environment wiring These are the default production and staging surfaces for Engineering work. Agents can use them to build, preview, verify, publish, and maintain the managed app without you manually wiring credentials into each task. ## Native Integrations Native integrations are first-party Cofounder connections with product-aware agent tools, approvals, and runtime handling. Cofounder supports native integrations across these areas: | Area | Native integrations | | --- | --- | | Engineering and delivery | GitHub, Vercel, Supabase, Linear, LaunchDarkly, Sentry, PagerDuty, Logfire, Datadog, Neon, Railway, Render | | Communication and support | Gmail, Google Calendar, Google Contacts, Slack, Intercom, AgentMail | | Docs, files, and knowledge | Notion, Google Docs, Google Drive, Google Slides, Airtable, Granola, Limitless | | Revenue and operations | Ramp, Loops, Metabase, Attio | | Marketing and publishing | PostHog, Google Search Console, Postiz, Social Publishing, Layers, Figma, Gamma | | Research and enrichment | Web, Apify, PhantomBuster, People Data Labs, enrichment, research workflows, stock market, weather | | Media and generation | Image generation, Canvas Video Studio, HyperFrames, Agent Media, OpenRouter Video, video post-processing, Gemini TTS, Lyria Music, ACE-Step Music, Writer, Kimi | | Developer agents and infrastructure | Codex, Claude Code, Devin, Doppler SecretOps, Composio, Zernio | Availability can vary by workspace, plan, and connected account. The **Integrations** page is the source of truth for what is connected in your workspace and which agents can use each connection. ## Examples - **Linear** lets Cofounder start or continue work from issues, route engineering tasks, and accept assigned Linear work as Cofounder tasks. See [Linear](/integrations/linear). - **Ramp** supports operations workflows such as the Roadmap's agent-guided [Incorporate LLC](/workspace/roadmap#incorporating-your-business) node. - **Notion** lets agents read pages and update existing pages in place when the task calls for changing a shared doc. - **Granola** lets agents list folders and notes, fetch meeting summaries, and include transcripts when exact wording matters. For payments, use the dedicated [Payments And Stripe](/integrations/payments-and-stripe) guide. ## MCP Servers Custom MCP servers let a workspace bring its own MCP-compatible tools into Cofounder, then choose which agents can use them. Use custom MCP servers when: - your team already has an MCP server for an internal system, private API, or specialized toolchain - the tool should be available to agents through the MCP protocol rather than a native Cofounder product workflow - you need per-agent access control over which custom tools an agent can call - the server's tools can run safely inside agent tasks and sandboxed workflows A typical custom MCP setup looks like this: 1. Open **Integrations** and go to **MCP**. 2. Add or paste an `mcp.json` configuration with an `mcpServers` object. 3. Save the configuration so Cofounder parses the servers and shows each saved MCP server. 4. Keep the servers that should be available marked as enabled. 5. Use **Agent access** to choose which agents can use each saved MCP server. 6. Ask the relevant agent to use the server's tools in a task. Exposed tools appear to agents as MCP-backed tool names such as `mcp__*`. Use native integrations when Cofounder has a purpose-built workflow for the service. Use custom MCP servers when you need to bring your own MCP tool surface into the agent runtime. ## Next Steps - [Linear](/integrations/linear) - [Payments And Stripe](/integrations/payments-and-stripe) - [MCP Toolkits](/integrations/mcp-toolkits) - [Custom Agents](/agents/custom-agents) --- ## Payments And Stripe **URL:** https://docs.cofounder.co/integrations/payments-and-stripe **Description:** Connect Stripe, sync it into the managed app, and use the Engineer Agent to add billing to your app. ## Where To Add Stripe Keys Add Stripe from **Settings > Payments**. The page shows whether the managed app is ready for payment setup. If the app has not been set up yet, Cofounder explains that payment work needs a managed Vercel product app before Stripe credentials and billing code can be installed. Org admins can add: - the Stripe test publishable key - the Stripe test secret key - the Stripe live publishable key - the Stripe live secret key Cofounder verifies the keys before treating Stripe as connected. You can add test keys, live keys, or both. Use test keys while building and checking payment flows. Add live keys when the app is ready to accept real payments. ## 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 Cofounder keeps test and live keys separate. Test keys stay out of production. Live keys sync to production only. The Payments page also shows credential slots for **Test** and **Live**. Each slot tracks whether keys, environment variables, and webhooks are present. ## Engineer Agent From **Settings > Payments**, you can kick off payment implementation with the **Engineer Agent**. The Engineer 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. If setup is blocked, the page shows the next step before the agent can safely proceed. ## 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 Engineer 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.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. ## Repository Access And Invites If you cannot open the managed repositories in GitHub, make sure your Cofounder account is signed in with GitHub or linked to the GitHub account that should receive access. Agents work through Cofounder's connected repository context. If GitHub is not connected, do not use an agent as a workaround by asking it to clone a private repo manually. Connect GitHub through the in-app sign-in or account-linking flow, then use the supported repository access flow instead. Organization admins can invite a GitHub user to the managed app and marketing repositories from **Settings > Advanced** under **Get access to managed repos**. Enter the user's GitHub username and Cofounder will send repository collaborator invites for the managed repositories. The user should then accept the GitHub invites from GitHub. ## 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 - accepting access to the managed Vercel projects - manually connecting 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. ### Why the Vercel step is separate Installing the Cofounder GitHub App gives Cofounder access to inspect and work in the repository. It does not give Vercel's GitHub integration access to that repository, and it does not change which repository the managed Vercel project is connected to. For a private repository, the guided import therefore asks you to: 1. Accept the invitation to the managed Vercel projects. 2. Make sure Vercel's GitHub integration has access to the repository. 3. Open the managed project's Git settings in Vercel. 4. Connect the exact repository selected in Cofounder. 5. Return to Cofounder and choose **Verify and finish**. Cofounder checks the live Vercel project before completing the import. The repository is not treated as imported while the project is unconnected or connected to a different repository. You can close the guided import and resume later. Use **Cancel setup** when you want Cofounder to restore the previous managed repository configuration. To switch from one imported repository to another, disconnect the current imported repository first. ## Next Steps - [Vercel](/managed-services/vercel) - [Managed Services](/managed-services/overview) --- ## Migrations **URL:** https://docs.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. Have the Engineer request a deploy so the migration work can reach staging. 3. While the handoff is open, automated checks can lint the migration files. 4. When the change reaches staging (staging publish / Publish to Staging), the staging migration path runs automatically. 5. When those changes are later published to production, the production migration path runs automatically. ## Staging And Production - shipping a migration to staging applies it to staging - publishing to production applies it to production That keeps migrations lined up with the same staging-to-production flow as the app code. Requesting a deploy is the normal agent path to staging; workspace Publish is the path to production. ## Next Steps - [Supabase](/managed-services/supabase) - [Requesting a deploy](/publishing/request-deploy) - [Publishing](/publishing/overview) - [Environments](/publishing/environments) --- ## Managed Services **URL:** https://docs.cofounder.co/managed-services/overview **Description:** Understand how managed GitHub, Vercel, and Supabase 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 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, and can request another invite later from [Settings > Advanced](/managed-services/vercel#project-access-and-invites) - **Supabase**: Cofounder manages the project for the workspace, but users are not invited into Supabase yet ## 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 ## Pages - [GitHub](/managed-services/github) - [Vercel](/managed-services/vercel) - [Supabase](/managed-services/supabase) - [Migrations](/managed-services/migrations) - [Requesting a deploy](/publishing/request-deploy) - [Publishing](/publishing/overview) --- ## Supabase **URL:** https://docs.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 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. ## Local Supabase For Agent Testing For app changes that depend on the database, auth, or storage, the Engineer agent can run Supabase locally in its sandbox. That lets the agent test migrations, create test data, and click through database-backed flows before a PR is ready for review. Local Supabase is separate from staging and production, so it is a safe place for the agent to verify behavior while it is still working. ## 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 - [Database Viewer](/agents/engineer-agent#database-viewer) - [Migrations](/managed-services/migrations) - [Testing Changes Locally](/agents/engineer-agent#testing-changes-locally) - [Managed Services](/managed-services/overview) --- ## Vercel **URL:** https://docs.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 - staging and production environment variables needed by the managed app and marketing site The onboarding flow also configures automation access on the managed Vercel projects so agent-driven deployment workflows can run. ## Project Access And Invites Cofounder will automatically invite you to the managed Vercel projects during onboarding. You will receive an email from Vercel. You can also request an email invite from **Settings > Advanced** under **Vercel Access**. Enter your email address and choose **Send invite**. You should then receive an invite. ## Bringing Your Own Repository Managed repositories created by Cofounder are connected to their Vercel projects during provisioning. Private repositories that you bring to Cofounder use a manual connection step. The guided import in **Settings > Advanced** will: 1. Send an invitation for access to the managed Vercel projects. 2. Check that the invited email has administrator access to each managed project. 3. Prepare the selected managed project, including its root directory, staging environment, and selected environment variables. 4. Open the project's Git settings so you can connect the selected GitHub repository. 5. Verify the live project connection before completing the import. The Cofounder GitHub App and Vercel's GitHub integration have separate repository permissions. If the repository does not appear in Vercel, configure Vercel's GitHub integration to allow that repository, then return to the managed project's Git settings. The import is complete when Cofounder verifies that the managed Vercel project is connected to the exact selected repository. It does not wait for a deployment to become ready, and it does not complete from a saved repository selection alone. Closing the guide preserves your progress. Explicitly cancelling restores the previous managed configuration. If an imported repository later becomes disconnected or the Vercel project points somewhere else, Cofounder shows the repository as needing link review instead of claiming the setup is healthy. ## Next Steps - [GitHub](/managed-services/github) - [Supabase](/managed-services/supabase) - [Managed Services](/managed-services/overview) --- ## Environments **URL:** https://docs.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: - **Staging** is the shared review environment for finished work - **Production** is the live customer-facing environment - the app also has a staging backend and a production backend For marketing: - **Staging** is the shared review environment for the site - **Production** is the live marketing site ## How Changes Reach Each Environment ### Staging Staging is the shared review environment. To publish agent work to staging: 1. The agent finishes work in its sandbox 2. The agent requests a deploy 3. You approve **Publish to Staging** 4. Staging / preview updates for that target For app work: - the staged app can run against the staging backend - migrations that reach staging follow the staging migration path See [Requesting a deploy](/publishing/request-deploy). ### Production Production is the live environment. To publish staging to production: 1. Use the workspace **Publish** button, or ask **Cofounder** to publish 2. Cofounder runs the production publish flow for the selected target 3. When publish completes, the live deployment updates For app work: - the live app continues running against the production backend - migrations published to production follow the production migration path See [Publishing](/publishing/overview). ## How They Link Together For app publishing: - finished agent work is reviewed into staging after the agent requests a deploy - staging is the place to confirm the change before customers see it - the staged app can run against the staging backend After production publish: - the live app or website updates - the live app continues running against the production backend Marketing publishing follows the same staging-then-production flow, without the managed app backend. ## Next Steps - [Publishing](/publishing/overview) - [Requesting a deploy](/publishing/request-deploy) - [Managed Services](/managed-services/overview) --- ## Publishing **URL:** https://docs.cofounder.co/publishing/overview **Description:** Understand how staging and production publishing work in Cofounder. ## Publishing Cofounder has two separate ship steps: 1. **Publish to staging (preview)** — put finished agent work into the shared review environment 2. **Publish to production** — promote what is already on staging to the live app or website For the staging step, the Engineer (or another coding agent) can request a deploy when the work is ready. You approve that handoff as **Publish to Staging**. For production, you (or Cofounder) use the workspace **Publish** flow. ## Staging Vs Production **Staging** is the shared place to review and test changes before customers see them. - it is the default review surface for the managed app and marketing site - it is where you check that a change looks and behaves right after an agent finishes work - for app work, it can use a separate staging backend so review does not touch live data **Production** is what real users hit. - it is the live app or website - only promote to production after staging looks good - for app work, it continues using the production backend ## The Two Steps ### 1. Publish to staging How it works at a high level: 1. An agent finishes work in its sandbox. 2. The agent requests a deploy for the app or marketing target. 3. Cofounder prepares the handoff and asks you to approve. 4. In the agent workspace, approve with **Publish to Staging** (or reject). 5. On approval, the change lands on staging. Once staging is updated: - the managed staging / preview deployment refreshes for that target - for app work, staging continues to use the staging backend - for database migrations, the staging apply path can run after the change reaches staging Requesting a deploy does not publish production. It only ships work into staging. See [Requesting a deploy](/publishing/request-deploy). ### 2. Publish to production Publishing to production 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 target you selected, and gives you a place to review readiness before the live environment updates. Once production is updated: - the live app or website reflects the published changes - for app migrations included in that publish, production migrations can run after the live promote ## What Agents Should Use | Goal | Flow | | --- | --- | | Ship finished agent work to staging | Request a deploy, then approve **Publish to Staging** | | Ship staging to production | Workspace **Publish** / ask Cofounder to publish | After finishing code changes, agents should request a deploy as the normal handoff into staging. Staging is the review step. Production is the live promote. ## Environments Publishing uses the staging and production environments that Cofounder sets up during onboarding. See [Environments](/publishing/environments). ## Next Steps - [Requesting a deploy](/publishing/request-deploy) - [Environments](/publishing/environments) - [Migrations](/managed-services/migrations) - [Managed Services](/managed-services/overview) - [Vercel](/managed-services/vercel) --- ## Requesting a deploy **URL:** https://docs.cofounder.co/publishing/request-deploy **Description:** How agents hand finished work to staging by requesting a deploy. ## Requesting a deploy When finished work is ready for shared review, the Engineer can request a deploy. That handoff is approval-gated. In the product UI the primary action is labeled **Publish to Staging**. ## What Happens When an agent requests a deploy, Cofounder: 1. Uses the active sandbox workspace for that agent session 2. Prepares the finished work for the selected app or marketing target 3. Queues an approval for you in the agent workspace 4. On approval, ships the change to staging That is the publish-to-staging step. It does not publish production. Production still goes through the workspace [Publish](/publishing/overview) flow. ## Targets A deploy request targets either: | Target | What it ships | | --- | --- | | product | the managed app / product | | marketing | the managed marketing site | ## What You See After the agent requests a deploy successfully: - an approval card appears for the deploy handoff - the primary action is labeled **Publish to Staging** - the reject action is labeled **Reject** If you approve: - Cofounder ships the work to staging - the staging / preview deployment updates If you reject: - staging does not change - Cofounder can reset the session handoff state for that deploy request - the agent gets clearer follow-up guidance so it can fix blockers and request a deploy again ## When Approval Is Ready Whether approval can be queued right away depends on how the target is set up: - managed Cofounder targets can usually queue approval as soon as the handoff is prepared - imported / bring-your-own targets may need automated checks to finish first If the handoff is not ready yet, the agent should fix blockers, prepare the work again, and request a deploy again. ## What It Needs Requesting a deploy needs: - an active sandbox for the agent session - finished work ready to ship for the selected target It will not: - publish production - replace the workspace Publish button ## How This Fits The Full Flow Typical Engineering path: 1. The Engineer implements and verifies in the sandbox when needed 2. The Engineer requests a deploy for the app or marketing target 3. You approve **Publish to Staging** 4. Staging updates with the change 5. When ready for live traffic, use workspace **Publish** to promote staging to production For database migrations: - shipping to staging is the staging apply path - publishing to production is the production apply path See [Migrations](/managed-services/migrations). ## Next Steps - [Publishing](/publishing/overview) - [Environments](/publishing/environments) - [Engineer Agent](/agents/engineer-agent) - [Migrations](/managed-services/migrations) --- ## Canvas **URL:** https://docs.cofounder.co/workspace/canvas **Description:** Use Canvas or Canvas v2 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. ## Which Canvas Version Opens The canonical workspace route is `/org//canvas`. The environment-level feature flag `CANVAS_V2_DEFAULT_ENABLED` controls which workspace that route opens: - When the flag is enabled and the URL contains supported Canvas parameters, the route opens Canvas v2, also called **Solaris**. - When the flag is disabled, or the URL requires a flow that Canvas v2 does not yet handle, the route opens the current Canvas. The flag is environment-scoped rather than a per-user setting. The `/org//canvas-v2` path redirects to the canonical `/canvas` route, so it does not bypass the rollout flag. ## Canvas V2: Navigate The Company World Canvas v2 presents the company as a spatial world. Cofounder sits at the center, departments form the surrounding map, and placed workspaces appear as **pits**. A pit is a location that can contain an agent workspace, task, Library file, department home, Web Preview, CRM, Inbox, or another focused surface. Select a department to frame its part of the world. Select a pit to zoom into the real interactive workspace inside it. Use the world controls to return to the overview, zoom in, or zoom out. You can also: - hold **Command/Ctrl** while scrolling to zoom - hold **Space** and drag to pan - use the command palette to create a task, return to the overview, open the Roadmap, view archived tasks, or open settings Only the focused workspace owns interaction. Other pits remain visible as lightweight previews until you select them. ## Canvas V2: Use The Side Panel The collapsible side panel is the conversation and coordination surface. On desktop it opens on the right and can be resized. On mobile it becomes the full-screen navigation surface. Its root tabs are: - **Cofounder** for company-wide conversation and routing - **Tasks** for active, waiting, completed, and archived work - **Company** for organization context and department navigation - **Library** for files and durable outputs Selecting a department, agent, task, or Library file opens its contextual view in the same panel. When an agent or task is active, the composer sends to that selected conversation while the associated workspace remains visible in the world. ## Canvas V2: Work In Pits Agent workspace pits combine live progress with durable review items. Depending on the task, a workspace can show plans, approvals, artifacts, generated media, tables, code or pull-request diffs, and other published outputs. Select an item in the workspace to inspect it at full size while continuing the conversation in the side panel. Empty **New Content** pits let you describe what Cofounder should create, choose an artifact type, or continue editing an existing artifact. Supported creation choices include documents, code, tables, images, videos, and PDFs. Department areas can also contain permanent surfaces such as Library, Web Preview, CRM, and Inbox. These remain placed in the world while their underlying data updates. ## Canvas V2: Review Work The attention inbox appears over the lower-left area of the world when work needs you. Open an item to focus the associated pit and its task or agent conversation. Review mode lets you move through approvals, clarification questions, completed outputs, failures, and other follow-ups without searching every department. You can snooze an item for later or dismiss it when no action is needed. On mobile, the side panel collapses during review so the relevant workspace stays visible. ## Current Canvas Fallback When `CANVAS_V2_DEFAULT_ENABLED` is off, the same `/canvas` route opens the current Canvas. It uses the existing canvas layout for task cards, agents, department workspaces, artifacts, attention items, and the conversation side panel. Tasks and durable outputs remain shared product data, so changing the workspace implementation does not create a separate task or agent runtime. ## Start And Publish Work Use **New task** or the command palette to describe the work, attach useful files, and choose an agent or let Cofounder route it. Use the side-panel **Cofounder** tab when you are unsure which agent or department should own the request. Agent work reaches shared staging when the agent requests a deploy and you approve **Publish to Staging**. Production still uses the workspace **Publish** flow after staging looks good. See [Requesting a deploy](/publishing/request-deploy) and [Publishing](/publishing/overview). ## Get Help Use the support option in the workspace menu, email [support@generalintelligencecompany.com](mailto:support@generalintelligencecompany.com), or join the [Cofounder Discord](https://discord.gg/7NVEUbtX2b). ## Next Steps - [Company](/workspace/company) - [Tasks](/workspace/tasks) - [Requesting a deploy](/publishing/request-deploy) - [Publishing](/publishing/overview) - [Previews And Feedback](/agents/engineer-agent#previews-and-feedback) - [Roadmap](/workspace/roadmap) - [Departments](/workspace/departments) - [Agents Overview](/agents/overview) --- ## Company **URL:** https://docs.cofounder.co/workspace/company **Description:** Use the Company view to understand your workspace stack, agents, and setup status. ## Company The **Company** view is the workspace-level overview for your organization. Use it when you want to see what Cofounder knows about the company itself, not just one task or one department. ## What It Shows The Company view can show: - metric cards for MRR, active users, churn, and signups, which stay empty until a real data source is connected - stack setup status for domains, email, payments, hosting, and other company infrastructure - the active agents available to the workspace - Company Memory imported from other AI tools Metric cards without a connected data source stay empty. Stack items with no data yet show an empty or setup-needed state instead of guessing. ## Company Memory Company Memory is shared workspace context that agents can search when they need prior decisions, project notes, workflows, or company facts. It can come from completed tasks, connected integrations, and [Company Context](/settings/company-context) imports. Use it for reusable company context, not one-off task instructions. Good memory includes: - company and product facts - important decisions and why they were made - recurring workflows and team preferences - active projects, goals, risks, and open questions - source notes that help another agent trust the context later Do not store secrets, API keys, private credentials, or raw transcripts in Company Memory. Memory can lag behind recent updates. If an important detail matters for a customer, production change, or external send, ask the agent to verify it against the source before acting. To change memory, tell Cofounder what to update in chat, update the connected source, or import cleaner context through [Company Context](/settings/company-context). ## Stack Status The stack area helps you see what is ready and what still needs setup. For example, domains, payments, email, and hosting can each show whether Cofounder has enough connected infrastructure to use them in agent work. When a stack item needs setup, open the related settings page or start the suggested agent task from the Company or Canvas flow. ## Engineering Workspace Open **Canvas** and go to the **Engineering** workspace for app infrastructure work. That workspace is where you can: - open the [**Database** artifact](/agents/engineer-agent#database-viewer) to view tables, inspect records, and upload CSV data - use **Stack** to see the services connected to the app - use **Deployments** to review previews, publish, and deploy the app ## Switch Or Create A Company Use the account menu in the top corner of Canvas when you work across more than one company workspace on the same account. From the account menu you can: - open **Switch company** when you already belong to multiple companies, then pick the workspace you want - choose **Create new company** to open the companies page and start another company workspace **Create new company** also appears in the account menu when you only have one company today. On the companies page you can review **Your companies** and finish **Create new company**. Plan limits can require an upgrade before additional companies are available. Switching companies changes the active workspace context, including Canvas, tasks, Library files, agents, and connected company setup. It does not merge data across companies. If you need a clean slate inside the current company instead of a second company, use **Start fresh** below. ## Start Fresh If the current company workspace is the wrong starting point, company admins can start fresh from **Settings > Company**. **Start fresh** keeps your account, billing, and remaining credits. Cofounder archives the current workspace and creates a clean one so you can run through setup again without making a brand-new account. Use this when: - you started with the wrong business or project - onboarding left the workspace in a bad state - the business direction changed and you want a clean slate - you want to clear workspace data and begin again Only company admins can start fresh. The flow asks why you want a clean workspace before it continues. Starting fresh is destructive for the current workspace contents. Export or save anything you still need before you confirm. ## Next Steps - [Canvas](/workspace/canvas) - [Tasks](/workspace/tasks) - [Company Context](/settings/company-context) - [AI Settings](/settings/ai-settings) - [Agents Overview](/agents/overview) - [Roadmap](/workspace/roadmap) --- ## Departments **URL:** https://docs.cofounder.co/workspace/departments **Description:** Understand the department workspaces in Cofounder and what each one is for. ## 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 has department workspaces for the main lanes of company work. The department workspaces are: - **Engineering** for product, app, repository, infrastructure, security, database, and deployment work - **Sales** for pipeline, leads, outreach, customer conversations, and revenue work - **Marketing** for positioning, content, SEO, launch work, social publishing, recurring Marketing Missions, and marketing-site work - **Design** for brand identity, visual systems, decks, email templates, UI kits, and product design support - **Support** for customer support, issue resolution, and customer success operations - **Operations** for recurring workflows, internal process, reporting, research, and cross-system cleanup - **Finance** for billing operations, collections, accounting handoff, close support, and financial reporting - **Legal** for contract support, policy review, compliance artifacts, and legal-ops workflows ## Default Agents By Department Seeded default agents are organized by department. The exact agents in your workspace can change as your setup changes, but onboarding starts with: - **Engineering**: `Engineer` - **Sales**: `Sales Agent` - **Marketing**: `Marketing Agent` - **Design**: `Design Agent` - **Support**: `Support Agent` - **Operations**: `Operations Agent`, `Ops Agent` - **Finance**: `Finance Agent` ## 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 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 The Marketing department can guide setup for channels, Missions, operating intensity, approval-gated publishing, and analytics-informed follow-up. See [Marketing Department](/workspace/marketing-department). The Engineering department can also show the managed Supabase [**Database** artifact](/agents/engineer-agent#database-viewer) on Canvas. Use that artifact when you need to browse tables, inspect records, or upload CSV data. 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 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 - brand and visual direction for Design - support policies for Support - reporting definitions for Operations - billing and close process notes for Finance - contract, policy, and compliance notes for Legal ## Next Steps - [Library](/workspace/library) - [Marketing Department](/workspace/marketing-department) - [Canvas](/workspace/canvas) - [Agents Overview](/agents/overview) - [Skills](/agents/skills) --- ## Library **URL:** https://docs.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 - search across library files - browse files by department folder - open directories and files - pin important files so they stay surfaced at the top of the file list for that file's department - edit supported Markdown, plain-text, and image files in preview - chat with a specific file when you want an agent to use it as focused context - download files when a download link is available - copy the agent sandbox path for a file - delete or archive files you no longer need - use department association to understand which files are most relevant to which kind of work ## Browsing Files The Library starts at the folder level. Open a department folder to see that department's files and directories. From there, you can move back to all folders, move up to a parent directory, search within the library, open a file, or pin a file. When a file is open, Cofounder shows the file contents in the Library view so you can inspect the artifact without leaving the workspace. ## File Actions Use the triple-dot menu on a file card, or right-click the card, for the same file actions: - **Open** - **Chat** - **Pin** or **Unpin** - **Download** - **Copy file path** - **Delete** **Copy file path** copies the absolute Library path agents use in the sandbox, such as `/workspace/library/marketing/brief.md`. Use that path when you want to point an agent, script, or task at an exact Library file. ## Editing Markdown And Text Files You can edit supported Markdown and plain-text files directly from Library preview. Open an editable file, choose **Edit**, make your changes, then save. Cofounder updates the shared Library file and refreshes the preview after the save completes. Editing is available for small Markdown and plain-text files when Cofounder can load the complete file and confirm which version you opened. It is not available for folders, archived files, locked files, read-only files, truncated large files, or preview-only formats such as CSV, HTML, JSON, code, images, PDFs, binary files, and specialized artifact data. If someone or an agent changes the file after you opened it, Cofounder treats the save as a conflict. Reload the latest preview, review your draft, and save again only if your changes still apply. For formats that are not editable in preview, use file chat or ask an agent to update the file. ## Editing Images You can edit supported images directly from Library preview. Open an image file, choose **Edit**, adjust the crop, then save. Cofounder updates the shared Library image and refreshes the preview after the save completes. While editing, you can: - crop and zoom the image - choose a ratio preset such as free, square, portrait, landscape, OG image, or custom - convert the output format to JPEG, PNG, or WebP - adjust output quality before saving When you are done, choose **Save Variant** to write the edited image back to the Library, or **Cancel** to discard the edit session. Image editing is available only when Cofounder can load a preview for the file and confirms that transforms are allowed for that image. If **Edit** is unavailable, use file chat or ask an agent to produce a new image asset instead. ## 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. For example, marketing work often lands here automatically as: - campaign briefs, launch plans, and messaging docs - decks, presentations, one-pagers, and branded docs - image directions, page concepts, and design variants - audio, short video, and social draft assets - measurement notes, SEO briefs, and follow-up plans That makes the Library the default place to review, reuse, and share generated marketing assets across the workspace. ## Reusable Scripts Agents can also save reusable scripts to the Library. Scripts live under `scripts/` and can be written in Python, Bash, TypeScript, or JavaScript. They are useful when a workflow needs to be run again later with new inputs, such as enriching a CSV, transforming exported data, checking records against an API, or producing a recurring report. Agents can list saved scripts, read an existing script before changing it, write a new script, and run a saved script inside the session sandbox. If an agent writes a script with the same filename as an existing Library script, the saved script is updated. From the Library, users can open a saved script and choose **Run script**. The run dialog can pass an optional input file from the Library, or an exact `/workspace/` path, to the script. Scripts that accept files should expose an `--input ` argument so the Library run flow can pass the selected file directly. A common pattern is: - connect the native app or MCP server that exposes the needed data - ask an agent to write `weekly_report.py` and save it to the Library - upload a new CSV export or point the script at a workspace file - run the script from the Library with that CSV selected The script can read the selected input file, call approved tools or connected services, and write the results back to the workspace. ## Next Steps - [Departments](/workspace/departments) - [Canvas](/workspace/canvas) - [Agents Overview](/agents/overview) --- ## Marketing Department **URL:** https://docs.cofounder.co/workspace/marketing-department **Description:** Set up the Marketing Department, choose channels and Missions, review the operating plan, and manage ongoing marketing work. ## Marketing Department The **Marketing Department** is the workspace for repeatable marketing operations: positioning, content planning, social publishing, launch work, analytics review, and recurring Marketing Missions. Use the Marketing Department when you want Cofounder to help run a marketing loop over time, not just draft a one-off artifact. The Marketing Department brings together: - a dedicated Marketing workspace on Canvas - the **Marketing Agent** and any custom marketing agents you add - department context, files, and generated campaign assets - recommended channels and content Missions - approval-gated publishing drafts - marketing analytics and follow-up recommendations ## Marketing Setup When you open or start the Marketing Department, Cofounder guides you through a setup flow that turns your company context into an operating plan. The setup usually asks you to confirm three things: 1. **Channels** — where Marketing should focus first. 2. **Missions** — the recurring marketing loops you want Cofounder to help run. 3. **Intensity** — how often the department should create or prepare new work. Cofounder uses your company context, positioning, product stage, and connected accounts to recommend sensible defaults. You can accept the defaults or adjust them before launch. ## Choose Channels Channels tell the Marketing Department where to focus content and publishing work. Supported channel recommendations can include: - LinkedIn - Instagram - X - Reddit - Facebook - TikTok - Threads - YouTube - Pinterest - Bluesky - Telegram - Snapchat You can choose one or more channels. Cofounder uses those choices to shape the content calendar, draft formats, approval cards, and analytics views. You do not need every account connected before setup. If a channel needs a connection later, Cofounder will keep drafts reviewable and ask before taking external actions. ## Choose Marketing Missions A **Marketing Mission** is a recurring loop with a goal, objectives, cadence, approval rules, and a first task. During setup, Cofounder recommends Missions based on your business. Examples include: - founder point-of-view posts - customer evidence sprints - ICP pain-point research - market-response monitoring - category clarity content - short-form demo clips - community answer desks - competitor gap watching You can activate multiple Missions. Cofounder creates operating documents for selected Missions and starts the primary first task when the department launches. After launch, you can manage recurring Missions from the Marketing workspace. Pause a Mission when the loop should stop temporarily, resume it when you want it active again, or archive it when it no longer belongs in the operating plan. A Mission can update Marketing context, maintain structured state, draft content, prepare calendar items, and ask for approval when something would leave the workspace. ## Choose Intensity Intensity controls how much marketing work Cofounder should prepare. Typical levels are: | Intensity | Planning target | | --- | --- | | Minimal | 3 posts per week | | Steady | 5 posts per week | | Active | 8 posts per week | | Aggressive | 12 posts per week | | Full send | 18 posts per week | Higher intensity means Cofounder prepares more drafts and follow-up work. It does not mean Cofounder publishes externally without review. ## Launching The Department After you confirm channels, Missions, and intensity, Cofounder materializes the Marketing workspace. Launch can create: - a Marketing operating plan - Mission operating documents in the Library - selected recurring Missions - an initial task for the primary Mission - a Marketing workspace announcement card - draftable content/calendar work for review If something fails during launch, Cofounder should keep the setup tied to the Marketing workspace chat so you can retry without starting from scratch. ## How Ongoing Marketing Work Runs After launch, Marketing work happens through Missions and ordinary Marketing Agent tasks. Use **Missions** for ongoing loops such as keeping a content calendar full, drafting founder-led posts, or monitoring market response. Use the **Marketing Agent** for one-off work such as a launch brief, campaign plan, deck, landing-page brief, image set, or SEO brief. A healthy Marketing Department flow looks like this: 1. Cofounder recommends or runs the next Marketing task. 2. The Marketing Agent drafts the artifact, content, or plan. 3. The result appears in Canvas or the Library. 4. You review approvals before publishing or sending anything externally. 5. Cofounder updates department context and Mission state as work completes. 6. Analytics and prior results inform the next recommendation. ## Publishing And Approval Marketing can prepare publishing-ready drafts, but external actions are review-gated. Review before: - publishing social posts - scheduling posts to connected accounts - sending campaigns - changing a live marketing site - using claims, customer quotes, pricing, or performance numbers externally ### Publish To Multiple Accounts A single social card can target more than one connected account at once. When a draft is ready, choose the destination accounts for that post. Cofounder tracks each destination separately, so one account can succeed while another still needs attention. This is useful when the same update should go out across several LinkedIn pages, Instagram accounts, X accounts, Reddit destinations, or other connected channels without recreating the card for each one. If the card asks you to choose an account, pick the destinations before approving publish or schedule. Review the per-account result after the action runs. Some cards may show that one provider or channel succeeded while another needs attention. Treat those as partial results: review what succeeded, fix the failed channel or connection, then retry the remaining action when appropriate. ## Analytics And Follow-Up The Marketing Department uses analytics and workspace state to recommend follow-up work. Depending on your setup, Cofounder can track signals such as: - onboarding and setup completion - selected channels and Missions - content calendar coverage - published or draft content status - engagement and channel performance - company profile and positioning signals - first-task and first-canvas outcomes These signals help Cofounder make better recommendations, but they do not replace human judgment. Use analytics as a prompt for the next campaign, content iteration, or positioning update. ## When To Use Another Department Use another department when the work belongs elsewhere: - **Sales** for lead lists, outbound, pipeline, ICP validation, and customer-development work. - **Design** for brand systems, visual direction, UI kits, and high-polish presentation design. - **Engineering** for code, app changes, marketing-site implementation, instrumentation, and production deploys. - **Support** for customer issues and support operations. Marketing can brief these departments, but the implementation should happen with the right agent. ## Next Steps - [Marketing Agent](/agents/marketing-agent) - [Departments](/workspace/departments) - [Canvas](/workspace/canvas) - [Library](/workspace/library) - [Publishing](/publishing/overview) --- ## Roadmap **URL:** https://docs.cofounder.co/workspace/roadmap **Description:** Use the Roadmap as a guide for moving through Cofounder and building out your business. ## Roadmap The Roadmap 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 Roadmap is organized into: - **Stages** like idea, initial setup, identity, build, GTM, launch, scale, and mature company work - **Tracks** across areas like product, engineering, brand, research, operations, revenue, and support - **Steps** for specific milestones in the journey Each stage shows completion progress, such as `1/4`, so you can see how far along that part of the company-building path is. ## Step Status Roadmap steps 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 ## Step Details Open a step to see its detail panel. Step details can explain: - why the step matters - how to move it forward - subtasks involved in the step - which prerequisite steps are required first - what completing the step unlocks If the step is agent-backed and available, the detail panel includes a launch action that starts the task with the right agent. ## Kicking Off Work You can open the Roadmap from Canvas. For steps that are agent-backed, you can launch the work directly from the Roadmap 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. ## Incorporating Your Business Use the **Incorporate LLC** Roadmap node when you are ready to form the legal entity for your company. Open **Canvas**, open the **Roadmap**, then select **Incorporate LLC**. Choose **Incorporate LLC with Ramp** to start a guided agent flow. Cofounder now handles this as a conversation with an agent instead of a one-shot form. The agent can help you start or continue the Ramp application, gather the non-sensitive business details Ramp needs, look up available filing states and industry codes, and track what is still waiting on you, Ramp, or Cofounder. During the flow, you may be asked to: 1. Start or connect your Ramp application. 2. Accept the Ramp email invite and choose **Start application** in Ramp. 3. Finish applicant-owned Ramp steps, such as identity or phone verification, directly in Ramp. 4. Confirm your formation details with the Cofounder agent. 5. Approve any application or formation submission before the agent sends it. 6. Return to the Roadmap to track application and incorporation status. For LLC formation, Cofounder asks for the state where you want to form the LLC, your industry or NAICS code, a short business description, at least three ranked LLC name options, and a US mailing address with a contact phone number. The agent can look up Ramp-supported states, filing fees, and industry codes while you decide. Cofounder does **not** collect SSNs in chat, documents, or tool inputs. If Ramp needs SSN or identity information, the agent sends you to the Ramp-hosted step so you can enter it directly with Ramp. If Ramp still needs action from you, Cofounder sends you back to Ramp and checks the status afterward. If the filing needs a correction, such as a name conflict, Cofounder shows the reason and helps you prepare the updated details before resubmitting. After the formation is filed, Cofounder can check whether it is pending review, submitted with the state, approved, or rejected, and can list formation documents when Ramp makes them available. If you completed incorporation outside Cofounder, the Roadmap can still let you record incorporation manually with an attestation. **Important:** Incorporating through Ramp can involve filing costs. Cofounder can guide the workflow and send supported filing details through Ramp, but it does not replace legal, tax, or filing-provider advice. ## How Items Get Checked Off Roadmap 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, steps move forward from locked or available to in progress and completed. You can also mark a roadmap or tech-tree item complete manually when the work happened outside Cofounder's automated flow. Add a short attestation that explains why the item is done so the workspace keeps a readable record of the decision. ## How To Use It The Roadmap 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 step instead of making you figure it out from scratch. ## Next Steps - [Canvas](/workspace/canvas) - [Tasks](/workspace/tasks) - [Departments](/workspace/departments) - [Agents Overview](/agents/overview) --- ## Tasks **URL:** https://docs.cofounder.co/workspace/tasks **Description:** Track running work, review completed work, and open task details from one place. ## Tasks The **Tasks** page is the list view for work across the current workspace. Use it when you want to see what is running, what is waiting on you, and what has finished recently. ## Task Sections Tasks are grouped by what is happening with the work now. The Tasks page shows these sections: - **Needs Action** for work waiting on you - **Ongoing** for work that is waiting to start or currently running - **Done** for work that finished and no longer needs action - **Todo** for task rows that are not running yet You can also open archived tasks when you need to look up older work. ## Needs Action Use **Needs Action** when you want to clear everything waiting on you. Tasks move here when: - the agent asks a clarification question - the agent needs approval to continue - a tool or permission approval is required - the agent produced something reviewable, such as an artifact, preview, pull request, export, or review URL - the task failed, errored, or stopped and needs follow-up Reviewable output appears as **Ready to review**. Open the task, inspect the result, then approve, respond, or mark the task complete. Clarification questions and approval requests stay in **Needs Action** until you answer, approve, or close them. ## Ongoing **Ongoing** contains tasks that are still in motion. A task can show: - **Waiting to start...** while it is queued or being prepared - **Running...** while the agent is actively working Running work stays in **Ongoing** until the agent stops, asks for input, needs approval, produces reviewable output, fails, or finishes. ## Done **Done** contains tasks that no longer need action. There are two common finished states: - **Completed** means the task was marked complete - **Finished turn** means the agent finished without a separate output that needs review Finished-turn tasks stay available in task history, but they do not show up as review items. ## Todo **Todo** is for task rows that exist but are not currently running. Most agent tasks move through **Ongoing**, **Needs Action**, and **Done**. If a task is already queued for an agent run, it usually appears in **Ongoing** as **Waiting to start...** rather than Todo. ## Task Details Open a task to see the task detail view. Depending on the task, the detail view can show: - the original request - the assigned agent - task state and elapsed time - workflow items, approvals, and generated artifacts - the conversation with the agent - options such as reporting an issue or opening more task actions If there is nothing pending, Cofounder shows that clearly instead of leaving an empty review panel. ## Editing A Previous Message When **Edit message** is available on one of your messages, you can change that message and send it again. The agent continues from the edited message. Later messages from the previous path are removed from the active conversation, so use this when you want to change direction rather than add another note. You can edit your own messages when the agent is not currently running. ## Reviewing Work Tasks that need action appear on the Tasks page and in review mode on Canvas. From review mode, you can move between waiting items, snooze an item for later, dismiss items that no longer need action, or exit review mode and return to normal navigation. Use this when several tasks have produced outputs, approvals, clarification questions, failures, or stopped runs and you want to process them without hunting through task lists. If an agent simply finished without producing a review item, Cofounder keeps the task in history instead of asking you to review it. ## Closing Task Work Tasks move into **Needs Action** automatically when an agent asks a question, requests approval, fails, stops, or produces something reviewable. Once you are done with waiting, failed, stopped, or reviewable work, mark it complete to move it into **Done**. If you complete something by mistake, the task action menu can mark it active again. ## Creating Tasks You can create a task from the **+** menu on Canvas. The task form lets you: - write the task description - attach images or screenshots - let Cofounder auto-assign the best agent - choose a repository when the task needs code context - choose **Execute** or **Plan** The **Create Task** button becomes available once the task has enough information to run. ## Plan Mode Choose **Plan** when you want an agent to propose the approach before it starts the work. Plan mode is useful for: - large product or engineering changes - work that touches several files, systems, or teams - tasks where you want to approve the approach first - research or setup work where the next step is not obvious When the plan is ready, the agent shows it as a review item. You can approve it and let the agent continue, or ask for changes. Use **Execute** for straightforward tasks where the agent can start right away. ## Next Steps - [Canvas](/workspace/canvas) - [Previews And Feedback](/agents/engineer-agent#previews-and-feedback) - [Library](/workspace/library) - [Agents Overview](/agents/overview) --- ## AI Settings **URL:** https://docs.cofounder.co/settings/ai-settings **Description:** Set global AI behavior for your workspace. ## AI Settings Use **Settings > AI Settings** to configure Cofounder agent settings. ## What You Can Set This page includes: - global prompt personalization ## Global Prompt Personalization Use global prompt personalization for context Cofounder should include across chats and agents, such as preferred response style or durable working assumptions. ## Related Pages - [Notifications](/settings/notifications) - [Testing Changes Locally](/agents/engineer-agent#testing-changes-locally) - [Environment Files & Secrets](/settings/env-files-and-secrets) - [Requesting a deploy](/publishing/request-deploy) - [Workspace](/workspace/canvas) --- ## Company Context **URL:** https://docs.cofounder.co/settings/company-context **Description:** Import company context from other AI tools into Company Memory. ## Company Context Use **Settings > Organization > Company Context** to import useful company knowledge from another AI tool into Cofounder. This is useful when ChatGPT, Claude, or another tool already knows things about your company that Cofounder should remember for future work. ## When To Use It Use a Company Context import when you want Cofounder to remember context such as: - what the company does - product and customer facts - important decisions and why they were made - team preferences and recurring workflows - active projects, goals, constraints, risks, and open questions Do not use it for one-off task instructions. Put task-specific context in the task itself. ## How It Works 1. Open **Settings > Organization**. 2. Find **Company Context**. 3. Choose the source tool. 4. Copy the generated prompt. 5. Paste the prompt into the source tool. 6. Bring the generated report back to Cofounder. 7. Preview the items Cofounder found. 8. Import the items you want saved. The source tool is not connected directly. It only generates a report that you paste or upload back into Cofounder. ## Preview Before Importing Preview shows the memory items Cofounder plans to create. Review the title, summary, type, and evidence for each item before importing. If the preview looks wrong, edit the report or regenerate it in the source tool before trying again. ## What Not To Import Do not import: - secrets, passwords, API keys, tokens, or private keys - raw transcripts or long logs - private personal context that is not about the company - guesses that the source tool cannot support ## Import History Cofounder keeps a history of completed imports so admins can see what was brought into Company Memory. Only organization admins can import company context. ## Related Pages - [Company](/workspace/company) - [AI Settings](/settings/ai-settings) - [Agents Overview](/agents/overview) --- ## Domains **URL:** https://docs.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. Open the **Domains** page from the account menu. Domains is a standalone page next to Settings, not a section inside Settings. The Domains page has two main tabs: - **Search** to find and secure a new domain - **Owned** to view domains your organization already controls You can also start a domain transfer from the Domains page. Depending on the domain state, 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 ## Manage Your Own DNS Records If your domain uses Cofounder's managed nameservers, the domain owner can add, edit, and delete DNS records from the **Domains** page. You can also ask Cofounder in chat to manage DNS records for you, such as adding verification records, pointing a subdomain, or reviewing the current DNS setup. Use this when you need to point a subdomain at another service, add verification records, or update records for email and app setup. DNS editing is available only to the domain owner. If the domain still uses another DNS provider, Cofounder shows the records you need on the Domains page, but you add them at that provider instead of editing them inside Cofounder. ## 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. ### First Owned Domain If your organization does not already have a managed domain assignment, Cofounder can auto-assign the first trusted owned domain after purchase or order refresh. Auto-assign skips domains that are still purchase-pending, use external DNS, or do not yet show trusted ownership. Those domains stay on the **Owned** tab until you finish setup or assign them yourself. ### Assign Or Switch On the **Owned** tab: - if no domain is assigned yet, choose **Assign** - if another domain is already assigned, unassigned owned domains show **Switch projects over to this domain** Switching makes the selected domain the primary domain for your managed app and site. Cofounder detaches other managed domain assignments as part of that switch. Domains that still need external DNS setup show a **DNS setup** state instead of Assign or Switch until verification is ready. ## 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. ## Related Pages - [Inbox](/settings/inbox) - [Environment Files & Secrets](/settings/env-files-and-secrets) - [Integrations Overview](/integrations/overview) --- ## Environment Files & Secrets **URL:** https://docs.cofounder.co/settings/env-files-and-secrets **Description:** Upload env files, download managed staging env files, and add project secrets. ## Environment Files & Secrets Use **Settings > Env Files & Secrets** to manage project configuration. This page has three areas: - **Environment Files** for uploading and editing encrypted `.env` files - **Managed Vercel Staging Export** for downloading staging environment variables from managed Vercel projects - **Secrets** for adding API keys to managed Vercel projects and the development environment ## Environment Files Upload `.env` files when you want Cofounder to store project configuration as editable variables. After upload, open the file to view and edit individual variables. ## Managed Vercel Staging Export When a managed app or marketing Vercel project exists, Cofounder can download that project's staging environment variables as a `.env` file. If no managed project is available yet, the project selector and download action stay disabled. ## Secrets Use **Add Secret** for API keys that should be pushed directly to a managed Vercel project. Choose the secret name, value, target environments, and project. The **Staging** environment is sent to Vercel Preview behind the scenes. Secret values are sent to Vercel and are not stored in our systems. Turn on **Development environment** when code running in the agent's sandbox needs to use the secret through an environment variable. This is useful for local verification against a third-party API, payment provider, or internal service. Secrets marked this way show a **Development** badge. You can change development environment access later from the pencil icon and save with **Save Development Access**. Only enable a secret for the development environment when the task needs it. Do not paste secret values into task messages or chat. ## How Agent Secret Access Stays Safe Agent access does not mean the raw credential is written into the conversation or stored in the workspace. When a sandbox starts, the agent can use the same environment variable name, such as `STRIPE_SECRET_KEY` or `OPENAI_API_KEY`. The value inside the sandbox is a placeholder, not the raw secret. When sandbox code makes a brokered network request with that placeholder, Cofounder's trusted backend swaps in the real credential for the outbound request. This lets the code call the service without exposing the secret value to the agent's files, chat messages, or normal command output. For local tools or non-HTTP clients that validate or consume the value before making an HTTP request, run the command through `gic-run -- `. `gic-run` resolves brokered placeholders only for the child process environment, applies every secret it can resolve, and skips unresolved placeholders with a warning instead of blocking. It must never be used to print raw secret values; refer to the environment variable name or placeholder name when diagnosing a failure. If a task no longer needs the credential, turn off **Development environment** for that secret. ## Related Pages - [Testing Changes Locally](/agents/engineer-agent#testing-changes-locally) - [Domains](/settings/domains) - [Integrations Overview](/integrations/overview) --- ## Inbox **URL:** https://docs.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 on the **Domains** page (account menu, next to Settings) 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. ## Warm Up a New Inbox Before Outreach Some workspaces can start inbox warming while provisioning a new agent inbox. Inbox warming gives the inbox time to build safe sending history before the agent uses it for outreach. When inbox warming is available, turn on **Inbox warmup** before you provision the inbox. Cofounder creates the inbox in a warmup-only state, starts the warmup enrollment, and keeps outreach locked until the domain reaches the required minimum. Inbox warming is only available when all of these are true: - the domain was purchased through Cofounder - the domain has not been imported or transferred in - the domain is verified and ready for Agentmail inboxes - the inbox is new, and warmup is selected before provisioning it - the domain does not already have regular outreach inboxes Imported domains, transferred domains, and domains that already have normal outreach inboxes are not eligible for new inbox warmup. If a domain is warming, new regular outreach inboxes on that domain stay blocked until warmup is released. Warmup has a **21 day minimum**. Cofounder recommends **28 days** for the full benefit. Once warmup starts, it cannot be cancelled to unlock outreach early. When the domain reaches the minimum, **Settings > Inbox** shows the warmup progress and lets an admin enable outreach for the domain. Releasing outreach updates the warmed inboxes so agents can send normal email from that domain. ## What Happens After Provisioning When an inbox is provisioned for an agent: - Cofounder creates the inbox for that agent - the agent can send and receive email through that inbox - incoming messages are available to that agent's email workflow When inbox warming is selected: - Cofounder creates the inbox as warmup-only - the inbox participates in warmup automation instead of normal outreach - the whole domain stays blocked for outreach until every warming inbox on that domain reaches the 21 day minimum and outreach is enabled Scheduled follow-up work for that agent is managed separately with scheduled tasks. ## 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 - warmup progress and outreach release, when inbox warming is available Disabled inboxes still exist, but they stop processing incoming email. ## Related Pages - [Domains](/settings/domains) - [Custom Agents](/agents/custom-agents) --- ## Notifications **URL:** https://docs.cofounder.co/settings/notifications **Description:** Control email notifications and desktop alerts for completed work, approvals, and account updates. ## Notifications Use **Settings > Notifications** to control how Cofounder reaches you. ## Email Notifications Email preferences apply to your account across all Cofounder companies. You can turn these on or off: - **Promotional emails** for trial and upgrade offers, product announcements, promotions, and release notes - **Billing emails** for receipts, payment issues, balance alerts, and changes that affect company access ## Desktop Alerts Desktop alerts show system notifications for approvals, questions, and issues that need your attention. When desktop alerts are on, you can also: - choose **Only when I'm away** to skip alerts while you are active in Cofounder - turn on **Hide task details** to keep task names out of system notifications - allow notifications for the current browser when the browser asks for permission - send a test alert after permission is granted If the browser blocks notifications, update the permission in your browser settings before desktop alerts can work there. ## Related Pages - [AI Settings](/settings/ai-settings) - [Company Context](/settings/company-context) --- ## Links - [Support](mailto:support@generalintelligencecompany.com)