Every SaaS product is getting an AI copilot right now. Most of them feel bolted on — a chat bubble in the corner that maybe helps with help-docs queries. A minority feel transformative — AI that changes how users interact with the core product. The difference isn't the model or even the data. It's the design decision about what the copilot is for, and that decision gets made in the first week of the project, before any code is written.
This post is the framework we use with SaaS clients designing copilots. It's about when to build one, where it should live in the UX, and how to decide what it does versus what the rest of the product does.
Two kinds of copilots
The fundamental design choice: is your copilot a feature alongside the product, or is it the product (and the current UI is the fallback)?
Adjunct copilot
Lives next to the existing UI. Helps users do what they already know how to do, just faster. Asking questions, automating routine tasks, surfacing relevant information. The UI stays primary; the copilot is augmentation. Most SaaS copilots in 2026 are this kind — GitHub Copilot is the canonical example.
Primary copilot
Replaces much of the UI for most users. The chat or natural-language interface is the primary way to do things. The existing UI becomes a fallback for power users or specific flows. This is more ambitious, more differentiated, and more risky.
When each is right
Pick adjunct when: your UI is core differentiation (users chose you for the interface); the product involves visual or spatial work that chat can't replicate; your users are expert and prefer keyboard-driven workflows. Adjunct copilots augment without disrupting, which matches most B2B SaaS.
Pick primary when: your UI is a liability (legacy or complex and off-putting to new users); your product is primarily information-retrieval or task-execution; you're targeting users who find traditional software intimidating. Primary copilots can unlock new user segments that the current UI loses.
Key design decisions
Where does the copilot live?
Sidebar, modal, inline, fullscreen? Each choice changes how users think about it. Sidebar (always accessible, peripheral) says 'assistant.' Modal (focused, blocking) says 'feature you invoke.' Inline (embedded in specific UI elements) says 'contextual help.' Fullscreen (dominant surface) says 'this is the way to work.' Match placement to role.
How does it know what you're doing?
A copilot without context is a worse Google. The best copilots see: the current page, the selected object, the recent actions, the user's permissions and role. Providing this context automatically is most of the engineering challenge. Do it well and the copilot feels clairvoyant. Do it poorly and users have to explain themselves every turn.
What actions can it take?
Read-only copilots are safe but limited. Action-taking copilots are powerful but risky. The decision: what can the copilot do without asking, what requires explicit confirmation, what requires out-of-band approval. Default: read-only actions auto-execute, state-changing actions require confirmation, irreversible or high-impact actions require separate approval. Our agents in production post covers the safety patterns in depth.
The conversational UX question
Chat isn't the only interface. For some tasks, structured forms or menus are faster and less ambiguous. Great copilots mix chat with structured UI — a chat response can include buttons, forms, embedded views. This hybrid feels like chat but avoids the 'explain yourself in 30 words' problem. See our conversational UX post for the patterns.
How to know if it's working
Copilot success metrics:
- Usage rate: what fraction of active users engage with the copilot weekly?
- Task completion rate: of tasks initiated through the copilot, how many complete successfully?
- Abandonment rate: how often do users start a copilot interaction and drop out?
- Time to value: does completing a task through the copilot beat the UI path?
- Net promoter: do users who use the copilot rate the product higher?
Measure baseline first. Add the copilot, measure again. A copilot that doesn't improve these numbers is costing engineering time without returning product value.
Pricing the copilot
Three models we see:
- Included in product price: simplest, best for adjunct copilots. Cost is overhead you accept.
- Separate add-on tier: for power features or high-cost copilots. Common for enterprise tiers.
- Usage-based: pay-per-call or credit-based. Works for primary copilots where usage correlates with value received. Aligns incentives but requires billing infrastructure.
Closing
The copilot decision is a product decision, not a technology decision. What role does it play? Where does it live? What can it do? Technology serves these answers; picking technology first leads to copilots that work technically but miss the product need. If you're designing a copilot, start with what it's for, then decide how to build it. We'd be glad to help think through it — get in touch.