Why a Modern MES Has to Run a Mixed Robot Fleet

Walk a Tier-2 plant that's started automating and you'll usually find the same picture: an AMR from one vendor moving totes, a couple of AGVs from another running fixed routes, a robotic arm at one station, and a forklift someone's been promised will go autonomous "next year." Four robots, four vendors, four apps. None of them knows the others exist.

Each one arrived on its own software island. The AMR has a fleet manager. The arm has a teach pendant and a PLC. The AGV runs off floor tape and a controller from 2014. They were all sold as "automation," and each does its job well enough. But there's no single place that knows what the whole floor is doing, so nobody is actually coordinating them. The plant bought robots. It didn't buy automation.

That gap is where the MES has to step in. "Does your MES support robots" is quietly becoming one of the most important questions a plant can ask — except the honest version is "does it support all of my robots, including the three I haven't bought yet."

A mixed fleet is the normal case, not the exception

No plant standardises on one robot vendor, and they shouldn't. Different jobs need different machines. AMRs for flexible transport, AGVs for high-volume fixed routes, arms for pick-and-place, autonomous forklifts for pallets. And they get bought over years, as budget allows, from whoever won that quarter's deal. So a real floor is always a mix. Heterogeneous by default.

The trouble is that the vendors aren't built to share. Each fleet manager quietly assumes it owns the floor. It optimises its own robots and stays blind to the rest. Put two AMR fleets from different vendors in the same aisle and they'll happily deadlock, because neither one knows the other is there. The more you automate, the worse the coordination problem gets — which is the opposite of what you were promised.

Why coordination belongs in the MES

The MES is the only system that already knows what the plant is trying to make, in what order, by when. It has the production context. A robot fleet manager knows where its robots are; it doesn't know that line 3 is about to change over and won't need totes for the next twenty minutes. Only the MES can turn "move this here" into "move this here because the schedule needs it there."

So the MES becomes the coordination layer. It sits above the individual fleet managers, talks to each of them, and arbitrates between them. It doesn't replace the vendor software — the arm keeps its controller, the AMR keeps its fleet manager. The MES just tells each one what the plant needs and lets it do what it's good at. Think of it as the shift supervisor for the robots: it doesn't drive them, it decides what matters next and who does it.

For that to work, the MES has to be genuinely vendor-neutral. The moment it only speaks one robot brand's language, you're back to islands — just a bigger one. The whole point is that it can talk to the robots you've already bought and the ones you'll buy in three years from a vendor that doesn't exist yet.

Why top-down automation stalls

The usual pitch for automation is top-down. Design the fully automated line on paper, buy everything at once, integrate for eighteen months, then go live. For a greenfield plant with deep pockets, that can work. For the plant that already exists, it rarely does. The capital is enormous, the downtime is unacceptable, and you're betting the whole floor on one big integration going right. Most plants can't take that bet, and the sensible ones don't.

So they do the reasonable thing instead: buy one robot, prove it, buy the next. Bottom-up. The catch is that bottom-up without a coordination layer just produces the island mess we started with — a floor full of machines that each work alone.

The bottom-up approach that actually works

The fix isn't to stop buying robots one at a time. It's to put the coordination layer in first — before the robots, or alongside the first one — so every new machine plugs into something that already understands the floor.

It goes in three steps, and each one is useful on its own:

First, visibility. Most plants already have cameras watching the floor for security. Point them at production instead and you get an honest, real-time picture of what's happening — cycle times, stoppages, where work actually flows and where it jams. This needs no robots at all, and it pays for itself by surfacing the hidden downtime every plant is losing. It's also the foundation everything else sits on.

Then coordination. Once the system can see the floor and knows the schedule, it can start directing the robots that are there. One AMR, then two, then the arm — each plugged into the same brain that already understands what the plant is making. The robots stop being islands and start being a fleet.

Then autonomy. With visibility and coordination in place, you can hand more decisions to the system. It re-routes a robot around a blocked aisle, holds a delivery because a line is in changeover, re-sequences work when a machine goes down. The floor starts to run more of itself, station by station.

Every rung of that ladder is worth climbing on its own, and each one de-risks the next. You're never betting the plant on a single leap. You're solving a real problem this quarter and quietly building the foundation for the next one.

This is also how you get ready for physical AI

There's a lot of noise right now about physical AI — machines that perceive, reason and act in the real world rather than just on a screen. It's real, and it's coming to the factory floor. But you can't drop physical AI onto a plant that can't see itself and whose robots don't talk to each other.

Physical AI needs two things most plants don't have yet: a trustworthy, real-time model of what's actually happening on the floor, and a coordination layer that can act across every machine on it. The bottom-up approach builds exactly those two things — not as a science project, but as a side effect of fixing today's problems. By the time end-to-end automation is affordable and proven, the plant that went bottom-up already has the groundwork laid. The plant that waited has to start from zero.

That's the quiet advantage of doing it this way. You're not automating for its own sake or buying robots to look modern. You're solving real problems now — hidden downtime, uncoordinated machines, coordination done by people with radios — and the same work leaves you standing on the right foundation when physical AI shows up for real.

Why a complete system pays back better than a pile of robots

A robot on its own has a payback number on a spreadsheet. The same robot inside a coordinated system has a much better one — and most plants never see it, because they buy the robot and never build the system. Here's where the extra return actually comes from.

Utilisation. A robot tied to one line sits idle whenever that line is down, in changeover, or simply running ahead. In practice a dedicated AMR is busy maybe half its shift. Pool the same robots under a coordination layer and the MES sends an idle unit wherever there's work — utilisation climbs into the seventies or eighties. That alone is often the difference between needing six robots and needing four.

Fewer machines for the same output. Because pooled robots cover for each other, you hit the same throughput with fewer of them. Every unit you don't have to buy is capital and maintenance you never carry.

The integration cost falls with each robot. The expensive part of automation was never the robot — it's the integration. The first one is a project. But once a coordination layer exists, the next robot is a configuration, not a project, and the marginal cost of adding it drops sharply. Skip the layer and every robot stays its own integration, forever.

Throughput you weren't counting. Lines quietly lose output to starvation and blocking — a station waiting on material, or stuck because the next one is full. Coordinated handling closes those gaps, so the robots stop being a delivery service you call and start being part of the flow.

Coordination that used to be a person. Today that job is done by people with radios and a WhatsApp group, reacting after the fact. Software does it continuously and ahead of time, and your supervisors go back to running the floor instead of dispatching it.

And the returns compound. This is the part a single-robot ROI can never capture. Every machine on the shared layer adds data — where things jam, how long a handoff really takes, when a route gets congested — and that data makes scheduling better for every robot, not just the new one. The system gets more valuable the more you connect to it. A pile of islands never does.

And the foundation pays a second time. When physical AI is ready for your floor, the coordination layer and the live model of the plant are already there. You bought them to fix this year's problems; they hand you next year's for free.

Where wiseDo fits

This is the layer we built wiseDo to be. It starts from the cameras and machines you already have, builds the real-time picture of the floor first, and grows into coordinating a mixed robot fleet — AMRs, AGVs, forklifts, arms — alongside the people working next to them. It's modular, so you add one piece at a time as it earns its place. And it's vendor-neutral, so it talks to the robots you've already bought and the ones you haven't decided on yet.

You don't have to know your end-to-end automation plan to start. You just have to take the first rung.

---

Want to see where your floor stands?

If you're buying robots one at a time and starting to feel the coordination problem, a free floor walk will tell you honestly what's worth connecting first. Twenty minutes, on your actual floor — no slides, no qualifying form.

Book a free floor walk, or see how wiseDo works across the plant.