Chatbot and copilot sound like synonyms. They're not. They represent different design patterns with different user psychology, failure modes, and success metrics. Building a chatbot for a task that should have been a copilot, or vice versa, is a common and expensive mistake. This post is the framework we use to pick between them.
The chatbot model
User initiates. Brings a question or task to the chat interface. Interaction is conversational turns. Context is assembled from what the user says. Success criterion: user got their answer; user is unblocked.
Classic examples: customer support bots, general Q&A assistants, booking assistants, onboarding guides. The user's world is elsewhere; they came to the AI to get unstuck, then leave.
Design implications: conversational UX patterns (see conversational UX). Context building through dialogue. Clear signals of capability and limits. Easy exit when done or when hitting a dead end.
The copilot model
User stays in a workflow. AI is embedded in the tool the user is already using — code editor, spreadsheet, CRM, design tool. Context comes from the tool itself — the doc, page, data, selection. Success criterion: task completed in the tool; output flows into user's next step.
Classic examples: code completion, inline sheet formulas, CRM next-step suggestions, design variation generation. The AI amplifies the user; the user doesn't leave their world to engage with AI.
Design implications: inline UI, minimal chrome. Context awareness is automatic (the AI sees the doc). Speed is critical (copilot slower than typing is worse than no copilot). Output feeds immediately into the user's next action.
Picking the right pattern
Three questions: Where does the user come from? (If from outside a workflow → chatbot. If from inside a tool → copilot.) Where does the output go? (If the user reads and leaves → chatbot. If the output goes into a document, file, form → copilot.) What does success look like? (If 'answer received' → chatbot. If 'task completed in tool' → copilot.)
Sometimes the same problem has both patterns. Customer support is chatbot-native. Customer support agent productivity is copilot-native (embedded in the agent's support desk, suggesting responses). Both can coexist in the same product; they're different features for different users.
Common mistakes
Building a chatbot for a task that should be a copilot. Slack bot for data analysis, when a copilot in the BI tool would be more useful. User has to leave their actual work to ask questions, then copy results back. High friction, low adoption.
Building a copilot for a task that should be a chatbot. Inline AI in an app the user only uses occasionally, when a separate chat surface would have been simpler. The copilot adds complexity to the main tool without the usage intensity to justify it.
Building both when one would do. 'We have a chatbot AND a copilot AND a...' — the feature count goes up but adoption doesn't. Pick the pattern that fits the main user workflow; add others only when validated demand exists.
Hybrid patterns that sometimes work
A copilot that can open a chat surface for harder questions. User is in a document; inline AI helps with most tasks; a 'Ask about this doc' button opens a focused chat for complex questions. Works when the chat is scoped to the current context.
A chatbot that can take actions in tools. 'Schedule a meeting with Priya Thursday at 3pm' via chatbot, with the chatbot executing against the calendar. Works when the actions are simple and the user prefers conversational over clicking.