From answering to acting
The first wave of in-product AI was chat in a sidebar: ask a question, get an answer, copy it somewhere useful. The second wave — the one that actually moves retention — is the assistant that does the thing. "Create an issue," "schedule the report," "deactivate that user" — executed inside the product with the user's permissions.
Why chatbots stall
- Answers without action put the user back in the workflow they were trying to escape.
- The product surface and the AI surface drift — two places to learn, two places to maintain.
- Logs live in a different system from product analytics, so impact is impossible to attribute.
What an action-capable assistant looks like
- A command surface inside the app (a ⌘K bar, a sidebar, a slash menu).
- A tool layer (MCP) exposing the product's own write paths.
- Per-user OAuth so every action attributes to the user.
- Audit logs alongside the rest of the product's audit trail.
Operating principle
If the assistant can't perform the action the user came to perform, it's a help center with a typing animation.
Safety without a freeze
- Allowlist tools per audience — admins get destructive ones, end-users don't.
- Dry-run mode for anything that mutates billing, permissions, or external systems.
- Inline confirmation for irreversibles; default to action for read-and-summarize.
Wire the assistant into your product with the Command+K layer — widget, tools, audit log, all included.
FAQ
- What's the actual difference between a chatbot and an in-product AI assistant?
- A chatbot answers questions in a separate surface. An in-product AI assistant takes actions inside your app on behalf of the user — creating records, editing settings, running reports — using the same auth and permissions as the user's own clicks.
- Why are chatbots stalling out in 2026?
- They're disconnected from the system of record. Users have to copy answers back into the product to act on them. The novelty wears off, retention drops, and the ROI conversation gets uncomfortable. Action is the unlock, not conversation.
- Doesn't an in-product assistant need MCP?
- Yes — or something equivalent. You need a typed, auditable tool layer that the assistant can call with the user's identity. MCP is the open standard for that layer; rolling your own works but means you rebuild discovery, transport, and auth.
- How do I keep an action-capable assistant safe?
- Per-user OAuth on every tool, allowlists per audience, dry-run mode for destructive actions, full audit logs, and human-in-the-loop confirmation for anything irreversible. Treat the assistant as a deputy, not a co-founder.