Why most inventory management systems will fail the Agentic Commerce test (and it’s not about features) 

I’ve spent the last six months talking to brands about their inventory management systems. The conversations follow a pattern: they show me their dashboards, walk through their forecasting features, demonstrate their reorder point calculations. They’re proud of the tools they’ve invested in. 

Then I ask a simple question: “If an AI agent queries your inventory right now, how accurate is the answer?” 

The room gets quiet. 

Most brands don’t have a clear view of their inventory, especially if multiple locations and channels are involved. And most brands don’t have a clear view of what AI shopping or agentic checkout really entails, and what it means for their inventory systems. The issue isn’t the quality of their tools, but that most inventory management systems were built on assumptions that no longer hold. 

The 2015 assumptions that built today’s systems 

Walk into any mid-market brand and look at their inventory setup. Chances are they’re running on a platform that assumed: 

• Humans usually take minutes or hours to place and review orders. 
• A 15-30 minute sync delay between systems is acceptable 
• Inventory counts don’t need to be perfect because humans are forgiving 
• Integration work is easier to manage when you limit connections 

These weren’t bad assumptions in 2015. They reflected how commerce actually worked. 

The problem is commerce doesn’t work that way anymore, and it especially won’t work that way when AI agents start making purchase decisions at scale. 

I’m going to make an uncomfortable claim: 80% of current inventory management platforms are architecturally unprepared for agentic commerce. No amount of feature additions will fix this. The foundation is wrong. 

The three architectural failures that will break everything 

Failure #1: The integration cap problem 

Take Cin7, one of our biggest competitors. Solid product, established player, thousands of customers. They cap integrations by pricing tier. 

This isn’t a pricing strategy—it’s a technical constraint. Their monolithic architecture can’t handle unlimited connections without performance degradation. So they limit what customers can connect. 

For human-driven commerce, this was manageable. You connect Shopify, QuickBooks, maybe a 3PL. Three to five integrations cover most workflows. 

For agent-driven commerce, this breaks immediately. 

AI agents won’t just query the data points you expose today. They’ll ask questions you haven’t thought of: “What’s the carbon footprint of this shipment?” “Can this ship to Alaska within 2 days?” “What’s the lead time if I order 50 units instead of 10?” 

Each question pulls from a different source. Your supplier for lead times. Your 3PL for shipping capabilities. Your carrier for transit times. Your manufacturer for production schedules. 

If your system caps at 10 integrations, you’re already done. If it slows down at 20, same problem. 

The uncomfortable question worth asking now is: if your system struggles with 10 smooth integrations today, how will it handle 100 protocol requests per second tomorrow? 

Failure #2: The “last updated 30 minutes ago” problem 

Here’s a dirty secret about most inventory integrations: they’re batch processes, not real-time. 

Your Shopify integration? Polls every 15 minutes. Your 3PL integration? Syncs twice an hour. Your accounting system? Updates overnight. 

Human shoppers don’t notice this. They browse and compare for minutes or hours before deciding. By the time they purchase, the data has refreshed three times. 

AI agents absolutely will notice. 

AI agents move faster. One queries at 2:47pm and sees 23 units. Another queries at 2:51pm and sees the same number—but a wholesale order just reserved 15 units, and the 3PL hasn’t synced yet. 

Both agents place orders. You’re now oversold by 15 units. 

This cascades. That phantom inventory shows up across every channel. Shopify, Amazon, your wholesale portal, anywhere the agent can query. The error multiplies because the foundation—your inventory system—had stale data. 

The problem isn’t the integration technology. We have webhooks, we have event-driven architecture, we have real-time protocols. The problem is most systems were built assuming eventual consistency is good enough. 

It’s not anymore. 

Failure #3: The single source of lies problem 

Most inventory management systems position themselves as the hub. They pull data from the rest of your stack, from your partners, transform and store it, and then show it back to you as one unified view. 

Sounds great. Except now you have version conflicts everywhere. 

If each of your systems show a different unit count, which is correct? 
The answer is usually “none of them, but Shopify is closest because it’s the actual source.” 

This is the difference between a system of record and a system of calculation. True systems of record reflect what’s true without transforming data. Most inventory management systems transform data constantly, creating derivative numbers that immediately diverge from reality. 

AI agents will route around systems they can’t trust. If an agent queries three sources and gets three different answers, it doesn’t average them—it marks you as unreliable and moves to the next brand.  

What actually matters: Architecture for agent-driven commerce 

If I’m rebuilding an inventory system today knowing what’s coming, here’s what I build for: 

Microservices over monoliths. Not because it’s fashionable, but because unlimited integrations are the foundation. When you don’t know which data points agents will query next year, you need architecture that can add connections without degrading performance. 

This is why we built Katana on microservices. Not to check a technical box, but because we watched competitors hit integration caps and knew that constraint would become fatal. 

Event-driven architecture. Real-time matters. Or near-real-time with acceptable SLAs. Batch processing worked for human timescales. For agent queries happening in milliseconds, you need systems that react to events as they occur. 

What matters is speed of truth propagation. If an order happens at 2:47pm, when does your system know? When do your integrations know? How long until that knowledge reaches every system that needs it? 

A single source of truth means aggregating data without transforming it. It means recording what happened, then letting other systems read from that record. Integrations write facts into the record. Calculations and rollups happen when systems read those facts. 

The technical pattern is event sourcing: store immutable facts, then derive the current state from them. Not transformed state that immediately becomes stale. 

API-first design. Not as an afterthought, not as “we have an API too,” but as the primary interface. When protocols like UCP and ACP become standard, your API needs to be production-ready, well-documented, and capable of handling query volumes that dwarf your current load. 

The controversial take: some brands should stay on spreadsheets 

Here’s where I’ll lose some readers: not every brand needs this infrastructure yet. 

If you’re single-channel, single-location, doing $1M revenue, a spreadsheet and a human managing inventory probably works fine. The complexity hasn’t overwhelmed human capacity yet. 

If you’re doing $2M with two channels, starting to use a 3PL, running 2,000+ orders per month… now you need infrastructure. The spreadsheet starts to crack. The time spent fixing mistakes starts to cost more than the system you’re trying to avoid. 

At $10M across five channels with external manufacturing and multiple fulfillment locations, you needed infrastructure two years ago. Every month you wait costs you in lost sales, service failures, and team time spent on reconciliation instead of growth. 

Premature infrastructure is as bad as inadequate infrastructure. Systems add overhead. They require maintenance, training, process changes. If you’re not at the complexity threshold yet, you’re better off staying simple. 

But know where that threshold is. For most modern DTC brands—especially those doing co-manufacturing with external fulfillment—it’s around $2M revenue, two channels, 2,000 monthly orders. That’s when human systems break and you need operational infrastructure. 

What I’m watching for 

The next 12-18 months will clarify who understands this shift and who doesn’t. 

I’m watching which platforms are rebuilding architectures versus adding features. Feature additions are easy to announce. Architecture changes are expensive, take years, and don’t make good marketing copy. But they’re what matters. 

I’m watching who embraces protocol standards versus who tries to own the customer. The platform companies that try to be the hub—the only system a brand needs—will lose to composable systems that play well with others. 

I’m watching who’s building for agent-driven commerce today versus who’s retrofitting human-driven systems with AI buzzwords. The difference is obvious if you look at the architecture, not the feature list. 

My prediction: we’ll see massive consolidation in 2026-2027. Not because of market conditions, but because architectural debt becomes undeniable. Platforms built on wrong assumptions will hit walls they can’t patch around. Brands will churn to systems that actually work for the commerce environment that’s emerging. 

Some platforms will make the transition. Most won’t. 

The brands that recognize this now—while there’s still time to change systems, rebuild processes, retrain teams—will have an operational advantage that compounds over time. 

The brands that wait until the failures become obvious will spend 2027 fighting fires while their competitors run ahead. 

Riikka Söderlund

COO & CMO

Riikka Söderlund is Chief Revenue Officer at Katana, where she works closely with hundreds of product businesses as they move beyond spreadsheets and set up systems that can handle growth. Her writing comes from those conversations and the patterns she’s seen across teams, channels, and locations.