The Great AI Sprawl
Why democratising AI made your teams slower, and the operating model that fixes it.
In the early days of AI, every company had one directive for their people - BE AI NATIVE. Most of them got the opposite of what they expected.
Not more productivity. More chaos. A tangled web of ‘AI Sprawl ‘.
Everyone turned into an AI builder overnight. Some did it because it was now a big part of how they got promoted. Some did it because their team was measuring usage, and they had to be seen using AI tools. And a lot of people did it because they realized building stuff with AI was way more fun than their actual job.
The C-suite mandated “use AI”. The org delivered chaos. Because AI without a system is just that - total chaos.
The numbers are brutal.
A recent Zapier survey found that 78% of employees using AI at work adopt tools outside IT approval. The IT Armageddon. 31% of enterprises discover new “rogue” AI tools monthly. And a recent report showed teams using more than 5 AI tools report lower self-rated productivity than teams using just 1-2 (Coommit).
In HubSpot, as we’ve dug into AI usage across the company, we’ve often found a negative correlation between people’s outcomes and their usage of AI vibe-coded tools they’ve built to help them do their work.
MIT research found that 95% of organisations see no measurable returns from AI investments in knowledge work. Gartner is forecasting that more than 40% of agentic AI projects will be cancelled by 2027 due to escalating costs, unclear value, and inadequate controls. And 54% of C-suite executives now admit AI adoption is, in their words, “tearing their company apart”.
Niranjan Vijayaragavan, Chief Product and Technology Officer at Nintex, called it plainly:
the rush into generative AI is creating “a new class of inefficiency.”
Companies invested in AI to move faster. The sprawl is making them slower.
But there is gold beyond that rainbow. There are companies and teams that are transforming how they work through AI. What are they doing differently?
From sprawl to system: agentic pods.
Uber recently shared how they’re approaching this. They call them Agentic Pods. The concept is simple: pair an AI-proficient engineer with a domain expert, give them a tight window, and ship a working end-to-end workflow.
Their results: marketing web QA went from 2 weeks to 50 minutes. Capital allocation across 150 cities: 15 hours to 30 minutes. Financial pacing reports: 2 days to 10 minutes.
This is the way.
We’re running a version of this at HubSpot right now. Engineers embedded with GTM teams, building workflows against real systems, measuring what moves the number.
But Uber’s model stops at “ship.” And anyone who’s actually done this at scale knows that shipping is maybe 40% of the job. The workflow has to survive contact with real users, hold up when you expand beyond the pilot group, and actually get adopted.
Here’s the full agentic loop we’re building toward:
1. Observe. Both qual and quant. If practical, e.g., you have budget, there is a new set of tools that will help you map workflows across your GTM teams and connect them to business outcomes Observability for GTM workflows. That means you can then go shadow the GTM practitioner/s doing those workflows. Map it out. See if it’s worth moving into the agentic bucket.
2. Identify. Find the highest-impact automation opportunities. Not every workflow is worth rebuilding. These need to be correlated to outcomes. You have to be able to measure what the impact of workflows is and prioritise, everything will look like an opportunity; this is the hardest part of the loop.
3. Build. Engineer and domain expert build the workflow together. Not for them. With them. To be honest, the domain expert can build most of it if using Codex, Cowork, etc. The engineer can build foundational features that might be needed to scale that workflow within these LLMs.
4. MVP. Deploy to a small group first. See if results hold before you roll it wide. It’s one thing getting a single person to use it and show impact; it’s a whole other getting 100s or 1000s.
5. Expand. Push it to more people. Does it generalize, or did it only work for the pilot group?
6. Enable. The most undervalued step. Someone needs to hold hands, train, and make sure the workflow actually gets used. Building it is maybe 40% of the job. Getting adoption is the other 60%. Changing human behavior is incredibly hard.
7. Measure. Close the loop back to observability. What worked, what didn’t, and what do you build next?
You’re likely thinking.
“This works if you have engineers to spare. Most GTM teams don’t.”
The pod model doesn’t require a full engineering team. It requires one technically proficient person paired with one domain expert. In some organizations, that technical person is a GTM engineer or just the person who is home every evening building out agents, deep in the AI weeds.
The point being, measuring “AI native” by usage is pointless. A person with low domain expertise and high AI agency is likely an incredible AI slop machine in your company right now, creating mass amounts of sprawl. You need to move from “everyone uses AI tools” to “let’s instrument the workflows that actually drive outcomes.”
Until Next Time,
Happy AI’fying
Kieran