Internal copilots: the model doesn't decide adoption
Two nearly identical rollouts. One reached 70% weekly use, the other 8%. The difference was where it lived.
We rolled out two nearly identical AI assistant implementations to different teams within the same company. They had nearly identical capabilities and similar model performance characteristics. One reached seventy percent weekly active usage. The other achieved only eight percent adoption despite having identical underlying functionality.
The successful assistant lived inside the tool the team already had open eight hours every day as part of their work. The copilot was a tab within the existing application they already knew well. No mental friction required. No new login to remember. Just another feature in a familiar interface.
The unsuccessful assistant was a separate application with its own interface, authentication, and navigation paradigms. The implementation was solid engineering work. The functionality was genuinely good. Nobody wanted to context-switch to a different application to use it during their workday.
The difference between seventy percent adoption and eight percent adoption was not the model quality or underlying capabilities. It was simply where the feature lived in the user's actual daily workflow and how integrated it was into their existing tools.
In internal assistant deployments, integration into existing workflow is not a delivery detail or optimization phase. It actually represents half the project effort. Plan and budget accordingly from the start.
The lesson generalizes beyond internal tools: put the capability where people already work or accept that adoption will stall at low percentages.