Zero. That’s how many usage percentages I’m going to quote at you in this piece, because the most useful thing about Google’s AI & Economy ATLAS isn’t a headline number you can screenshot. It’s the method. And the method is something every one of us building bots should be copying into our own stacks this week.
Quick recap for anyone who missed it. Google announced the first iteration of the AI & Economy ATLAS on July 23, 2026, described as an ongoing, large-scale, de-identified study of how people actually use AI at work and in daily life. It’s led out of the Chief Economist’s Office, with Zanna Iscenko as AI & Economy Lead and Scott Strand heading StratOps. Then on September 15, 2026, Google shipped new data visualizations on top of that data, alongside a broader set of 2026 updates covering Gemini models, NotebookLM features, AI search, and developer tooling.
Two months from launch to a visualization layer. That pace tells you something about how the project is being treated internally: not as a one-off white paper, but as a living dataset that needs an interface.
Why a usage study matters more than a benchmark
Most of us build bots against assumptions. You imagine a user, you imagine the tasks they’ll bring, and you design prompts and tools around that imagined person. Then you ship, and the logs tell you a completely different story. The support bot you built for troubleshooting gets used mostly for policy lookups. The coding assistant gets used to explain code someone else wrote, not to write new code.
ATLAS is essentially that gap, measured at scale. A study organized around activity, tasks, and adoption is asking the question benchmarks never ask: not “can the model do this” but “what are people actually handing it, and how often.” Those are wildly different questions, and only one of them helps you decide what to build next.
For bot builders, the practical takeaway is uncomfortable but simple. If a company with Google’s resources concluded it needed an ongoing, structured study to understand AI usage, your gut feeling about your own users is probably worth less than you think.
Instrument your bot like it’s a research project
Here’s the architecture change I’d push for. Stop logging conversations and start logging tasks.
Most bot telemetry I see in the wild captures the wrong grain. You get raw transcripts, token counts, latency, maybe a thumbs up or down. That’s operations data. It tells you whether the system is healthy. It doesn’t tell you what the system is for.
A task-level layer looks more like this:
- Task classification. A cheap, fast model reads each completed interaction and tags it with an intent category. Not sentiment, not a quality score, just: what was this person trying to get done?
- Completion signal. Did the interaction end in a resolved action, an abandonment, or a handoff? Infer it from the tail of the conversation and any downstream events you control.
- De-identification at write time. Strip identifiers before the record lands in your analytics store, not after. ATLAS is explicitly de-identified, and that framing is the only reason a study like it can exist at that scale. The same logic applies to your product, at any scale.
- Task drift tracking. Compare this month’s intent distribution to last month’s. New categories showing up are your roadmap. Categories you built for that never appear are your cleanup list.
None of this is exotic. It’s a classifier, a table, and a weekly query. The reason people skip it is that it produces findings that contradict the plan, which is exactly why it’s valuable.
The model updates fit the same pattern
The 2026 Gemini updates and the NotebookLM integration with design tools point in a similar direction. Model families are splitting into tiers, including lighter, faster variants, and tools are being wired into the places where work actually happens rather than sitting in isolated chat windows.
Both trends reward builders who know their task distribution. Model tiering is only useful if you can route: cheap model for classification and routing, stronger model for reasoning-heavy work. Without task data, you either overpay by sending everything to the top tier, or you underserve by sending everything to the fast one. With task data, routing becomes a lookup.
The NotebookLM direction is the same story from the other end. Connecting an AI tool to a design surface is a bet about where a task lives. You can only make that bet well if you know which tasks your users are actually performing and in which application they’re already sitting.
What I’m doing about it
I’m adding an intent classifier to the two bots I maintain, writing tags to a separate table from transcripts, and setting a monthly review. The goal isn’t a dashboard nobody opens. It’s one decision per month that I would have gotten wrong otherwise.
Google built a study to find out what people do with AI. You can build a much smaller version of that for your own users in an afternoon, and the findings will be more actionable than anything in a global dataset. Steal the method, not the numbers.
🕒 Published: