Two axes decide everything.
"Where should the AI live?" is the wrong question. The real question is two questions stacked. Who initiates the work — the human, or the co-worker noticing something? And where does the work surface — inside a tool the team already uses, or in a new dedicated space?
Answer those two and you land on one of four modes. Pick the wrong mode and the co-worker becomes shelfware in week six, regardless of how good the model is.
Most teams pick Ask first because it's safe. The biggest ROI usually lives in Watch or Build.
Ask — Q&A on your data.
The user types a question, the co-worker reads the right rows in your warehouse / docs / CRM, drafts an answer with citations back to the source. No autonomous action — the human is in the chair.
Best for: ad-hoc analysis, "where did this number come from", new-hire onboarding, exec briefings before a meeting. The lowest-trust mode — users see every citation and can click through to the source.
Watch out for: teams that pick Ask because it feels safe, when the work is actually a recurring cadence that belongs in Build. You'll know it's the wrong fit if the same question gets asked every Monday.
Watch — proactive alerts.
The co-worker observes a stream — CRM activity, ticket volume, model drift, financial drivers — and surfaces only what's changed materially. It pings a person, not a dashboard.
Best for: customer health (churn risk), pipeline integrity (stale opps), system observability (anomaly detection), revenue ops (forecast drift). Anything where the question "is something different today?" is asked daily but answered manually.
Watch out for: alert fatigue. A Watch co-worker that pings 30 times a day is worse than no co-worker. Tune the threshold against false-positive cost before you ship.
Embed — inside the tool you already use.
The co-worker lives where the work happens — a Slack slash command, a CRM side panel, a button inside the ticket inbox. The team doesn't switch context to use it; the co-worker comes to them.
Best for: drafting replies in support, generating account briefs inside the CRM, summarizing meeting transcripts inside Slack, suggesting next-best-actions in the ticket UI.
Watch out for: tool sprawl. If you embed in three different tools, you have three different co-workers to maintain. Pick the one tool where the team spends 80% of the day and Embed only there.
Build — a recurring workflow.
The co-worker runs on a schedule, drafts a deliverable, and routes it to an approval queue. The human approves a batch, not a one-off. Monthly variance commentary. Weekly pipeline review. Daily exception report.
Best for: any cadenced report or recurring decision that today eats hours of skilled-human time. Build is where the highest ROI usually hides — and the highest implementation risk.
Watch out for: brittle assumptions. A Build co-worker assumes the input data shape will stay stable. Add a schema-drift check or it will silently break the first time a column gets renamed.
"Pick a mode based on who notices the work first — the human or the co-worker. That single question removes 80% of the ambiguity."
The decision tree, in three questions.
- Does the work happen on a known cadence? If yes → Build. If no → question 2.
- Should the co-worker notice things the human hasn't noticed yet? If yes → Watch. If no → question 3.
- Is the existing tool where the team spends most of their day? If yes → Embed. If no → Ask.
Most workflows fit one mode cleanly. If you find yourself wanting two, you usually have two workflows in a trenchcoat — split them before you ship.
Pick the wrong mode and the co-worker becomes shelfware.
If you have a workflow you're trying to place, a 45-minute call usually tells us which mode it belongs in — and whether it's worth shipping at all.