Building AI Copilots — intelligence inside the workflow
A chatbot is a destination; a copilot is a passenger — it lives inside an existing tool (editor, inbox, CRM, spreadsheet), sees what the user is doing, and proposes; the user disposes. The category's defining law:
Context is the product. Two copilots with identical models differ entirely in what they can see — the open document, the selected code, the ticket thread, the cursor position. Copilot engineering is 80% context assembly (Topics 5, 53, 58): deciding, per invocation, which slice of the user's world goes on the whiteboard.
The interaction patterns, each with its own physics: inline completion (Topic 66's FIM — a hard <500 ms budget that mandates SLMs, Topic 63, and makes this the one pattern where model choice is dictated by latency, not quality); selected-text actions ("rewrite," "explain," "fix" — burst-shaped, mid-size models); side-panel chat with context (the workhorse — a chatbot that can see the workspace); and background drafts awaiting review (pre-written email replies, suggested ticket responses — latency-free because asynchronous, so the biggest model is affordable here; note the elegant inversion: the pattern users see instantly gets the smallest model, the one they see later gets the largest).
The structural advantage nobody should waste: every suggestion is accepted, edited, or rejected — which means a copilot generates labeled preference data as exhaust (Topic 16's triplets: shown vs. what-the-user-kept), plus a free north-star metric: acceptance rate, trackable per feature, per context type, per model version — a production eval (Topic 75) running itself. This flywheel is why copilots that ship early and instrument well become uncatchable: their training data is their usage.
Trust design completes the shape, straight from Topic 57's consequence tiers: suggestions are previewed, provenance-marked, one-keystroke-undoable, and consequential actions (send, commit, delete) are never auto-applied. A copilot that once silently mangles a document loses more trust than a hundred good suggestions earned — design for the error case first.
Summary
Copilot = context assembly + latency-tiered interaction patterns + suggestion-not-action trust design, with acceptance rate as the north star and accept/reject exhaust as a preference-data flywheel.
Mental model
A brilliant colleague reading over your shoulder who only ever hands you sticky notes — never touches your keyboard, and learns your taste from which notes you keep.
Mistakes to avoid
using one model for all patterns (the 500 ms completion path and the async draft path are different animals — Topic 38's matrix applies within one product); and discarding the accept/reject stream — that's your moat leaving through the logs.
Exercise
Spec a copilot for a tool you use daily (your editor, email, or issue tracker): list the five context sources you'd assemble per invocation and their token budgets, assign each interaction pattern a model tier with its latency budget, and define what "accepted" means telemetrically for each. One page — the copilot PRD.