What an AI-Native Operations Platform Actually Looks Like (also on Medium)
Almost every collection operation runs on fragments — routing tools, GPS trackers, spreadsheets, and group texts that don't talk to each other. An AI-native platform isn't a chatbot bolted onto existing software. It's a system built from the ground up to plan, adapt, and learn.
It's 6:47 on a Tuesday morning in Cleveland.
Maria is at her desk before anyone else. Paper notes on the corner. A Google Sheet open with locations. A separate tab for the routing tool. Another tab for GPS tracking through Samsara or Motive. A group text from yesterday with photos and weights buried somewhere in the scroll. A driver just called out. A property manager is calling about an overflow. The route plan she finalized Friday is already wrong.
She's the dispatcher. She runs the operation. The operation is running on fragments.
This isn't unusual. It's the norm. Almost every collection operation in the country runs this way. Even the best modern systems are still digitizing the old way. Take Routeware, HaulerHero, Curbwaste. Real companies doing real work, meaningfully better than the spreadsheets and clipboards that came before them. But they're digitizing the past, not rebuilding for what comes next.
Maria is the integration layer between five tools that don't talk to each other. That is a software problem. It's a failure of building quality tools for this industry. Routing platforms, dispatch software, bin monitoring, fleet tools. Every category is full of point solutions tackling a specific aspect. What nobody built is the layer that ties it all together and makes decisions across it.
That's what an AI-native operations platform is.
What "AI-native" actually means
The phrase gets thrown around because every software company wants to look modern. Most of what gets called AI today is a chatbot bolted onto a dashboard, a "smart" suggestion in a sidebar, a demo that lights up at trade shows. The underlying platform is the same one that was built before any of this existed. The decision layer is still you.
AI-native is different — and the difference isn't subtle.
Take Linear, the engineering tool we use to run Plutou. Linear was famously quiet on AI for years. While the rest of the market raced to ship chatbots, Linear sat on its hands. The reasoning, which CEO Karri Saarinen has talked about publicly, came down to one thing: they weren't going to ship AI until they could ship it properly. Then they moved hard. Saarinen recently declared "issue tracking is dead" and rebuilt Linear as the context layer for coding agents. Agents are now installed in 75 percent of Linear enterprise workspaces.
That's the model. AI-native is waiting until you can build it the right way, then doing so. Building the system with AI in mind from the infrastructure up. The data layer, the integrations, the way the platform reasons about an operation. All of it designed so the system can adapt as models improve, as new agents come online, as the technology curve bends. Not locked into anything. Flexible by design.
It also means something more specific. Building agents that have 20 years of operator thinking baked into them. Not generic LLM wrappers. Agents that know how a collection operation actually runs. What decisions a dispatcher makes at 6:47 a.m. The tradeoff between a missed stop and a late arrival. You're the operator. Not the integrator. The tedious work moves into the routing and dispatch layer. The judgment work stays with you.
Vertical, not horizontal
There's another layer to this. Vertical software is having its moment, and the reason is exactly what's happening in collection.
For years, the dominant playbook in software was horizontal. Build a generic platform, sell to every industry, win on breadth. That worked when software was mostly thin layers on top of databases. It doesn't work when the decision layer is the product. a16z and Bessemer have both been writing about this. AI-native vertical companies are reaching scale faster than any previous generation of SaaS, because AI on top of vertical depth produces something a horizontal platform can't replicate.
Horizontal tools have to flatten the work to make it portable across industries. Vertical tools shape themselves around how the work actually happens. For collection, that distinction is everything. The agents have to understand collection. The data model has to be shaped by collection. The operating loop has to match how collection runs. Generic logistics platforms and horizontal routing engines weren't built for that, and they never will be.
That's the build at Plutou. Not a routing engine. Not a logistics tool dressed up as a vertical play. A vertical operations platform for collection — route planning, location intelligence, and a driver app that share one data model instead of three tabs that don't talk.
What it does: Plan. Adapt. Learn.
Plan. The system builds the week. Not a person rebuilding a spreadsheet on Sunday night. The dispatcher reviews and edits in route planning, but the first draft exists before they open their laptop.
Adapt. A driver calls out. A truck won't start. An overflow gets called in. The system reshuffles routes in seconds. A human reviews and approves. The day continues. There's still a person in the loop because there are still operational decisions, physical-world realities, judgment calls that need a human. The tools should serve that, not pretend to replace it — that's what the driver app is for: capture in the field, approve at the desk.
Learn. Every pickup feeds the system more context. Fill rates. Service times. Route economics. What works in this city and not in that one. The longer it runs, the more autonomous it gets at the parts that should be autonomous, and the sharper its handoffs are at the parts that shouldn't be.
I'm not going to detail much more. Anyone can build any software nowadays. That's the great equalizer of this moment. Building quality software is the actual key. Most of what's interesting about what we're building gets revealed by running it, not by writing about it. (Try the route optimizer →)
Why this conversation is happening now
Look across collection and there's a lot of noise about how the market is broken. EPR is forcing collection at scale. EU textile EPR is rolling out across member states (EU Waste Framework Directive), and California SB 707 is the first statewide textile EPR law in the U.S. (bill text). More coming. Gas prices keep moving. Margins are tight. Labor is tighter. At the same time, entirely new collection streams are emerging — compost programs in California, battery collection partnerships with companies like Redwood Materials, EPR-funded textile collection networks rolling out across Europe. The industry isn't shrinking. It's expanding while the operating model stays stuck.
Every one of those new streams hits the same wall. Collection is the bottleneck. The math of any sustainability program, whether it's the circular economy, EPR compliance, or diversion from landfill, only works if collection is run well. Right now, it isn't. It runs on fragments — the same duct-tape stack of point tools most operators already know too well.
Where this lands
A few days ago I wrote about why collection has been broken for 40 years. The point of that piece was that the routing problem itself isn't the bottleneck. The data layer underneath it is. Operators have been left with point solutions stacked on point solutions, with no system that makes sense of any of it.
This is what fixing it actually looks like.
The next 40 years of this industry won't run on the operating model that ran the last 40. They won't run on Excel. They won't run on chatbots bolted onto Excel either. They'll run on something purpose-built for collection. Vertically specific. AI-native. Designed to keep getting better as the technology underneath keeps getting better.