- Open the **Chat panel**, select `agent1.content` as the output to display, and send: *"John is a software engineer from San Francisco who studied Computer Science at Stanford University."*
+ Open the editor's **Chat panel**, select `agent1.content` as the output to display, and send: *"John is a software engineer from San Francisco who studied Computer Science at Stanford University."*
The agent searches, then returns what it found.
@@ -101,6 +101,6 @@ Build a people research agent in 10 minutes. It takes a name through a chat inte
{ question: "Do I need API keys to follow this tutorial?", answer: "No. On hosted Sim, the model and the search tools run on Sim's hosted keys, included with your plan credits. You can bring your own provider keys if you prefer." },
{ question: "Do I need coding experience to complete this tutorial?", answer: "No. The whole tutorial uses the visual builder and the chat panel — no code." },
{ question: "Can I use a different model?", answer: "Yes. The Agent block supports models from OpenAI, Anthropic, Google, Groq, Cerebras, DeepSeek, xAI, and more, plus local models through Ollama if you self-host." },
- { question: "Can I import workflows from other tools?", answer: "Not directly. But you can describe what you want to Mothership in natural language and have it build the workflow for you, which is usually faster than manual recreation." },
+ { question: "Can I import workflows from other tools?", answer: "Not directly. But you can describe what you want in Chat and have Sim build the workflow for you, which is usually faster than manual recreation." },
{ question: "What if my workflow does not produce the expected output?", answer: "Test iteratively in the Chat panel and inspect each block's output from the dropdown to pinpoint where things go wrong. The Logs page records every run, block by block, with inputs, outputs, timing, and cost." },
]} />
diff --git a/apps/docs/content/docs/en/index.mdx b/apps/docs/content/docs/en/index.mdx
index e4e6ca4f453..c7360ed0398 100644
--- a/apps/docs/content/docs/en/index.mdx
+++ b/apps/docs/content/docs/en/index.mdx
@@ -6,7 +6,7 @@ import { Card, Cards } from 'fumadocs-ui/components/card'
# Sim Documentation
-Welcome to Sim, the open-source AI workspace where teams build, deploy, and manage AI agents. Create agents visually with the workflow builder, conversationally through Mothership, or programmatically with the API — connected to 1,000+ integrations and every major LLM.
+Welcome to Sim, the open-source AI workspace where teams build, deploy, and manage AI agents. Create agents visually with the workflow builder, conversationally in Chat, or programmatically with the API — connected to 1,000+ integrations and every major LLM.
## Quick Start
diff --git a/apps/docs/content/docs/en/introduction/index.mdx b/apps/docs/content/docs/en/introduction/index.mdx
index 3a8f3ec1795..b953b86665b 100644
--- a/apps/docs/content/docs/en/introduction/index.mdx
+++ b/apps/docs/content/docs/en/introduction/index.mdx
@@ -9,7 +9,7 @@ import { Image } from '@/components/ui/image'
import { Video } from '@/components/ui/video'
import { FAQ } from '@/components/ui/faq'
-Sim is the open-source AI workspace where teams build, deploy, and manage AI agents. You build by describing what you want to **Mothership**, the natural-language control plane, or visually in the workflow builder, or programmatically with the API. Connect AI models, databases, APIs, and 1,000+ business tools to build agents that automate real work.
+Sim is the open-source AI workspace where teams build, deploy, and manage AI agents. You build by describing what you want in **Chat**, visually in the workflow builder, or programmatically with the API. Connect AI models, databases, APIs, and 1,000+ business tools to build agents that automate real work.
-Mothership generates the architecture, and you verify the execution. Even when you build conversationally, it helps to understand the resources Mothership creates, so you can inspect, run, and improve them.
-
## The anatomy of a workspace
-A Sim system is not a single chat response. It is a set of resources that live in a **workspace** and connect to each other. The sidebar mirrors that anatomy, and these are its parts.
+A Sim system is a set of resources that live in a **workspace** and connect to each other. These are its parts:
-- **[Mothership](/mothership)** is the natural-language control plane. You describe what you want, and it builds and edits the resources for you.
+- **[Chat](/chat)** is where you build conversationally. You describe what you want, and Sim builds and edits the resources for you.
- **[Workflows](/workflows)** are visual programs made of blocks, where your logic runs. Most other resources become useful through a workflow.
-- **[Agents and tools](/agents)** are how a workflow acts. An agent reasons with a model, and tools let it take actions like sending an email or querying an API.
+- **[Agents and tools](/agents)** are how a workflow acts. An agent reasons with a model, and tools let it take actions like sending an email or querying an API. These are agents *you* build — distinct from Sim itself working for you in Chat.
- **[Tables](/tables)** hold structured rows your workflows read, write, and process.
- **[Knowledge bases](/knowledgebase)** are searchable memory. An agent retrieves relevant passages from your documents to ground its answers.
- **[Files](/files)** are the documents and media your workflows store, read, and produce.
@@ -54,25 +51,18 @@ A Sim system is not a single chat response. It is a set of resources that live i
## What you can build
-- **AI assistants and chatbots.** Conversational agents that search the web, manage calendars, send email, and act on your business systems.
-- **Business process automation.** Data entry, report generation, customer responses, and content workflows.
-- **Data processing and analysis.** Extract from documents, analyze datasets, and sync data across platforms.
-- **API integration workflows.** Unified endpoints that orchestrate multi-service logic and event-driven automation.
+- **Assistants and chatbots.** A support agent that answers from your docs, or a Slack bot that searches the web and acts on your systems.
+- **Process automation.** Invoice extraction into a billing table, lead scoring and outreach, weekly report generation.
+- **Data pipelines.** Pull from a CRM, enrich each record with an agent, and write the results back to a table.
+- **Unified APIs.** One endpoint that orchestrates several services and models behind a single call.
## Integrations
-Sim provides native integrations with 1,000+ services:
-
-- **AI models.** OpenAI, Anthropic, Google Gemini, Groq, Cerebras, and local models via Ollama or VLLM.
-- **Communication.** Gmail, Slack, Microsoft Teams, Telegram, WhatsApp.
-- **Productivity.** Notion, Google Workspace, Airtable.
-- **Development.** GitHub, Jira, Linear, automated browser testing.
-- **Search and data.** Google Search, Perplexity, Firecrawl, Exa AI.
-- **Databases.** PostgreSQL, MySQL, Supabase, Pinecone, Qdrant.
+Sim has native integrations with 1,000+ services — every major AI model provider, and the communication, productivity, development, search, and database tools your work already runs on. Browse the full catalog at [Integrations](/integrations).
For anything not built in, [MCP support](/agents/mcp) connects any external service or tool.
-## Deployment options
+## Hosting
- **Cloud-hosted.** Launch immediately at [sim.ai](https://sim.ai) with managed infrastructure, scaling, and observability.
- **Self-hosted.** Deploy on your own infrastructure with Docker Compose or Kubernetes, with support for local models.
@@ -83,7 +73,7 @@ For anything not built in, [MCP support](/agents/mcp) connects any external serv
Build your first agent in 10 minutes
-
+
Create and operate your workspace in natural language
@@ -98,9 +88,9 @@ For anything not built in, [MCP support](/agents/mcp) connects any external serv
{ question: "Is Sim free to use?", answer: "Sim offers a free Community plan with 1,000 one-time credits to get started. Paid plans start at $25/month (Pro) with 5,000 credits and go up to $100/month (Max) with 20,000 credits. Annual billing is available at a 15% discount. You can also self-host Sim for free on your own infrastructure." },
{ question: "Is Sim open source?", answer: "Yes. Sim is open source under the Apache 2.0 license. The full source code is available on GitHub and you can self-host it, contribute to development, or modify it for your own needs. Enterprise features (SSO, access control) have a separate license that requires a subscription for production use." },
{ question: "Which AI models and providers are supported?", answer: "Sim supports 15+ providers including OpenAI, Anthropic, Google Gemini, Groq, Cerebras, DeepSeek, Mistral, xAI, and OpenRouter. You can also run local models through Ollama or VLLM at no API cost. Bring Your Own Key (BYOK) is supported so you can use your own API keys at base provider pricing with no markup." },
- { question: "Do I need coding experience to use Sim?", answer: "No. Sim lets you build agents conversationally through Mothership using natural language, or visually by connecting blocks in the workflow builder. For advanced use cases, the Function block lets you write custom JavaScript, and the full API/SDK is available for programmatic access." },
+ { question: "Do I need coding experience to use Sim?", answer: "No. Sim lets you build agents conversationally in Chat using natural language, or visually by connecting blocks in the workflow builder. For advanced use cases, the Function block lets you write custom JavaScript, and the full API/SDK is available for programmatic access." },
{ question: "Can I self-host Sim?", answer: "Yes. Sim provides Docker Compose configurations for self-hosted deployments. The stack includes the Sim application, a PostgreSQL database with pgvector, and a realtime collaboration server. You can also integrate local AI models via Ollama for a fully offline setup." },
{ question: "Is there a limit on how many workflows I can create?", answer: "There is no limit on the number of workflows you can create on any plan. Usage limits apply to execution credits, rate limits, and file storage, which vary by plan tier." },
{ question: "What integrations are available?", answer: "Sim offers 1,000+ native integrations across categories including AI models, communication tools (Gmail, Slack, Teams, Telegram), productivity apps (Notion, Google Workspace, Airtable), development tools (GitHub, Jira, Linear), search services (Google Search, Perplexity, Exa), and databases (PostgreSQL, Supabase, Pinecone). For anything not built in, you can use the MCP (Model Context Protocol) support to connect custom services." },
- { question: "How does Sim compare to other AI agent builders?", answer: "Sim is an AI workspace, not just a workflow tool or an agent framework. It combines Mothership for natural-language agent creation, a visual workflow builder, knowledge bases, tables, and full observability in one environment. Teams build agents visually, conversationally, or with code, then deploy and manage them with enterprise governance, real-time collaboration, and staging-to-production workflows." },
+ { question: "How does Sim compare to other AI agent builders?", answer: "Sim is an AI workspace, not just a workflow tool or an agent framework. It combines natural-language building in Chat, a visual workflow builder, knowledge bases, tables, and full observability in one environment. Teams build agents visually, conversationally, or with code, then deploy and manage them with enterprise governance, real-time collaboration, and staging-to-production workflows." },
]} />
diff --git a/apps/docs/content/docs/en/knowledgebase/index.mdx b/apps/docs/content/docs/en/knowledgebase/index.mdx
index f0d14803755..cc881ba72e3 100644
--- a/apps/docs/content/docs/en/knowledgebase/index.mdx
+++ b/apps/docs/content/docs/en/knowledgebase/index.mdx
@@ -7,6 +7,7 @@ pageType: concept
import { Video } from '@/components/ui/video'
import { Card, Cards } from 'fumadocs-ui/components/card'
import { FAQ } from '@/components/ui/faq'
+import { TryInChat } from '@/components/ui/try-in-chat'
A **knowledge base** is a store of documents your agents can search by meaning. You upload files, Sim splits them into chunks and indexes them, and a [Knowledge block](/knowledgebase/using-in-workflows) retrieves the chunks most relevant to a query. This is how an agent answers from your own content instead of the model's general training.
@@ -37,6 +38,34 @@ Two things control retrieval quality, and each has its own page:
To keep a base in sync with an outside source like Google Drive, use a [connector](/knowledgebase/connectors).
+## In chat [#in-chat]
+
+You can also build and query a knowledge base by asking Sim in [Chat](/chat): create one, add documents to it, and ask questions against its content in plain language.
+
+
+
+
+
+
+
+
+
+Sim runs the same indexing and search described on this page, so anything it creates is immediately usable from the [Knowledge block](/knowledgebase/using-in-workflows) in a workflow.
+
## Next
diff --git a/apps/docs/content/docs/en/logs-debugging/index.mdx b/apps/docs/content/docs/en/logs-debugging/index.mdx
index bc111469978..810bef52cd1 100644
--- a/apps/docs/content/docs/en/logs-debugging/index.mdx
+++ b/apps/docs/content/docs/en/logs-debugging/index.mdx
@@ -24,7 +24,7 @@ The **Logs page** lists every run across your workspace, one row per run. The [L
### The run
-Each row on the Logs page is one **run**. It records the **trigger** that started it (manual, api, schedule, chat, webhook, mcp, mothership, copilot, workflow, or a2a), a **status**, a **duration**, and the **cost** in credits. It also carries an **execution ID** that uniquely names the run.
+Each row on the Logs page is one **run**. It records the **trigger** that started it (manual, api, schedule, chat, webhook, mcp, mothership, copilot, workflow, or a2a — `mothership` and `copilot` are legacy values for what is now Chat), a **status**, a **duration**, and the **cost** in credits. It also carries an **execution ID** that uniquely names the run.
The status shows the run's outcome at a glance, with failed runs badged **Error**. When you are hunting a failure, you filter the list to the errors and start there.
@@ -90,7 +90,7 @@ When a value is the wrong shape, reshape it in a [Function](/workflows/blocks/fu
## AI-assisted debugging
-Mothership and Copilot can read a run's logs and propose a fix from the trace: the error message, the input the block received, and the output the upstream block produced. The logs stay the ground truth. You confirm a proposed fix the same way you confirm your own: rerun the workflow and compare the new trace against the failed one.
+Ask Sim in Chat to read a run's logs and it can propose a fix from the trace: the error message, the input the block received, and the output the upstream block produced. The logs stay the ground truth. You confirm a proposed fix the same way you confirm your own: rerun the workflow and compare the new trace against the failed one.
## Retention
diff --git a/apps/docs/content/docs/en/meta.json b/apps/docs/content/docs/en/meta.json
index 5d11bb02c2a..7e4e74f0309 100644
--- a/apps/docs/content/docs/en/meta.json
+++ b/apps/docs/content/docs/en/meta.json
@@ -4,12 +4,17 @@
"---Get Started---",
"./introduction/index",
"./getting-started/index",
+ "---Chat---",
+ "./chat/index",
+ "./chat/tasks",
+ "./chat/mailer",
"---Workflows---",
"./workflows/index",
"./workflows/how-it-runs",
"./workflows/data-flow",
"./workflows/connections",
"./workflows/variables",
+ "./workflows/building-in-chat",
"workflows/deployment",
"workflows/triggers",
"workflows/blocks",
@@ -41,15 +46,6 @@
"./logs-debugging/index",
"./logs-debugging/logging",
"./logs-debugging/alerts",
- "---Mothership---",
- "./mothership/index",
- "./mothership/workflows",
- "./mothership/research",
- "./mothership/files",
- "./mothership/tables",
- "./mothership/tasks",
- "./mothership/knowledge",
- "./mothership/mailer",
"---Platform---",
"./platform/workspaces",
"./platform/organization",
diff --git a/apps/docs/content/docs/en/mothership/files.mdx b/apps/docs/content/docs/en/mothership/files.mdx
deleted file mode 100644
index 64eb36960e1..00000000000
--- a/apps/docs/content/docs/en/mothership/files.mdx
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Files & documents
-description: Upload, create, edit, and generate files — documents, presentations, images, and more.
----
-
-import { Image } from '@/components/ui/image'
-import { Video } from '@/components/ui/video'
-import { FAQ } from '@/components/ui/faq'
-
-
-
-Describe a document, presentation, image, or visualization and Mothership creates it — streaming the content live into the resource panel as it writes. Attach any file to your message and Mothership reads it, processes it, and saves it to your workspace.
-
-## Uploading Files to the Workspace
-
-Attach any file directly to your Mothership message — drag it into the input, paste it, or click the attachment icon. Mothership reads the file as context and saves it to your workspace.
-
-Use this to:
-- Hand Mothership a document and ask it to process, summarize, or extract data from it
-- Upload a CSV and have it create a table from it
-- Drop in a PDF and ask Mothership to turn it into a knowledge base document
-- Attach a design mockup and ask Mothership to describe it or generate code from it
-
-Uploaded files appear in the Files panel in the sidebar and are accessible to all workflows in the workspace. Mothership can also fetch a file directly from a URL and save it for you: "Download the JSON at [URL] and save it to the workspace."
-
-## Creating Documents
-
-Mothership can write any text-based file — markdown, plain text, code files, CSV, JSON, or any other format:
-
-- "Write a technical spec for the new auth system as a markdown file"
-- "Create a CSV of our test accounts with columns for name, email, and plan tier"
-- "Write a Python script that calls our workflow API and processes the response"
-- "Draft a postmortem for the outage last Tuesday and save it as a markdown file"
-- "Write a personalized outbound email for Acme Corp based on their recent funding announcement"
-- "Draft a weekly ops digest summarizing workflow run counts, errors, and top failures for the past 7 days"
-
-Files are saved to your workspace and accessible from the Files panel in the sidebar.
-
-## Editing Existing Files
-
-Open a file using `@filename` or the **+** menu, then describe the change:
-
-- "Update the pricing section to reflect the new tiers"
-- "Refactor this Python script to use async/await"
-- "Add a section on error handling to this spec"
-- "Rewrite the introduction of this report to be more concise"
-
-## Presentations
-
-
-
-Mothership can generate `.pptx` files:
-
-- "Create a pitch deck for Q3 review — 8 slides covering growth, retention, and roadmap"
-- "Turn this research report into a 10-slide presentation"
-- "Build a deck that walks through our API onboarding flow"
-- "Build a battle card deck for our top 3 competitors — one slide each covering positioning, pricing, and how we win"
-- "Create an account plan for Acme Corp — their priorities, our solution fit, and proposed next steps"
-
-The file is saved to your workspace and can be downloaded.
-
-## Images
-
-Mothership can generate images using AI, and can use an existing image as a reference to guide the output:
-
-**Generating images:**
-- "Generate a banner image for the new feature announcement — dark background, clean typography"
-- "Create a diagram showing the data flow through our webhook pipeline"
-- "Make a social card for the blog post with the title and author name"
-
-**Using a reference image:**
-- Attach an existing image to your message, then describe what you want: "Generate a new version of this banner with a blue color scheme instead of green"
-- "Create a variation of this diagram with the boxes rearranged horizontally [attach image]"
-
-
-
-Generated images are saved as workspace files.
-
-## Charts and Visualizations
-
-Mothership can generate charts and data visualizations from data you describe or reference:
-
-- "Plot the workflow run counts from the metrics table as a bar chart grouped by week"
-- "Create a line chart of token usage over the past 30 days from this data [paste data]"
-- "Generate a pie chart showing the distribution of lead sources from the leads table"
-
-
-
-Visualizations are saved as files and rendered in the resource panel.
-
-## Calculations & Data Processing
-
-For one-off calculations and data transformations, describe what you need and Mothership runs it directly in the chat:
-
-- "Parse this JSON and extract all records where status is 'failed'"
-- "Calculate the p95 latency from these timing values: [paste values]"
-- "Convert these Unix timestamps to ISO 8601"
-- "Deduplicate this list of emails, case-insensitive"
-
-Results come back directly in the chat. Ask Mothership to save the output as a file if you need it.
-
-## File Viewer Modes
-
-When a file opens in the resource panel, you can switch between three views:
-
-
-
-| Mode | What it shows |
-|------|--------------|
-| **Editor** | Raw editable text |
-| **Preview** | Rendered output (markdown, HTML) |
-| **Split** | Editor and preview side by side |
-
-
diff --git a/apps/docs/content/docs/en/mothership/index.mdx b/apps/docs/content/docs/en/mothership/index.mdx
deleted file mode 100644
index 3f61f20df5a..00000000000
--- a/apps/docs/content/docs/en/mothership/index.mdx
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Building with Mothership
-description: Your AI command center. Build and manage your entire workspace in natural language.
----
-
-import { Image } from '@/components/ui/image'
-import { Video } from '@/components/ui/video'
-import { FAQ } from '@/components/ui/faq'
-
-
-
-Describe what you want and Mothership handles it. Build a workflow, run research, generate a presentation, query a table, schedule a recurring job, send a Slack message — Mothership knows your entire workspace and takes action directly.
-
-## What You Can Do
-
-| Area | What Mothership can do |
-|------|-----------------------|
-| **[Workflows](/mothership/workflows)** | Build, edit, run, debug, deploy, and organize workflows |
-| **[Research](/mothership/research)** | Search the web, read pages, crawl sites, produce research reports |
-| **[Files & Documents](/mothership/files)** | Upload, create, edit, and generate documents, presentations, and images |
-| **[Tables](/mothership/tables)** | Create, query, update, and export workspace tables |
-| **[Automation & Configuration](/mothership/tasks)** | Schedule jobs, take immediate actions, connect integrations, manage tools |
-| **[Knowledge Bases](/mothership/knowledge)** | Create knowledge bases, add documents, and query content in plain language |
-
-## How It Works
-
-Mothership receives a snapshot of your entire workspace with every message — all workflows, tables, knowledge bases, files, credentials, jobs, and integrations. This is why you can refer to things by name without specifying IDs or paths:
-
-- "Run the invoice workflow"
-- "Add a row to the leads table"
-- "Deploy the summarizer as a chat"
-
-No configuration, no context-setting. Just describe what you want:
-
-- "Build a lead enrichment workflow that scores inbound signups and writes the results to the leads table"
-- "Research our top 5 competitors and save a battle card for each one"
-- "Schedule a daily job that checks for new high-fit prospects and posts them to #outbound in Slack"
-- "Create a workflow that takes a contract PDF, extracts the key terms, and emails a summary to legal"
-
-For complex tasks, Mothership delegates to specialized subagents automatically. You'll see them appear as collapsible sections in the chat while they work — building, researching, writing files, executing actions.
-
-{/* TODO: Screenshot of the Mothership chat showing a subagent section expanded mid-task — e.g., the Build or Research subagent actively working, with its collapsible header and steps visible in the thread. */}
-
-## Adding Context
-
-Bring any workspace object into the conversation via the **+** menu, `@`-mentions, or drag-and-drop from the sidebar. Mothership also opens resources automatically when it creates or modifies them.
-
-
-
-{/* TODO: Screenshot of the resource panel with multiple tabs open — a workflow tab, a table tab, and a file tab — showing different resource types side by side. */}
-
-| What to add | How it appears |
-|-------------|---------------|
-| **Workflow** | Interactive canvas in the resource panel |
-| **Table** | Full table editor in the resource panel |
-| **File** | File viewer with editor, split, and preview modes |
-| **Knowledge Base** | Knowledge base management UI |
-| **Folder** | Folder contents |
-| **Past task** | A previous Mothership conversation |
-
-## Layout
-
-Mothership has two panes. On the left: the chat thread, where your messages and Mothership's responses appear. On the right: the resource panel, where workflows, tables, files, and knowledge bases open as tabs. The panel is resizable; tabs are draggable and closeable.
-
-
-
-
diff --git a/apps/docs/content/docs/en/mothership/knowledge.mdx b/apps/docs/content/docs/en/mothership/knowledge.mdx
deleted file mode 100644
index 41c1edbb5d8..00000000000
--- a/apps/docs/content/docs/en/mothership/knowledge.mdx
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: Knowledge bases
-description: Create, populate, and query knowledge bases from Mothership.
----
-
-import { Image } from '@/components/ui/image'
-import { Video } from '@/components/ui/video'
-import { FAQ } from '@/components/ui/faq'
-
-
-
-Create a knowledge base, add documents to it, and query it in plain language — all through conversation. Knowledge bases you create in Mothership are immediately available to Agent blocks in any workflow.
-
-## Creating Knowledge Bases
-
-Describe the knowledge base and Mothership creates it:
-
-- "Create a knowledge base called 'Product Docs'"
-- "Set up a knowledge base for our support team — call it 'Support KB'"
-- "Create a competitive intelligence knowledge base"
-- "Create a knowledge base from our sales playbook and attach it to the outbound agent workflow"
-- "Set up a customer success knowledge base — I'll add our onboarding guides and past case studies to it"
-
-## Adding Documents
-
-Add documents by attaching files to your message, pasting text, or pointing Mothership at a URL:
-
-- "Add this PDF to the Product Docs knowledge base [attach file]"
-- "Add the following text to the Support KB as a new document: [paste content]"
-- "Fetch the page at [URL] and add it to the competitive intelligence knowledge base"
-- "Add these three uploaded case studies to the customer success knowledge base"
-
-Mothership processes and indexes each document automatically. Once indexed, the content is searchable by any Agent block that has the knowledge base attached.
-
-{/* TODO: Screenshot of Mothership confirming a document was added and indexed — showing the document name and its indexed status in the knowledge base. */}
-
-## Querying Knowledge Bases
-
-Ask Mothership a question and it searches the specified knowledge base to answer:
-
-- "What does the Product Docs knowledge base say about our refund policy?"
-- "Search the Support KB for anything related to SSO setup errors"
-- "What are the key differences between our Pro and Enterprise plans, based on the product docs?"
-- "Find everything in the competitive intelligence knowledge base about [competitor]'s pricing"
-
-## Connectors
-
-For knowledge bases that should stay current automatically, connectors sync content from external services on a schedule — no manual uploads needed. New content is added, changed content is re-processed, and deleted content is removed on every run.
-
-Connectors are configured through the knowledge base settings, not through Mothership chat. Once connected, all synced content is immediately searchable by Mothership and by any Agent block with the knowledge base attached.
-
-Sim ships with 49 built-in connectors, including Notion, Google Drive, Slack, GitHub, Confluence, HubSpot, Salesforce, Gmail, and more.
-
-Examples of what you can sync:
-
-- **Notion** — sync a workspace, a database, or a specific page tree
-- **Google Drive / Dropbox / OneDrive** — sync documents from cloud storage
-- **GitHub** — sync a repository's markdown and code files
-- **Slack** — sync channel history
-- **Confluence / Jira** — sync your internal wiki or issue tracker
-- **HubSpot / Salesforce** — sync CRM records into a searchable knowledge base
-
-See [Connectors](/knowledgebase/connectors) for setup steps, sync frequency options, and managing connector status.
-
-## Managing Knowledge Bases
-
-List, inspect, and clean up knowledge bases in plain language:
-
-- "What knowledge bases are in this workspace?"
-- "How many documents are in the Support KB?"
-- "Remove the outdated pricing doc from the Product Docs knowledge base"
-- "Delete the old-competitive-intel knowledge base"
-
-## Using Knowledge Bases in Workflows
-
-Knowledge bases created in Mothership are immediately available to Agent blocks in any workflow. Attach a knowledge base to an Agent block and it will use semantic search to retrieve relevant content at runtime.
-
-See [Knowledge Base](/knowledgebase) for full details on document processing settings, search configuration, and connector syncing.
-
-
diff --git a/apps/docs/content/docs/en/mothership/meta.json b/apps/docs/content/docs/en/mothership/meta.json
deleted file mode 100644
index 767005e2f25..00000000000
--- a/apps/docs/content/docs/en/mothership/meta.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "title": "Mothership",
- "pages": ["index", "workflows", "research", "files", "tables", "tasks", "knowledge"]
-}
diff --git a/apps/docs/content/docs/en/mothership/research.mdx b/apps/docs/content/docs/en/mothership/research.mdx
deleted file mode 100644
index 19fd72c5bd0..00000000000
--- a/apps/docs/content/docs/en/mothership/research.mdx
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Research
-description: Ask Mothership to research anything — it searches, reads, and synthesizes from the web.
----
-
-import { Image } from '@/components/ui/image'
-import { Video } from '@/components/ui/video'
-import { FAQ } from '@/components/ui/faq'
-
-
-
-Ask Mothership to research anything and it figures out the best approach — searching the web, reading specific pages, crawling sites, looking up technical docs. Just describe what you want to know.
-
-## Asking Questions
-
-Ask anything — about a company, a competitor, a market, a technical question, or a specific URL:
-
-- "What did Salesforce, HubSpot, and Gong each ship in the past 30 days? Summarize the key product updates."
-- "What's Acme Corp's tech stack, recent hires, and open engineering roles?"
-- "Find everything published about [competitor] in the past 90 days — press, product changes, job postings."
-- "What are the current rate limits on the Anthropic API?"
-- "Read [URL] and tell me what changed in this release"
-- "What does Stripe's API say about handling webhooks with idempotency keys?"
-- "Who are the main players in AI-powered revenue operations, and how do they differentiate?"
-
-Mothership returns an answer directly in the chat. For anything that needs a longer written output, ask it to save the result as a file.
-
-## Research Reports
-
-When you need a structured, saved document rather than a chat answer, ask Mothership to write it up. It searches, reads, and cross-references multiple sources until it has enough to produce a full report. The output is saved as a file in your workspace and opened in the resource panel.
-
-{/* TODO: Screenshot of a completed research report open in the resource panel as a file — showing a structured markdown document with sections, findings, and citations. */}
-
-- "Research the top 10 AI SDR tools — pricing, features, positioning, and what customers say. Save as a competitive analysis."
-- "Do a full market landscape for AI in healthcare diagnostics — major players, funding, use cases, and regulatory environment."
-- "Research how our top 5 competitors handle multi-tenant auth — pricing, architecture, and any known vulnerabilities. Write it up as a report."
-- "Find every public case study on AI agents in financial compliance from the past 2 years. Summarize the key outcomes and save as a markdown file."
-- "Build a battle card for [competitor] — their positioning, pricing, strengths, weaknesses, and how we win against them."
-
-
diff --git a/apps/docs/content/docs/en/mothership/tables.mdx b/apps/docs/content/docs/en/mothership/tables.mdx
deleted file mode 100644
index dfe97a7f2a6..00000000000
--- a/apps/docs/content/docs/en/mothership/tables.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Tables
-description: Create, query, and manage workspace tables from Mothership.
----
-
-import { Image } from '@/components/ui/image'
-import { FAQ } from '@/components/ui/faq'
-
-
-
-Create a table from a description or a CSV, query it in plain language, add or update rows, and export the results — all through conversation. Tables open in the resource panel as soon as they're created or referenced.
-
-## Creating Tables
-
-Describe the schema and Mothership creates the table:
-
-- "Create a leads table with columns for name, email, company, status, and created date"
-- "Create a table that matches the structure of this CSV [attach file]"
-- "Set up an errors table with: id (text), message (text), workflow (text), timestamp (date), resolved (boolean)"
-- "Create a prospect table for outbound — company, domain, employee count, industry, ICP score, and last contacted date"
-- "Set up an enrichment results table to store output from the lead enrichment workflow: email, company, title, LinkedIn URL, fit score"
-
-## Querying Data
-
-Ask questions about table contents in plain language:
-
-- "How many rows in the leads table have status 'qualified'?"
-- "Show me all records from the past 7 days where score is above 0.8"
-- "What are the top 5 most common error messages in the failures table?"
-- "Are there any duplicate emails in the contacts table?"
-- "How many prospects have an ICP score above 0.75 and haven't been contacted in the past 30 days?"
-- "What's the conversion rate from 'contacted' to 'meeting booked' in the pipeline table this month?"
-
-Mothership translates the question into a structured query and returns the results.
-
-## Adding and Updating Rows
-
-Add individual rows, bulk-update based on a condition, or delete records — all in plain language:
-
-- "Add a row to the leads table: Acme Corp, jane@acme.com, status pending"
-- "Mark all rows in the queue table as processed where created_at is before today"
-- "Update the price column for all rows where tier is 'pro' to 49"
-- "Delete all rows in the test_events table"
-
-## Exporting
-
-Export a full table or a filtered subset as a CSV. The file is saved to your workspace and can be downloaded or referenced in other workflows:
-
-- "Export the leads table to a CSV"
-- "Export all rows where status is 'closed' and save as a file"
-
-## Using Tables in Workflows
-
-Tables created in Mothership are immediately available in workflows via the [Table tool](/integrations/table). Reference a table by name — no additional configuration needed.
-
-
diff --git a/apps/docs/content/docs/en/mothership/tasks.mdx b/apps/docs/content/docs/en/mothership/tasks.mdx
deleted file mode 100644
index dedce2ec84d..00000000000
--- a/apps/docs/content/docs/en/mothership/tasks.mdx
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: Automation & configuration
-description: Schedule recurring jobs, take immediate actions, connect integrations, and configure your workspace.
----
-
-import { Callout } from 'fumadocs-ui/components/callout'
-import { Image } from '@/components/ui/image'
-import { Video } from '@/components/ui/video'
-import { FAQ } from '@/components/ui/faq'
-
-
-
-Mothership can act on your behalf right now — send a message, create an issue, call an API — or on a schedule, running a prompt automatically every hour, day, or week. It can also connect integrations, set environment variables, add MCP servers, and create custom tools.
-
-## Scheduled Jobs
-
-A scheduled job is a Mothership task that runs on a cron schedule. On each run, Mothership reads the current workspace state and executes the job's prompt as if you had just sent it.
-
-### Creating a Job
-
-Describe the recurring task and how often it should run:
-
-- "Every morning at 8am, check the leads table for new entries and post a summary to #sales in Slack"
-- "Every Monday at 9am, pull last week's workflow run counts and write a report to the workspace"
-- "Run the data sync workflow every 6 hours"
-- "On the first of every month, export the billing table to CSV and email it to finance@example.com"
-- "Every weekday at 7am, check for new funding announcements from companies in our ICP and post the top 5 to #market-intel in Slack"
-- "Every Sunday night, run the lead enrichment workflow on all prospects added in the past week and update their scores in the table"
-- "Daily at 6am, pull the previous day's workflow errors, summarize the top issues, and post to #eng-alerts"
-
-Mothership sets the cron expression and stores the job prompt. The first run happens at the next scheduled time.
-
-### Viewing Job Logs
-
-- "Show me the last 5 runs of the weekly report job"
-- "Did the sync job run successfully this morning?"
-- "What did the Monday digest job do last week?"
-
-Logs show run time, status (completed, failed), and a summary of what the agent did.
-
-### Managing Jobs
-
-- "Pause the morning summary job"
-- "Change the sync job to run every 3 hours instead of 6"
-- "Delete the onboarding digest job"
-- "What scheduled jobs are currently active?"
-
-## Taking Direct Action
-
-For requests that should happen right now — without building a workflow — just ask. Mothership acts immediately using the credentials connected to your workspace.
-
-{/* TODO: Screenshot of Mothership chat showing the "Taking action" subagent label active during a direct action — e.g., posting to Slack or sending an email. Shows the subagent inline in the chat thread. */}
-
-| Request | What happens |
-|---------|-------------|
-| "Send a Slack message to #eng that the deploy finished" | Posts to Slack immediately |
-| "Email the Q3 report to jane@example.com" | Sends via connected Gmail or Outlook |
-| "Create a GitHub issue: auth tokens not rotating on logout" | Opens an issue in the specified repo |
-| "Add a contact to HubSpot: Acme Corp, ceo@acme.com" | Creates the contact via HubSpot API |
-| "Call the webhook at [URL] with this JSON payload" | Makes the HTTP request |
-
-If an integration isn't connected, Mothership walks you through connecting it.
-
-## Connecting Integrations
-
-Mothership can connect new OAuth integrations and API credentials on demand:
-
-- "Connect my Google account"
-- "Add the Slack workspace for our team"
-- "Set up GitHub with my personal access token"
-
-{/* TODO: Screenshot of Mothership walking through connecting an integration — e.g., the Integration subagent active with an OAuth prompt or confirmation that a credential was connected. */}
-
-Once connected, credentials are available to Mothership for direct actions and scheduled jobs, and to all workflows in the workspace.
-
-
- Connected credentials are shared across the workspace. Any workflow that uses the same integration will automatically use the same credential.
-
-
-See [Credentials](/platform/credentials) for managing connected accounts.
-
-## Environment Variables
-
-Environment variables are workspace-scoped values — API keys, connection strings, and configuration that workflows reference via `{{ENV_VAR}}` syntax rather than hardcoding. Set them once and every workflow in the workspace can use them.
-
-- "Set the DATABASE_URL environment variable to 'postgres://...'"
-- "Add an OPENAI_API_KEY environment variable"
-- "Add a WEBHOOK_SECRET variable for the inbound webhook workflow"
-- "Update the SCORING_API_URL variable to point to the new endpoint"
-- "What environment variables are currently set?"
-
-{/* TODO: Screenshot of Mothership confirming an environment variable was set — e.g., a response message showing the variable name was saved. */}
-
-## MCP Servers
-
-MCP (Model Context Protocol) servers expose tools from external services that Agent blocks can call inside workflows. Connecting an MCP server makes all of its tools available in the workflow editor's tool picker — no custom integration code required.
-
-Mothership can add and manage MCP servers connected to your workspace:
-
-- "Add the Stripe MCP server using my API key"
-- "Remove the old analytics MCP server"
-- "What MCP servers are connected to this workspace?"
-- "Update the endpoint for the internal tools MCP server to [URL]"
-
-Once added, MCP tools appear in the workflow editor's tool picker and can be called from any Agent block.
-
-{/* TODO: Screenshot of Mothership confirming an MCP server was added or updated — showing the server name and its status. */}
-
-## Custom Tools
-
-Custom tools are single HTTP endpoints you define manually — useful for internal APIs and services that don't have a built-in Sim integration or an MCP server. Once created, they appear in the workflow editor alongside built-in tools and can be called from any Agent block.
-
-Mothership can build custom tools from a description:
-
-- "Create a custom tool that calls our internal scoring API at [URL] with a POST request and returns the score field"
-- "Build a tool for our Zendesk instance that creates a ticket with a subject and body"
-- "Create a tool that hits our internal enrichment API with a domain and returns company size, industry, and funding stage"
-- "Add a tool that calls our CRM's REST API to look up a contact by email and return their account owner"
-
-Custom tools appear in the workflow editor and are callable from any Agent block alongside built-in tools.
-
-{/* TODO: Screenshot of Mothership with the Custom Tool subagent active — showing it building a tool definition. */}
-
-
diff --git a/apps/docs/content/docs/en/mothership/workflows.mdx b/apps/docs/content/docs/en/mothership/workflows.mdx
deleted file mode 100644
index 44ea4e33961..00000000000
--- a/apps/docs/content/docs/en/mothership/workflows.mdx
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: Workflows
-description: Create, edit, run, debug, deploy, and organize workflows from Mothership.
----
-
-import { Image } from '@/components/ui/image'
-import { Video } from '@/components/ui/video'
-import { FAQ } from '@/components/ui/faq'
-
-
-
-Describe a workflow and Mothership builds it. Reference an existing one by name and it edits it. No canvas navigation required — every change appears in the resource panel in real time.
-
-## Creating Workflows
-
-Describe what the workflow should do — what triggers it, what it should do, which integrations it needs, and what it should return. Mothership builds it and opens the canvas in the resource panel.
-
-- "Build a workflow that takes a URL, scrapes the page, summarizes it with Claude, and sends the summary to a Slack channel"
-- "Create a workflow triggered by a webhook that extracts invoice data from a PDF and writes it to the billing table"
-- "Build an outbound workflow: take a company name and domain, enrich it with firmographic data, score the fit, and draft a personalized cold email"
-- "Create a lead enrichment workflow that takes an email from a form submission, looks up the company, and writes the enriched record to the leads table"
-- "Build a customer onboarding workflow: when a new user signs up, send a welcome email, create a HubSpot contact, and post a notification to #new-customers in Slack"
-
-## Editing Workflows
-
-{/* TODO: Screenshot of Mothership with the Edit subagent active and a change applied to an open workflow — e.g., a new block added or a configuration updated, visible on the canvas in the resource panel. */}
-
-Open an existing workflow with `@workflow-name` or the **+** menu, then describe the change. Mothership reads the current structure before modifying it — you don't need to explain what already exists.
-
-- "Add a condition that routes to a different branch if the confidence score is below 0.7"
-- "Replace the GPT-4o model with Claude Opus 4.6 on the summarizer block"
-- "Add a Slack notification at the end that includes the output"
-
-## Running Workflows
-
-
-
-Ask Mothership to run a workflow and it handles the execution:
-
-- "Run the data sync workflow"
-- "Run the invoice processor with this PDF [attach file]"
-- "Test the lead scoring workflow with these inputs: name=Acme, score=0.4"
-
-Execution streams back to the chat. The workflow in the resource panel shows live block-by-block state.
-
-## Reading Logs
-
-Mothership can retrieve and interpret execution logs for any workflow in the workspace:
-
-- "Show me the last 10 runs of the pipeline workflow"
-- "Why did the invoice workflow fail yesterday?"
-- "What did the extractor block return in the most recent run?"
-
-Logs include per-block execution state, outputs, errors, and timing.
-
-## Debugging
-
-When a workflow fails, tell Mothership to debug it:
-
-- "Debug the last failed run of the content pipeline"
-- "The summarizer block is returning empty output — figure out why"
-
-Mothership reads the failure logs, identifies the cause, applies a fix, and can re-run to confirm.
-
-{/* TODO: Screenshot of the Debug subagent section in the Mothership chat showing it reading logs and applying a fix. */}
-
-## Deploying
-
-Mothership can deploy a workflow as any of the three deployment types:
-
-| Deployment type | What it creates |
-|----------------|----------------|
-| **API** | A REST endpoint at `https://sim.ai/api/workflows/{id}/execute` |
-| **Chat** | A hosted conversational interface with a shareable URL |
-| **MCP tool** | An MCP server that exposes the workflow as a tool |
-
-Ask: "Deploy the invoice workflow as an API and generate an API key."
-
-Mothership can also roll back: "Revert the billing workflow to the version from last Tuesday."
-
-See [API Deployment](/workflows/deployment/api) and [Chat Deployment](/workflows/deployment/chat) for full details on each deployment type.
-
-## Organizing Workflows
-
-Mothership can create and manage folders to keep your workspace organized.
-
-**Folders:**
-- "Create a folder called 'Data Pipelines'"
-- "Move the invoice workflow into the billing folder"
-- "Move the billing folder inside the finance folder"
-- "Delete the old-experiments folder"
-
-**Renaming and moving:**
-- "Rename the 'test_v2' workflow to 'lead-scorer'"
-- "Move the summarizer workflow to the research folder"
-
-{/* TODO: Screenshot showing Mothership confirming a folder or workflow organization action — e.g., a message confirming "Moved 'invoice-processor' into 'billing' folder" with the resource panel showing the folder open. */}
-
-## Workflow Variables
-
-Mothership can set global variables on a workflow — values accessible across all blocks in that workflow at runtime:
-
-- "Set the API_ENDPOINT variable on the sync workflow to 'https://api.example.com/v2'"
-- "Update the MAX_RETRIES variable on the pipeline workflow to 5"
-
-Variables set this way are available via `` syntax inside any block in the workflow.
-
-## Deleting Workflows
-
-- "Delete the old_api_prototype workflow"
-- "Delete all workflows in the deprecated folder"
-
-
diff --git a/apps/docs/content/docs/en/platform/costs.mdx b/apps/docs/content/docs/en/platform/costs.mdx
index 8a360e5a2e1..330d42c5567 100644
--- a/apps/docs/content/docs/en/platform/costs.mdx
+++ b/apps/docs/content/docs/en/platform/costs.mdx
@@ -246,11 +246,11 @@ When configured, workflows use your key instead of Sim's hosted keys. If removed
## Voice Input
-Voice input uses ElevenLabs Scribe v2 Realtime for speech-to-text transcription. It is available in the Mothership chat and in deployed chat voice mode.
+Voice input uses ElevenLabs Scribe v2 Realtime for speech-to-text transcription. It is available in Chat and in deployed chat voice mode.
| Context | Cost per session | Max duration |
|---------|-----------------|--------------|
-| Mothership (workspace) | ~5 credits ($0.024) | 3 minutes |
+| Chat (workspace) | ~5 credits ($0.024) | 3 minutes |
| Deployed chat (voice mode) | ~2 credits ($0.008) | 1 minute |
Each voice session is billed when it starts. In deployed chat voice mode, each conversation turn (speak → agent responds → speak again) is a separate session. Multi-turn conversations are billed per turn.
diff --git a/apps/docs/content/docs/en/platform/enterprise/access-control.mdx b/apps/docs/content/docs/en/platform/enterprise/access-control.mdx
index 38aa1ec8dac..dc21ccf5ca4 100644
--- a/apps/docs/content/docs/en/platform/enterprise/access-control.mdx
+++ b/apps/docs/content/docs/en/platform/enterprise/access-control.mdx
@@ -7,7 +7,7 @@ import { Callout } from 'fumadocs-ui/components/callout'
import { FAQ } from '@/components/ui/faq'
import { Image } from '@/components/ui/image'
-Access Control lets workspace admins define permission groups that restrict what each set of workspace members can do — which AI model providers they can use, which workflow blocks they can place, and which platform features are visible to them. Permission groups are scoped to a single workspace: a user can be in different groups (or no group) in different workspaces. Restrictions are enforced both in the workflow executor and in Mothership, based on the workflow's workspace.
+Access Control lets workspace admins define permission groups that restrict what each set of workspace members can do — which AI model providers they can use, which workflow blocks they can place, and which platform features are visible to them. Permission groups are scoped to a single workspace: a user can be in different groups (or no group) in different workspaces. Restrictions are enforced both in the workflow executor and in Chat, based on the workflow's workspace.
---
@@ -15,10 +15,10 @@ Access Control lets workspace admins define permission groups that restrict what
Access control is built around **permission groups**. Each group belongs to a specific workspace and has a name, an optional description, and a configuration that defines what its members can and cannot do. A user can belong to at most one permission group **per workspace**, but can belong to different groups in different workspaces.
-When a user runs a workflow or uses Mothership, Sim reads their group's configuration and applies it:
+When a user runs a workflow or uses Chat, Sim reads their group's configuration and applies it:
- **In the executor:** If a workflow uses a disallowed block type or model provider, execution halts immediately with an error. This applies to both manual runs and scheduled or API-triggered deployments.
-- **In Mothership:** Disallowed blocks are filtered out of the block list so they cannot be added to a workflow. Disallowed tool types (MCP, custom tools, skills) are skipped if Mothership attempts to use them.
+- **In Chat:** Disallowed blocks are filtered out of the block list so they cannot be added to a workflow. Disallowed tool types (MCP, custom tools, skills) are skipped if Sim attempts to use them.
---
@@ -146,12 +146,12 @@ Restrictions are enforced at the point of execution, not at save time. If a grou
This applies regardless of how the workflow is triggered — manually, via API, via schedule, or via webhook.
-### Mothership
+### Chat
-When a user opens Mothership, their permission group is read before any block or tool suggestions are made:
+When a user opens Chat, their permission group is read before any block or tool suggestions are made:
- Blocks not in the allowed list are filtered out of the block picker entirely — they do not appear as options.
-- If Mothership generates a workflow step that would use a disallowed tool (MCP, custom, or skills), that step is skipped and the reason is noted.
+- If Sim generates a workflow step that would use a disallowed tool (MCP, custom, or skills), that step is skipped and the reason is noted.
---
@@ -183,8 +183,8 @@ When a user opens Mothership, their permission group is read before any block or
answer: "Users with no group in a given workspace have no restrictions in that workspace. All blocks, model providers, and platform features are fully available to them there. Restrictions only apply in the specific workspaces where they are assigned to a group."
},
{
- question: "Does Mothership respect the same restrictions as the executor?",
- answer: "Yes. Mothership reads the user's permission group for the active workspace before suggesting blocks or tools. Disallowed blocks are filtered out of the block picker, and disallowed tool types are skipped during workflow generation."
+ question: "Does Chat respect the same restrictions as the executor?",
+ answer: "Yes. Sim reads the user's permission group for the active workspace before suggesting blocks or tools. Disallowed blocks are filtered out of the block picker, and disallowed tool types are skipped during workflow generation."
},
{
question: "Can I restrict access to specific workflows or workspaces?",
diff --git a/apps/docs/content/docs/en/platform/enterprise/data-drains.mdx b/apps/docs/content/docs/en/platform/enterprise/data-drains.mdx
index 8a55a28f449..1cea1446a1c 100644
--- a/apps/docs/content/docs/en/platform/enterprise/data-drains.mdx
+++ b/apps/docs/content/docs/en/platform/enterprise/data-drains.mdx
@@ -1,6 +1,6 @@
---
title: Data Drains
-description: Continuously export workflow logs, audit logs, and Mothership data to your own object store, data warehouse, observability platform, or HTTPS endpoint on a schedule
+description: Continuously export workflow logs, audit logs, and chat data to your own object store, data warehouse, observability platform, or HTTPS endpoint on a schedule
---
import { FAQ } from '@/components/ui/faq'
@@ -37,8 +37,8 @@ A drain exports exactly one source. To export multiple sources, create multiple
| **Workflow logs** | Workflow execution records (one row per execution, only after the run reaches a terminal state). |
| **Job logs** | Background job records (deployed APIs, schedules, webhooks). Only terminal-state rows are exported. |
| **Audit logs** | Organization- and workspace-scoped audit events — logins, permission changes, resource creation/deletion, drain configuration changes. |
-| **Copilot chats** | Mothership chat history. |
-| **Copilot runs** | Mothership run records (terminal state only). |
+| **Copilot chats** | Chat history. |
+| **Copilot runs** | Chat run records (terminal state only). |
Each row is delivered as a single line of NDJSON. The shape of each row is part of the public schema and stable across versions; every row carries an `id` field that downstream consumers can use to dedupe.
diff --git a/apps/docs/content/docs/en/platform/enterprise/data-retention.mdx b/apps/docs/content/docs/en/platform/enterprise/data-retention.mdx
index ecd4c4321d4..b8ef0f298ba 100644
--- a/apps/docs/content/docs/en/platform/enterprise/data-retention.mdx
+++ b/apps/docs/content/docs/en/platform/enterprise/data-retention.mdx
@@ -48,7 +48,7 @@ Resources covered:
### Task cleanup
-Controls how long **Mothership data** is kept, including:
+Controls how long **chat data** is kept, including:
- Copilot chats and run history
- Run checkpoints and async tool calls
diff --git a/apps/docs/content/docs/en/platform/enterprise/index.mdx b/apps/docs/content/docs/en/platform/enterprise/index.mdx
index 6544acddfd8..6b74bac7c2a 100644
--- a/apps/docs/content/docs/en/platform/enterprise/index.mdx
+++ b/apps/docs/content/docs/en/platform/enterprise/index.mdx
@@ -55,13 +55,13 @@ Track configuration and security-relevant actions across your organization for c
## Data Retention
-Configure how long execution logs, soft-deleted resources, and Mothership data are kept before permanent deletion. See the [data retention guide](/platform/enterprise/data-retention).
+Configure how long execution logs, soft-deleted resources, and chat data are kept before permanent deletion. See the [data retention guide](/platform/enterprise/data-retention).
---
## Data Drains
-Continuously export workflow logs, audit logs, and Mothership data to a customer-owned S3 bucket or HTTPS webhook on a schedule. See the [data drains guide](/platform/enterprise/data-drains).
+Continuously export workflow logs, audit logs, and chat data to a customer-owned S3 bucket or HTTPS webhook on a schedule. See the [data drains guide](/platform/enterprise/data-drains).
---
diff --git a/apps/docs/content/docs/en/platform/organization.mdx b/apps/docs/content/docs/en/platform/organization.mdx
index cbf534bf533..e829311f50a 100644
--- a/apps/docs/content/docs/en/platform/organization.mdx
+++ b/apps/docs/content/docs/en/platform/organization.mdx
@@ -1,78 +1,35 @@
---
title: Organizing a workspace
-description: Folders, colors, and naming conventions for keeping a growing workspace understandable.
+description: Folders group workflows in the sidebar; a separate workspace draws a hard boundary.
pageType: concept
---
import { Card, Cards } from 'fumadocs-ui/components/card'
-A **folder** is a container in the sidebar that groups workflows. It is the primary way you organize a [workspace](/platform/workspaces) once it holds more than a handful of workflows. Folders work like folders in a desktop file system: they nest, they collapse, and you arrange them by convention so the structure tells you where things live.
+A **folder** groups workflows in the sidebar. Folders work like folders anywhere: they nest, they collapse, you drag them to reorder or to move one inside another, and each has a name and a color dot for at-a-glance grouping. A flat list of twenty workflows is hard to scan; the same twenty under three or four top-level folders is a map.
-A flat list of twenty workflows is hard to scan, but grouping the same twenty under three or four top-level folders gives you a map of where everything lives.
+{/* VISUAL: before/after sidebar. Left: a flat list of ~20 workflows. Right: the same workflows under 3-4 color-coded top-level folders, one expanded to show a subfolder. */}
-{/* VISUAL: before/after sidebar. Left: a flat list of ~20 workflows, no grouping. Right: the same workflows under 3-4 top-level color-coded folders ("Internal", "Customer-Facing", "Ops"), some expanded to show nested subfolders. */}
+Two folder actions do more than tidy up:
-## The parts of a folder
+- **Locking** makes a folder read-only — its workflows can be viewed and run but not edited, and locking a parent locks everything inside it. Lock `Production` so nobody edits a live workflow by accident. Who can lock follows [roles and permissions](/platform/permissions).
+- **Archiving** removes a folder from the sidebar without deleting it, and you can restore it later. There is no hard-delete in the folder menu, so archiving is the safe way to retire a finished engagement or an old experiment.
-Here's an example: a folder named **Customer Deployments**, colored red, holding five workflows and two subfolders.
+{/* VISUAL: the folder context menu open on a folder row: rename, change color, lock, duplicate, export, new subfolder, delete. */}
-### Name
-
-A **name** is the label you give a folder. It is plain text with no enforced format, so the convention is yours to set. Pick names that read as categories, not as one-off labels: `Internal`, `Customer-Facing`, `Ops`. Our example folder is named `Customer Deployments`. Naming is covered in [Conventions](#conventions) below.
-
-{/* VISUAL: a single sidebar folder row showing the expand chevron, color dot, and name "Customer Deployments". */}
-
-### Color
-
-A **color** is a hex value assigned to a folder for visual grouping, shown as a dot next to the name. It defaults to gray (`#6B7280`) and you can change it from the folder's menu. Color is the fastest way to read the sidebar at a glance. Reserve one color per top-level category (red for production, gray for scratch work) so you can find the right branch before reading a single name. Our example is red (`#EF4444`).
-
-{/* VISUAL: a short vertical stack of folders with distinct color dots: red "Production", gray "Internal", another color for "Customer-Facing", showing color as the grouping signal. */}
-
-### Nesting
-
-A folder can sit inside another folder. The inner one is a **subfolder**, and the structure is a tree: a top-level folder has no parent, a subfolder points at the folder that contains it, and that chain can go as deep as you need. Our example, `Customer Deployments`, holds two subfolders and itself sits under a `Production` folder.
-
-Lead with shallow trees. Two or three levels (`Production` > `Customer A` > `Deployments`) stay readable. Go deeper than that and you end up scrolling the sidebar instead of scanning it.
-
-{/* VISUAL: a three-level nested tree: "Production" (red, top level) > "Customer A" (yellow) > "Deployments" (purple), each row indented one step, showing the parent-to-child chain. */}
-
-### Order
-
-Folders display in a set **order**, top to bottom, that you control by dragging them in the sidebar. Drag a folder up or down to reorder it within its level, or drag it onto another folder to move it inside as a subfolder. Order is a convention too: put the folders a team touches daily at the top.
-
-### Locking
-
-A **locked** folder is read-only: its workflows can be viewed but not edited. Locking is off by default. Lock a `Production` folder so members can open and run its workflows without changing them by accident. Locking a folder also locks everything inside it, so a locked parent protects its subfolders and their workflows in one move. Who can lock and unlock follows the workspace [roles and permissions](/platform/permissions).
-
-{/* VISUAL: the folder context menu open on a folder row, showing the options: rename, change color, lock, duplicate, export, new subfolder, delete. */}
-
-### Archiving
-
-**Archiving** a folder removes it from your active sidebar without deleting it. An archived folder drops out of the normal view, and you restore it when you need it again. Use archiving for cleanup: a finished customer engagement or a retired experiment leaves the sidebar but stays recoverable. There is no permanent hard-delete in the folder menu, so archiving is the safe way to get something out of the way.
-
-## Conventions
-
-Naming conventions make the structure legible to someone who did not build it. Nothing here is enforced, so the value comes from applying one rule consistently across the workspace.
-
-- **Group by audience or function at the top level.** A common split is `Internal`, `Customer-Facing`, and `Ops`. Someone new can find the right branch from the top-level names alone.
-- **Name folders as categories, workflows as actions.** A folder is a noun (`Billing`); a workflow is a thing it does (`Send overdue reminder`). The folder path plus the workflow name should read as a sentence.
-- **Use color for the top level, names for everything below.** Color carries the coarse grouping; names carry the detail. Mixing both at every level turns into noise.
-- **Mirror the convention everywhere.** The same category words you use for folders are worth reusing for [tables](/platform/workspaces), [secrets](/platform/credentials), and [integrations](/integrations), so a team learns one vocabulary instead of three.
+Keep the structure legible: name folders as categories (`Internal`, `Customer-Facing`, `Ops`) and workflows as actions (`Send overdue reminder`), keep nesting to two or three levels, and reuse the same category words across tables, secrets, and integrations so the team learns one vocabulary.
## One workspace or several
-Folders organize within a workspace. A separate workspace draws a hard boundary: resources never cross it, and access is granted per workspace. Reach for a new workspace when you need that boundary, not just tidier grouping.
+Folders organize within a workspace. A separate [workspace](/platform/workspaces) draws a hard boundary: resources never cross it, and access is granted per workspace.
- **Group in folders** when everything belongs to the same team and the same access rules, and you only want it easier to navigate.
-- **Split into workspaces** when a set of work needs its own members, its own integrations and secrets, or its own isolation. The classic case is one workspace per customer, where the workspace itself is the deliverable the customer owns.
-
-See [Workspace fundamentals](/platform/workspaces) for what the boundary scopes and [Roles and permissions](/platform/permissions) for how members and seats work across workspaces.
+- **Split into workspaces** when a set of work needs its own members, integrations, secrets, or isolation. The classic case is one workspace per customer, where the workspace itself is the deliverable the customer owns.
## Next
-
+
-
diff --git a/apps/docs/content/docs/en/platform/workspaces.mdx b/apps/docs/content/docs/en/platform/workspaces.mdx
index bdb3529eae9..3209d0ff64f 100644
--- a/apps/docs/content/docs/en/platform/workspaces.mdx
+++ b/apps/docs/content/docs/en/platform/workspaces.mdx
@@ -1,5 +1,5 @@
---
-title: Workspace fundamentals
+title: Workspaces
description: A workspace holds your workflows and resources and decides who can access them.
pageType: concept
---
diff --git a/apps/docs/content/docs/en/tables/index.mdx b/apps/docs/content/docs/en/tables/index.mdx
index ae70683af65..d9db25850c3 100644
--- a/apps/docs/content/docs/en/tables/index.mdx
+++ b/apps/docs/content/docs/en/tables/index.mdx
@@ -7,6 +7,7 @@ pageType: concept
import { Image } from '@/components/ui/image'
import { Card, Cards } from 'fumadocs-ui/components/card'
import { FAQ } from '@/components/ui/faq'
+import { TryInChat } from '@/components/ui/try-in-chat'
A **table** is a grid of typed columns in your workspace, like a spreadsheet with a schema. Use one to hold reference data, collect what your workflows produce, or store the structured records your agents read and write.
@@ -36,6 +37,36 @@ Open the **Tables** section in the sidebar and click **New table** to create one
A [Table block](/tables/using-in-workflows) reads and writes rows from inside a workflow: query rows for reference data, write results back, or process a batch. A [workflow column](/tables/workflow-columns) goes a step further and runs a workflow against each row on its own. Everything in a table is also available over the [REST API](/api-reference/getting-started).
+## In chat [#in-chat]
+
+Everything on this page can be done by asking Sim in [Chat](/chat): create a table from a description or a CSV, query it in plain language, add or update rows, and export results.
+
+
+
+
+
+
+
+
+
+Sim translates each request into the same operations described above, and can query across tables — describe the relationship and what you want. Tables it creates are immediately available to the [Table block](/integrations/table) in any workflow.
+
## Next
diff --git a/apps/docs/content/docs/en/workflows/building-in-chat.mdx b/apps/docs/content/docs/en/workflows/building-in-chat.mdx
new file mode 100644
index 00000000000..c7f0121d1f9
--- /dev/null
+++ b/apps/docs/content/docs/en/workflows/building-in-chat.mdx
@@ -0,0 +1,138 @@
+---
+title: Building in chat
+description: Create, edit, run, debug, deploy, and organize workflows from Chat.
+---
+
+import { Image } from '@/components/ui/image'
+import { Video } from '@/components/ui/video'
+import { FAQ } from '@/components/ui/faq'
+import { TryInChat } from '@/components/ui/try-in-chat'
+
+
+
+Describe a workflow and Sim builds it. Reference an existing one by name and it edits it. No canvas navigation required — every change appears in the resource panel in real time.
+
+## Creating Workflows
+
+Describe what the workflow should do — what triggers it, what it should do, which integrations it needs, and what it should return. Sim builds it and opens the canvas in the resource panel.
+
+
+
+## Editing Workflows
+
+{/* TODO: Screenshot of Sim with the Edit subagent active and a change applied to an open workflow — e.g., a new block added or a configuration updated, visible on the canvas in the resource panel. */}
+
+Open an existing workflow with `@workflow-name` or the **+** menu, then describe the change. Sim reads the current structure before modifying it — you don't need to explain what already exists.
+
+
+
+## Running Workflows
+
+
+
+ask Sim to run a workflow and it handles the execution:
+
+
+
+Execution streams back to the chat. The workflow in the resource panel shows live block-by-block state.
+
+## Reading Logs
+
+Sim can retrieve and interpret execution logs for any workflow in the workspace:
+
+
+
+Logs include per-block execution state, outputs, errors, and timing.
+
+## Debugging
+
+When a workflow fails, tell Sim to debug it:
+
+
+
+Sim reads the failure logs, identifies the cause, applies a fix, and can re-run to confirm.
+
+{/* TODO: Screenshot of the Debug subagent section in the Sim chat showing it reading logs and applying a fix. */}
+
+## Deploying
+
+Sim can deploy a workflow as any of the three deployment types:
+
+| Deployment type | What it creates |
+|----------------|----------------|
+| **API** | A REST endpoint at `https://sim.ai/api/workflows/{id}/execute` |
+| **Chat** | A hosted conversational interface with a shareable URL |
+| **MCP tool** | An MCP server that exposes the workflow as a tool |
+
+Ask: "Deploy the invoice workflow as an API and generate an API key."
+
+Sim can also roll back: "Revert the billing workflow to the version from last Tuesday."
+
+See [API Deployment](/workflows/deployment/api) and [Chat Deployment](/workflows/deployment/chat) for full details on each deployment type.
+
+## Organizing Workflows
+
+Sim can create and manage folders to keep your workspace organized.
+
+**Folders:**
+
+
+**Renaming and moving:**
+
+
+{/* TODO: Screenshot showing Sim confirming a folder or workflow organization action — e.g., a message confirming "Moved 'invoice-processor' into 'billing' folder" with the resource panel showing the folder open. */}
+
+## Workflow Variables
+
+Sim can set global variables on a workflow — values accessible across all blocks in that workflow at runtime:
+
+
+
+Variables set this way are available via `` syntax inside any block in the workflow.
+
+## Deleting Workflows
+
+
+
+
diff --git a/apps/docs/content/docs/en/workflows/deployment/index.mdx b/apps/docs/content/docs/en/workflows/deployment/index.mdx
index 92bf4121d02..12cb255c4d7 100644
--- a/apps/docs/content/docs/en/workflows/deployment/index.mdx
+++ b/apps/docs/content/docs/en/workflows/deployment/index.mdx
@@ -7,7 +7,7 @@ pageType: concept
import { Callout } from 'fumadocs-ui/components/callout'
import { Card, Cards } from 'fumadocs-ui/components/card'
-A deployment is a published version of a [workflow](/workflows) that outside callers can run. While you build, a workflow lives on your canvas as a draft only you can run. Deploying publishes a fixed copy of that draft and gives it an address: a REST endpoint, a chat page, a set of [MCP](/workflows/deployment/mcp) tools, or an [A2A](/workflows/deployment/api) agent. Each is a **surface**, a channel callers reach the same published workflow through.
+A deployment is a published version of a [workflow](/workflows) that outside callers can run. While you build, a workflow lives on your canvas as a draft only you can run. Deploying publishes a fixed copy of that draft and gives it an address: a REST endpoint, a chat page, a set of [MCP](/workflows/deployment/mcp) tools, or an [A2A](/workflows/deployment/api) endpoint other AI agents can call. Each is a **surface**, a channel callers reach the same published workflow through.
Like publishing a book, building and deploying are separate acts. You draft and revise freely on the canvas. When you click **Deploy**, Sim prints a fixed edition. Readers get that edition, not your latest draft, until you publish a new one. You can always go back to an earlier printing.
diff --git a/apps/docs/content/docs/en/workflows/index.mdx b/apps/docs/content/docs/en/workflows/index.mdx
index 5cb1b0c72a5..ffe3f69efbf 100644
--- a/apps/docs/content/docs/en/workflows/index.mdx
+++ b/apps/docs/content/docs/en/workflows/index.mdx
@@ -68,7 +68,7 @@ Two larger families do more specific jobs:
## How a workflow starts [#triggers]
-A trigger decides what starts the run and what input it receives. **Native triggers** need no connected account: [Start](/workflows/triggers/start) (manual, API, or chat), [Schedule](/workflows/triggers/schedule) (a timer), [Webhook](/workflows/triggers/webhook) (any inbound HTTP request), [RSS](/workflows/triggers/rss) (a new feed item), and [Table](/workflows/triggers/table) (a row change in a Sim table). **Integration triggers** fire on an event in a connected service — a GitHub push, a new email — and hand it to the workflow.
+A trigger decides what starts the run and what input it receives. **Native triggers** need no connected account: [Start](/workflows/triggers/start) (manual runs, API calls, and deployed chats), [Schedule](/workflows/triggers/schedule) (a timer), [Webhook](/workflows/triggers/webhook) (any inbound HTTP request), [RSS](/workflows/triggers/rss) (a new feed item), and [Table](/workflows/triggers/table) (a row change in a Sim table). **Integration triggers** fire on an event in a connected service — a GitHub push, a new email — and hand it to the workflow.
Every trigger runs the active [deployment](/workflows/deployment), so redeploy after changing a workflow for it to pick up the new version.
@@ -84,9 +84,9 @@ When a workflow runs, blocks execute in dependency order: a block runs as soon a
A workflow is where the rest of the workspace becomes behavior. On their own, tables, knowledge bases, files, and integrations are just resources. Workflows are where they *do* something.
-{/* VISUAL: system-context diagram. Mothership builds; tables/KBs/files/integrations feed; deployments expose; logs verify. */}
+{/* VISUAL: system-context diagram. Chat builds; tables/KBs/files/integrations feed; deployments expose; logs verify. */}
-- **Mothership** builds and edits workflows in natural language.
+- **[Chat](/chat)** — ask Sim to build and edit workflows in natural language.
- **Tables, knowledge bases, files, and integrations** feed data, memory, artifacts, and actions into a workflow.
- **Deployments** expose a workflow as an API, chat, or MCP server.
- **Logs** record every run so you can verify what happened, step by step.
diff --git a/apps/docs/next.config.ts b/apps/docs/next.config.ts
index 5c91879d91f..59fa2dd3cd0 100644
--- a/apps/docs/next.config.ts
+++ b/apps/docs/next.config.ts
@@ -24,8 +24,8 @@ const config: NextConfig = {
// form deployment removed
{ source: '/deployment/form', destination: '/workflows/deployment', permanent: true },
// copilot deprecated and removed
- { source: '/copilot', destination: '/mothership', permanent: true },
- { source: '/copilot/:path*', destination: '/mothership', permanent: true },
+ { source: '/copilot', destination: '/chat', permanent: true },
+ { source: '/copilot/:path*', destination: '/chat', permanent: true },
// connections/* and variables/* collapsed into single pages under workflows/
{ source: '/connections', destination: '/workflows/connections', permanent: true },
{ source: '/connections/:path*', destination: '/workflows/connections', permanent: true },
@@ -122,7 +122,24 @@ const config: NextConfig = {
destination: '/workflows/deployment/:path*',
permanent: true,
},
- { source: '/mailer', destination: '/mothership/mailer', permanent: true },
+ { source: '/mailer', destination: '/chat/mailer', permanent: true },
+ // Mothership section dissolved: the agent is Sim, the surface is Chat.
+ { source: '/mothership', destination: '/chat', permanent: true },
+ { source: '/mothership/research', destination: '/chat#research', permanent: true },
+ { source: '/mothership/tasks', destination: '/chat/tasks', permanent: true },
+ { source: '/mothership/mailer', destination: '/chat/mailer', permanent: true },
+ {
+ source: '/mothership/workflows',
+ destination: '/workflows/building-in-chat',
+ permanent: true,
+ },
+ { source: '/mothership/tables', destination: '/tables#in-chat', permanent: true },
+ {
+ source: '/mothership/knowledge',
+ destination: '/knowledgebase#in-chat',
+ permanent: true,
+ },
+ { source: '/mothership/files', destination: '/files#in-chat', permanent: true },
{ source: '/credentials', destination: '/platform/credentials', permanent: true },
{
source: '/credentials/:path*',