- The product and workflow layer decides whether an AI system is used at all. Accuracy does not matter for a feature nobody opens.
- A separate chat interface makes people leave their tool, describe their context in words, and copy the answer back. Each step loses users.
- Embedded intelligence works at a specific step of an existing workflow: it already has the context, proposes a concrete action, and the person accepts, edits or rejects it in place.
- Measure adoption by acceptance and edit rates at that step, not by chat sessions, and design the edit path as carefully as the happy path.
A team builds a capable assistant, adds a chat panel to the side of the product, and launches. Usage spikes for two weeks and then flattens. The model was fine. The placement was wrong.
01Why do chat panels underperform?
A chat box beside the work asks a lot of the user before it gives anything back:
- Leave the task. Stop what they are doing and switch to a different surface.
- Explain the context. Describe, in words, the ticket, the record or the document that the product already has on screen.
- Translate the answer. Read prose and turn it into an action: copy a value, fill a field, click somewhere else.
Each of those steps is friction, and friction compounds. Power users push through. Most people go back to doing it by hand.
There are good uses for an open-ended assistant: exploration, questions that cut across many systems, people who live in chat already. It is a poor default for a defined, repeated job.
02What does “inside the workflow” mean?
Find the step in the existing workflow where someone makes a decision, and put the intelligence exactly there, with the context already loaded.
| Workflow | Beside it | Inside it |
|---|---|---|
| Support queue | Assistant panel the agent can ask | Each ticket opens with a proposed resolution and draft reply, ready to send or edit |
| Invoice processing | “Ask AI about this invoice” | Fields pre-filled from the PDF, mismatches with the purchase order highlighted |
| Code review | Chat with the codebase | Review comments on the exact lines, each one accept or dismiss |
| Sales ops | Assistant that answers CRM questions | Stale deals flagged in the pipeline view with a drafted follow-up |
In every “inside” example the system already knows the context, proposes something concrete, and the person stays in the tool they were using.
03How should AI product design handle accept, edit and reject?
The model proposes, the person disposes. Three paths matter equally:
- Accept: one action, in place. The proposal is specific enough to execute as is.
- Edit: the proposal is a starting point the person can change. Often the most-used path, and the most informative.
- Reject: fast, with an optional reason, and no penalty for using it.
@dataclass
class Suggestion:
ticket_id: str
action: Literal["refund", "replace", "reply_only", "escalate"]
args: dict # exact arguments, shown to the agent before anything runs
draft_reply: str
evidence: list[str] # order record, policy section: why the model proposed this
confidence: Literal["high", "low"]
def on_decision(s: Suggestion, decision: str, edited_args: dict | None, user: User):
log_decision(s, decision, edited_args, user) # acceptance and edit rates come from here
if decision == "accept":
execute(s.action, s.args, on_behalf_of=user)
elif decision == "edit":
execute(s.action, edited_args, on_behalf_of=user)Show the evidence next to the proposal. People trust a suggestion they can check in two seconds, and they catch the wrong ones faster.
04How do you measure it?
Not by chat sessions or messages sent. At the step you instrumented, track:
- Coverage: the share of items where a proposal was shown.
- Acceptance rate: proposals used as is.
- Edit rate and edit distance: proposals used after changes, and how much changed.
- Rejection reasons: the cheapest source of eval cases you will ever get.
- Time to complete the step, compared with before.
Every edit is a free label. Feed edits and rejections back into the eval set, and the system improves on the cases that actually matter to the people using it.
An AI feature is used when it saves a step, not when it adds a destination.
05Where it sits in the stack
This is L5, product and workflow: the layer closest to the user and the one that decides whether everything beneath it matters. When the proposed action needs sign-off before it runs, the approval belongs in the same place, handled as a durable wait, so the person approving never has to leave their tool either.