What is Embedded Assistant?
Also called In-App Assistant, In-Product Copilot.
An embedded assistant is an assistant that lives inside a host application and has access to that application's context and actions. Unlike a general chat interface, it can read what the user is currently viewing and operate on it, for example editing a record or filtering a report. The assistant is a feature of the product it sits in.
The defining piece is context passing. The host application tells the assistant who the user is, what screen they are on, and which records are selected, then exposes a bounded set of actions the assistant is permitted to call. Permissions come from the host, so the assistant inherits the signed in user's existing access rather than holding a separate, broader key.
This turns vague requests into executable ones. 'Sort this by churn risk and email the top ten' is meaningless to a standalone chat window and unambiguous inside the report the user is looking at. It also compresses the distance between asking and doing, since the result appears in the same interface rather than as instructions to follow manually.
The risks come from the same context. An assistant that can act needs a clear boundary between reading and writing, confirmation for anything destructive, and an undo path. Teams also underestimate scope creep, because once an assistant is embedded, every feature request becomes a request for one more action, and the permitted action set grows faster than the tests around it.
Compared with a chat widget, which is a container that can be dropped onto any page, an embedded assistant is coupled to the product's data model on purpose. The tradeoff is portability against usefulness. A widget travels anywhere and knows little; an embedded assistant knows a great deal and cannot be lifted into another application unchanged.
Key points
- Receives host application context: user, screen, and selection
- Inherits the signed in user's permissions, not broader ones
- Can act on records, not only answer questions
- Write actions need confirmation and an undo path
- Coupled to the product's data model by design
In practice
An accounting tool embeds an assistant in its invoice list. A user viewing overdue invoices types 'chase everything more than thirty days late.' The assistant already knows the filtered set, drafts a reminder for each of the eleven matching invoices, shows them for review, and sends only after the user approves. The same request typed into an unconnected chat box could not identify which invoices were meant.