llms full.txt
# 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 prompt, integrations, skills, or department when the change is about that agent's working contract.
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, add browser test credentials in [AI Settings](/settings/ai-settings) so the Engineer can use a test account instead of your personal account.
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 test 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 - **Stitch** screen concepts and design variants for early UI exploration, best treated as concept sketches rather than production-ready UI - **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 - changing a live marketing site - using generated claims, customer quotes, pricing, or performance numbers - sharing decks or assets with external audiences
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
## 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.
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, Stitch | | 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 - linking the managed Vercel project to that repo - setting the root directory - syncing env vars
For app repos, it can also keep managed Supabase env wiring, migrations, and the `prod` branch setup aligned.
## Next Steps
- [Vercel](/managed-services/vercel) - [Managed Services](/managed-services/overview)
---
## Migrations
**URL:** https://docs.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 - **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)
---
## Postmark
**URL:** https://docs.cofounder.co/managed-services/postmark **Description:** Understand how Postmark handles transactional email in Cofounder.
## Postmark
Cofounder uses Postmark for transactional email only when a workspace already has an email provider binding.
## Role
Postmark handles transactional email for the workspace.
- it powers product emails like sign-in links and other system email - it connects sending domains to the managed app setup when email is configured - it gives Cofounder a managed email provider instead of making users wire this up themselves
## Domain Sync
When a domain is assigned in `Settings > Domains`, Cofounder can sync that domain to Postmark if the workspace has an email provider binding.
The user still needs to activate the domain for Postmark before email can send from it.
## Next Steps
- [Settings: Domains](/settings/domains) - [Managed Services](/managed-services/overview)
---
## Supabase
**URL:** https://docs.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) - [Postmark](/managed-services/postmark) - [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 - Postmark environment variables for email when the workspace has email configured - 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.
## Next Steps
- [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 the canvas as the live workspace for tasks, agents, reviews, and related work.
## What Canvas Is
Canvas is the main operating surface for Cofounder. It is the default landing page for an organization and the fastest way to understand what is active, what is blocked, and what should happen next.
## What You Can See On The Canvas
Depending on what is running, Canvas can show:
- active tasks and their current state - agents and the work assigned to them - departments and department-level workspaces - department artifacts, such as the **Database** artifact in Engineering - work waiting on review - suggested next tasks from the Roadmap or recent workspace activity - staging URLs for deterministic preview links - attention queue items
## Using Canvas
### Launch work from the create menu
Use the **+** menu to create either a new task or a new agent.
For tasks, add the request, attach any useful files, and either choose an agent yourself or let Cofounder auto-assign the work.
For agents, create a reusable worker with its own name, instructions, model, apps, and scheduled tasks.
### Work at the department level
Departments open as focused workspaces inside Canvas.
Inside a department you can see its agents, tasks, files, rules, and context. Department context and rules help the agents in that lane share the same operating assumptions.
The **Engineering** workspace also includes a [**Database** artifact](/agents/engineer-agent#database-viewer) when managed Supabase is connected. Open it to browse tables, inspect records, or upload CSV data without leaving Canvas.
### Use the attention queue
The attention queue is the button in the bottom right of Canvas. It appears when agents have work ready for you.
Open it to review finished work, approvals, and follow-ups without digging through every task.
From review mode, move through each item, open the task, snooze it for later, or dismiss it when no action is needed.
### Chat with Cofounder
The side panel lets you ask Cofounder questions about the company or ask it to spin up new work.
Use this when you are not sure which agent should handle a request. Cofounder can help route the task to the right agent or workspace.
### Save staging URLs
When you have a staging deployment URL for a task or preview, save it on the Canvas node. That gives the workspace a stable preview link it can reopen later.
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).
## 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
## Next Steps
- [Canvas](/workspace/canvas) - [Tasks](/workspace/tasks) - [Company Context](/settings/company-context) - [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 - chat with a specific file when you want an agent to use it as focused context - 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.
## 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.
## 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
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
- [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.
The domain 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 domain 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 **Settings > Domains**.
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, 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.
The same assignment also registers the domain with Postmark and prepares the DNS records needed for email sending.
## Inbox Domains
Your domains can also be used for agent inboxes.
In `Settings > Inbox`, you can choose which of your domains should be available as inbox domains for agents. Once a domain is ready there, you can assign inbox addresses to agents on that domain.
## Email Sending With Postmark
Assigned domains can also be used for transactional email through Postmark when the workspace has email configured.
When the sending domain verifies, Cofounder turns on Postmark-backed SMTP for the managed Supabase projects.
It also syncs the Postmark configuration into the managed Vercel projects, including:
- the Postmark server token - the Postmark server ID - the message stream IDs - the default from address
If the domain is using managed Vercel nameservers, Cofounder can also auto-create the Postmark DNS records. Otherwise, Cofounder shows the records you need to add manually.
## Related Pages
- [Inbox](/settings/inbox) - [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 in **Settings > Domains** to buy a domain from Cofounder, import one, or transfer one in.
After that, go to **Settings > Inbox** and choose which domain should be used for agent inboxes.
## Inbox Domain Setup Takes Time
Inbox domain setup is not instant.
After domain or nameserver changes, Agentmail still needs time to provision and verify the inbox domain. During that window, the inbox domain can show as pending or still checking setup.
## Provision An Inbox For An Agent
Once an inbox domain is ready, you can provision an inbox for a custom agent.
In **Settings > Inbox**, pick the agent, choose the inbox-ready domain, set the inbox handle, and provision the inbox.
That gives the agent its own email address on your domain.
## 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)
---
## Links
- [Support](mailto:support@generalintelligencecompany.com)