Do: The Warehouse That Runs Itself

Walk onto almost any warehouse floor and the gap between the system of record and physical reality is visible within minutes. The WMS says a wave was released at 9:00. What actually happened is a supervisor manually built the pick list the night before, printed it, and handed it out — and by 9:40, a late inbound delivery and two absent pickers have already made that plan obsolete. Nobody updates the wave. Everybody just works around it.

This isn't a failure of the people on the floor. It's a failure of the tooling they're given. Static wave plans, fixed pick routes, and box sizes chosen by eye were reasonable when volumes were predictable and order profiles were simple. They aren't reasonable for a modern, high-velocity, multi-channel fulfillment operation.

The warehouse doesn't need a better report on what happened during the shift. It needs the shift plan itself to keep up with the shift as it actually unfolds.

This is the third post in our Agentic Operations series. Our previous post covered how Datanomous Planning builds a plan for every order in well under a second: which warehouse it ships from, which team prepares it, when it will be ready, and what it costs. This post covers the layer that turns that plan into reality on the floor — Datanomous WES, the Warehouse Execution Manager, which synchronizes the plan in real time and instantly manages whatever deviates from it.

The execution gap

Warehouse execution is where the boardroom's clean order-to-ship diagram meets the reality of a physical building full of people, equipment, and constantly shifting conditions. A handful of patterns show up in almost every facility that hasn't moved past static, rule-based execution.

• Fixed wave planning — waves are built once, typically by hand, hours before the shift, and stay fixed even as inbound delays, order surges, and absenteeism change what's actually achievable.
• Static pick routing — pickers follow a fixed serpentine path regardless of current congestion, walking further than necessary and crossing paths in busy aisles.
• Manual packing decisions — carton size and dunnage chosen by eye, slow and inconsistent, and expensive once dimensional-weight freight pricing applies.
• Late bottleneck detection — a pack-station backlog or QC slowdown is usually first noticed when a carrier cut-off is missed, not while there was still time to react.

None of this shows up cleanly in a weekly report. It shows up as overtime nobody planned for, carrier cut-offs missed by minutes, and a floor that runs on the tribal knowledge of whichever supervisor is on shift that day.

Datanomous WES: the Do layer

The plan Datanomous Planning builds is flawless on paper. But things on the floor rarely go exactly to plan — a picker doesn't show up, a truck is delayed, a product isn't where it's supposed to be. This is exactly where Datanomous WES's job begins: it's the only layer that commits and executes work on the floor, synchronizing the plan against the floor in real time, and instantly managing the exceptions.

In doing so, it coordinates people, robots, and physical assets against a live picture of demand and capacity — not once at the start of a shift, but continuously: wave generated from live demand, route recalculated continuously against floor congestion, guided box and dunnage selection, bottlenecks flagged before they cost a cut-off.

• For floor managers and supervisors — replaces static, once-a-day wave building with continuous, real-time balancing of order priority against available labor, and surfaces likely SLA breaches hours ahead of the cut-off with the specific re-allocation steps needed to avoid them.
• For pickers and packers — dynamic route optimization recalculates the shortest, least-congested path continuously; intelligent batching groups multi-order picks by physical proximity and weight; voice-directed and vision-guided execution reduces scanning steps and catches errors before they leave the building; packaging guidance recommends the exact carton size and dunnage for each order.

Every WES action has a full audit trail. What executes automatically and what routes to a supervisor for approval is clearly defined. A dashboard can tell a supervisor that Zone A is falling behind; it can't move an operator there. Datanomous WES is built to be the layer that actually changes what happens next on the floor — not just the layer that describes it.

A busy afternoon: two ways to run the same shift

An e-commerce warehouse has 10,000 orders on the books for the day. On the floor: 50 operators, 100 autonomous mobile robots, and 20 packing stations.

The morning with a classic WES

The WMS sends orders to the WES, which processes them against predefined rules: express first, then standard, then whatever's closest to its carrier cut-off. Task creation follows the same fixed logic. By early afternoon, Zone A gets severely congested — five operators go on break at the same time, robot traffic increases, a queue forms at the packing line. A classic WES keeps applying the rules it has. As the queue grows it fires an alert; an operations manager steps in and manually moves two people from Zone B to Zone A. The system only reacts once the problem already exists.

The same morning with Datanomous WES

Datanomous WES starts with the same orders, but never looks at the current state in isolation — it continuously weighs historical order patterns, operator speeds, product movement, robot positions, floor traffic, packing capacity, and active promotions together. At 9:00 am, the system forecasts a roughly 35% capacity gap opening in Zone A between 2:00 and 4:00 pm. There's no problem yet — but the system acts on the forecast ahead of time: stations extra operators in Zone A from the morning, starts fulfilling some orders from alternative stock in Zone B, adjusts robot routing, and pulls some picking batches forward.

