The most consequential AI hire of 2026 isn’t a model researcher. It’s an economist. Google expanded its AI & Economy team with Nobel Laureate Philippe Aghion and Professor Ajay Agrawal, with new directors Anu Madgavkar and Daniel Rock running the program. No new benchmark. No new context window. Just people whose job is to figure out what happens to work when the software gets good enough.
If you build bots for a living, that should interest you more than another point on a leaderboard.
Why a bot builder should care about labor economics
I spend my days wiring up agents. Retrieval layers, tool-calling loops, retry logic, the unglamorous plumbing that makes an assistant actually useful instead of merely impressive in a demo. The mainstream story about AI progress is told in capability terms: what can the model do now that it couldn’t do six months ago?
That framing quietly skips the question that determines whether my work ships. Capability is not adoption. A bot that can handle 80% of a support queue is a technical achievement. A bot that is allowed to handle 80% of a support queue is an organizational one. The gap between those two things is where most agent projects die, and it’s exactly the gap Google’s AI & Economy Research Program is pointed at: global AI adoption and labor market shifts.
Aghion’s work sits in growth economics. Agrawal has spent years on the economics of prediction machines. Rock studies how technology reshapes jobs. Madgavkar’s research background is in workforce and productivity questions. Put that group in a room with Google’s internal view of how people actually use its AI products, and you get something builders rarely have access to: evidence about where automation lands, at what pace, and in which tasks.
The part the capability race keeps getting wrong
Here’s a pattern I see constantly in bot architecture. Teams scope a project around a job title instead of a task list. “Build a bot that replaces tier-one support.” That framing fails, and it fails for reasons economists identified long before the current wave of models existed. Jobs are bundles of tasks. Automation hits individual tasks unevenly. The tasks that get automated first are rarely the ones that make a role expensive.
Designing agents around tasks rather than roles changes the architecture in concrete ways:
- You decompose the workflow before you pick a model, not after
- Your tool definitions map to discrete actions with clear success criteria, which makes evaluation tractable
- Handoff points to humans become explicit design decisions instead of error-handling afterthoughts
- You can measure value per task, which is what your budget holder actually wants to see
That’s not a philosophical position. It’s what makes the difference between an agent you can monitor and an agent that silently degrades in production.
Research as a design input
I’ll be honest about the skeptical read. A large AI company funding research on AI’s economic effects has an obvious interest in the conclusions. That’s a fair concern and worth holding onto. Research programs deserve scrutiny regardless of who pays for them, and the useful test is whether the published work makes claims specific enough to be wrong.
But the alternative to imperfect evidence isn’t better evidence. It’s vibes. Right now, most decisions about where to deploy agents inside companies are made on vibes: a manager’s hunch about which team is ready, a vendor’s promise about time saved, a blog post from someone who shipped something adjacent. Actual data on adoption patterns across markets would be a step up from that, even with the caveats attached.
What I’d read it for
Three questions I’d want answered, and which this group is positioned to answer:
Where does adoption stall
Not which tasks models can do, but which tasks organizations actually hand over. The delta between those two sets is a roadmap for what to build next.
What happens to the tasks around the automated ones
When a bot absorbs part of a workflow, the surrounding work changes shape. Agents that ignore this generate more review burden than they remove. Knowing which direction that pressure goes should inform how much autonomy you give a system.
How adoption differs across regions
The program’s global focus matters if you ship products used outside a handful of wealthy markets. Deployment assumptions that hold in one economy break in another.
Build with the second-order effects in view
The teams shipping agents that stick are the ones thinking about the humans on both ends of the pipeline. Google putting serious economists on the payroll is a signal that the hard problems are moving from capability to consequence.
The models will keep improving whether or not we pay attention. Understanding what happens when they land inside real organizations is the part we can still get ahead of.
🕒 Published: