How Walmart Is Reengineering AI Delivery Speed

Replacing Quarterly Planning Cycles With Stopwatch Deployment

David Glick draws a direct line between planning cadence and AI failure. When iteration speed compresses from quarters to hours, the cost of being wrong about priorities drops dramatically — and with it, the entire logic of heavyweight planning cycles.

The practical implication for retail technology leaders is that planning overhead becomes less valuable the faster a team can iterate. Rather than spending three months on discovery and three months on UX to get one thing right, teams that can prototype in real time with end users can course-correct in minutes. As the SVP explains:

“When you can only do one thing a year, you’d better get the right thing right. You spend a lot of time on global prioritization: three months on discovery, three months on UX. If you can do 50 things a year, it may not matter which one you do first.”

– David Glick, SVP of Enterprise Business Services at Walmart

This reframes how retail leaders should think about planning overhead. The goal is not to plan better — it is to iterate faster so that planning becomes less consequential. Three operational shifts that support this:

Prototype in real time with end users rather than gathering requirements upfront. Glick’s team compresses what once took months of back-and-forth into a single afternoon session.

Replace sequential approvals with parallel governance. Security and compliance processes should run alongside development, not after it.

Measure in hours and days, not quarters. The planning unit should match the delivery unit.

Shifting From Monolithic AI Systems to Federated Nano Agents

The dominant mental model for enterprise AI — one large, centralized system that handles everything — is not just inefficient. It is architecturally misaligned with how value actually gets created at scale.

Glick draws a direct line from the failures of monolithic software to the limitations of monolithic AI. Hundreds of engineers checking into a single codebase created the same problem: too much coordination overhead, too little speed, too many dependencies. The move to microservices solved that for software. Nano agents are solving it for AI.

The distinction matters in practice:

Nano agents are small, single-purpose AI tools built and owned by domain-specific teams. Each solves one problem well rather than many problems poorly.

Super agents act as intelligent dispatchers — a routing layer that directs requests to the right nano agent without requiring users to know where to look or what to ask for.

Chunky agents sit in between, handling domain-level routing before passing work to more specific agents below.

The SVP uses a simple analogy to illustrate the principle: “Swiss Army knives do many things, but do them poorly. A fork, a spoon, and a knife — between those three things, I can usually eat my dinner better than with a pocket knife.”

For retail technology leaders, the operational implication is clear. A single monolithic AI deployment creates a single point of failure and a single point of slowdown. A federated network of task-specific agents creates resilience, speed, and clear ownership — and scales in a way that centralized systems cannot.

Building the Infrastructure That Builds Agents, Not Just the Agents Themselves

David’s most sophisticated insight in this conversation is not about any individual agent. It is about what happens when an organization stops treating AI deployment as a series of projects and starts treating it as a manufacturing capability.

Glick calls this “the machine that builds the machine.” The idea is straightforward: rather than investing engineering effort in building one agent at a time, invest in the platform, processes, and standards that make agent development repeatable, fast, and scalable across every domain in the organization.

The practical difference between these two approaches is significant:

Project thinking produces individual agents that work well in isolation but require the same effort to build each time.

Platform thinking produces an agent factory — infrastructure that any domain team can use to spin up, test, and deploy agents without having to start from scratch.

Glick is candid about where most organizations, including his own, currently sit. His team has produced three separate agent-building platforms across different functions — finance, people, and operations — each optimized for its own domain. Rather than treating this as a problem to eliminate, he frames it as an acceptable stage of maturity:

“We’d rather have two things that do something than zero. The folks on my finance tech team built something that works great for them. The folks from my people tech team built something slightly different, but it works for them and is able to access the data it needs.”

David Glick, SVP of Enterprise Business Services at Walmart

The rule of thumb for retail leaders: duplication in the early stages of agent infrastructure is acceptable. Absence is not. The priority is to get domain teams building and iterating—and then consolidate on what works. Organizations that wait for a perfect, unified platform before deploying will find themselves years behind those that built messily and learned quickly.