When congestion in Zone A actually starts building at 2:00 pm, Datanomous WES has already seen it coming. The decision engine engages instantly: pull these orders from Zone B, use robot 72 instead of robot 35, shift operator 18 into Zone A for 45 minutes, run this batch now. Action is taken before the problem grows, before it even fully forms.

• Decision logic — fixed rules vs. learning models with continuous optimization.
• Approach to problems — reactive, intervenes after the problem occurs vs. prevented before it occurs.
• Task assignment — to the nearest or first available resource vs. to the resource that will produce the best outcome.
• Labor planning — a fixed plan vs. dynamically updated through the day.

From the field: a 15-site 3PL deployment

Datanomous has deployed the WES execution layer across all 15 sites for a high-volume pick-and-pack 3PL operator. Before deployment, the operator was working with expensive handheld terminals, pick routing that didn't adapt to real conditions, fixed waves that broke the moment a shipment came in late or an urgent order arrived, and pack or QC bottlenecks that were usually invisible until they'd already put a carrier cut-off at risk.

The deployment introduced hands-free, voice-directed picking, dynamic wave generation from live demand, intelligent routing, and real-time bottleneck detection across all 15 sites.

The waves stopped needing a person. When a disruption hit, the system replanned automatically instead of requiring a supervisor to intervene and cover the gap with overtime.

The targets agreed with this operator ahead of deployment: +15% pick throughput, +10% on-time ship / SLA, −20% overtime during peak, −30% mispicks and rework. These are published pre-deployment targets agreed with the customer, not confirmed post-deployment results — the engagement remains anonymized at the customer's request — included here as a real, representative example of the scale of change being targeted, not a guarantee of outcome for every facility.

The agents behind the floor

Two specialized digital workers do the moment-to-moment work described in the busy-afternoon scenario above — one watching the floor itself, the other watching where an order should ship from at all.

• Facility & WES Execution Agent — watches WES data directly: AMR/AGV fill levels, conveyor faults, shift load, and pack rate. Detects the moment a picking line locks up or fails, and reroutes the work orders assigned to that line onto a backup line through WES, autonomously, within the guardrails set for it.
• Dynamic Sourcing & Routing Agent — watches order address, warehouse fill, freight tariffs, and SLA penalty exposure. When the main facility is running hot enough that a delivery will be late and a penalty will trigger, it takes on a reasonable logistics cost differential and reroutes the order to ship from an available secondary facility instead.

Inside a live negotiation

When an urgent order lands, this is what the agent network actually does in the background — the Signal → Trigger → Action model, playing out in milliseconds rather than a diagram. The scenario below is illustrative, modeled on a 3PL running an Istanbul / Ankara network, to show the shape of the negotiation rather than a specific customer's numbers.

Signal: a VIP order needs a same-day decision

A high-priority B2B order drops into the system. Three digital workers report to the orchestrator agent within the same cycle, each from its own read of the operation:

• Demand & Revenue Agent — “This order is from a VIP account. If it doesn't ship today, the exposure is a meaningful penalty.”
• Facility & WES Agent — “The line at the main facility is locked. Clearing it through overtime would cost more than the penalty itself.”
• Dynamic Sourcing Agent — “The secondary facility has capacity. A modest logistics cost differential ships it today from there instead.”

Trigger: the orchestrator weighs the trade-off

The orchestrator agent compares the three numbers it's just been given — penalty exposure, overtime cost, and the logistics differential — against each other, not against a fixed rule. The secondary-facility option wins because it protects the most margin, not because it was the default or the nearest option.

Action: the decision executes and logs itself

The order is rerouted to the secondary facility's WES queue. The decision, the numbers behind it, and the agents that produced them are logged automatically — a manager reviewing the exception later sees the full trade-off that was weighed, not just the outcome. None of this works without the execution-layer integration we covered in our first post: the Facility & WES Agent's report is only trustworthy because it's reading the same WES data — capacity, faults, shift load — that governs what the floor can physically do, not a stale summary of it.

Why this matters to leadership

• COO — the floor plan adapts to what's actually happening in the building, instead of a supervisor absorbing every disruption manually and hoping the shift still hits its numbers.
• CFO — reduced overtime, fewer mispicks and returns, and less dimensional-weight waste are margin improvements that don't require a facility expansion or a capital automation project.
• CIO — WES runs as an orchestration layer over the existing WMS and equipment fleet. It doesn't require ripping out systems already in place, and every automated action is logged and auditable.
• Operations & site leadership — supervisors spend their time on genuine exceptions and coaching, not rebuilding the wave plan by hand every time something on the floor changes.

Getting the order out of the building on time is only half the job — it still has to leave through the right door, on the right truck, without the operation absorbing carrier detention fees along the way. Our final post covers Deliver: how Datanomous Yard closes that gap.