Where should a copilot live in your product: side panel, inline, or command bar?

A copilot should live where the task happens. Put it inline when people change something they can already see, in a command bar when they know the action by name, in a side panel when they ask about the page and keep it in view, and on a full page when the work spans many sources. In every placement, show what the copilot can see and let people change that before they send. Humbleteam designs AI products for clients including Synthesia, the text-to-video platform, Cluely and MyRadar.

Humbleteam, a digital product design agency, publishes this guide. It covers four copilot placements, how vendor help pages describe them, the context a copilot reads, how to show and change that context, a placement decision table, an invented worked example, a test and a checklist. Sources are described as of November 14, 2026.

What are the four placements, and how do real products use them?

This guide sorts the ways a copilot enters an existing product into four placements.

• Inline: the copilot works in the content itself, as a suggestion at the cursor or an action on a selection.
• Command bar or slash command: the user types or picks a named action, and the result lands in place.
• Side panel: a chat sits beside the work, so the page stays in view.
• Full page: the chat takes the whole screen for long, multi-source work.

Every detail in the table is the vendor’s own description, read on November 14, 2026. Features change.

Figma’s Actions menu follows the command pattern: Cmd+K or Ctrl+K opens it, and it holds AI-powered design, writing and image tools.

Most of these products offer more than one entry point, and each entry point starts with its own default context. The VS Code docs draw the line plainly: use inline chat for “quick, targeted edits within the visible code context,” and the Chat view for multi-step tasks, multi-file changes or broader exploration.

Which placement fits which task?

Decide by task type, not by what competitors ship. Microsoft’s 18 guidelines for human-AI interaction include G3, “Time services based on context,” G7, “Support efficient invocation,” and G8, “Support efficient dismissal.” Each placement trades those off differently. Our reading: inline is the fastest to call and to ignore, while a full page takes longer to reach and leaves the most room to read and compare.

The table below is our example. Fill your own with the 5 to 10 tasks your users repeat most.

Our tie-break rules, for tasks that fit two rows:

1. If the output must end up in the work surface, start inline or with a command, and offer the panel for follow-up questions.
2. If the user has to read and judge the output before using it, use the panel, so the source stays visible next to the answer.
3. If the request needs more than one object or more than one step, send it to the panel or the full page, as VS Code does.
4. Give every placement a keyboard path, as GitHub, VS Code, Notion and Figma do.

What can the copilot see, and why must the interface say so?

Nielsen Norman Group’s April 2026 guidelines for site chatbots note that users “won’t assume a chatbot knows what they’re looking at” unless the chatbot says so. The same article says a bot should clearly and concisely indicate what it can do and tailor its opening message to the page the user is on.

Context comes in layers, and the docs above describe each one.

The VS Code docs add two details. A suggested attachment, such as the open file, “isn’t the same as an explicitly attached file,” so the two should look different. And explicit context “still counts toward the context window,” so the docs advise adding only sources that help with the task.

Apple’s Human Interface Guidelines for generative AI add a privacy rule. When information goes to a server, make sure people know, and show them what is shared.

How do you show the context and let people change it?

Five patterns cover it, and each has a documented example.

1. A chip in the input for the implicit context, with an x to remove it. In some modes, VS Code suggests the active file as an attachment, separate from files the user adds.
2. One picker for explicit context, opened by a single character and by a visible button. VS Code offers both # and Add Context; Google Docs offers @ and Sources.
3. A scope control near the input. Notion’s All sources menu and Gemini’s search locations both narrow where the copilot looks.
4. References after the answer. GitHub’s “Used n references” dropdown lists the files behind a response, which supports HAX G11, “Make clear why the system did what it did.”
5. A way back. Apple’s guidelines ask apps to let people dismiss new content and revert or retry changes they disagree with. VS Code shows inline edits as a diff with Keep or Undo, and Confluence says undo restores the original after Rovo edits.

For actions that cannot be undone, Apple’s guidelines say to get permission first. HAX G10, “Scope services when in doubt,” points the same way: when the copilot is unsure which object the user means, it should ask, not guess.

What does this look like in an invented procurement app?

Tallyway, its features and every detail below are invented. Tallyway is a procurement app where buyers review supplier contracts, and its team wants one copilot for four jobs.

• Draft a reply to a supplier inside the email composer: inline suggestion at the cursor, with the open contract implied and no chip, because the user sees the contract above.
• Shorten a clause: inline action on the selected clause, shown as a diff with keep and undo.
• “Create renewal task”: slash command in any contract, with the contract name shown in the command row before it runs.
• “Which contracts renew before March and have no price cap?”: full page, with the scope label set to all contracts the user can access and a source list on each answer.

Questions about one open contract go to a side panel. It opens with one line, “Reading: this contract and its 2 attachments,” and a chip the user can remove.

How do you test placement before building it?

Prototype the placements with canned answers, then run a task test with 5 to 8 users of the existing product. Give each person 3 to 5 tasks from your decision table. Both ranges are our example, not a research figure. Before each prompt is sent, ask one question: “What do you think the copilot can see right now?” Compare the answer with the real context. We count every mismatch as a design defect, even when the output is good.

Track these events after launch (names ours): entry point used, context chip removed, item added from the picker, scope changed, references opened, suggestion accepted, undo after an AI edit. Our rule of thumb: a high undo rate in one placement suggests that placement is wrong for that task. If the copilot has already shipped and few people use it, our guide on auditing an AI copilot that users don’t adopt walks through the funnel and the error analysis.

What should the context checklist cover?

• The copilot names what it can do in its first message, tailored to the page.
• The implicit context appears as a chip that can be removed.
• Added files and records appear as separate chips.
• The search scope is visible and can be changed near the input.
• Each answer lists the sources it used.
• Every AI edit can be undone or dismissed, and irreversible actions ask first.
• One line says answers follow the user’s own access rights.
• A global setting turns off proactive suggestions, in line with HAX G17, “Provide global controls.”

What can you produce now?

1. A placement decision table for your top 5 to 10 tasks.
2. A context layer sheet: implicit, explicit, scope, instructions and permissions.
3. Prototype screens of the input with chips, the picker and the scope control.
4. A task test script with the “What can it see?” question, and an event list.

If you are choosing a team to design the copilot itself, our comparison of AI product design agencies sets out what to look for.