Working with your integrator and robot vendors

Most facilities that bring E31 Consulting in already have other people in the building. An integrator who wired the line. A robot vendor whose fleet software runs the pickers or the mobile units. A controls team that owns the warehouse system. The practice does not displace any of them. It builds a use case on the customer's appliance that talks to the systems those people own, by the routes the customer declares.

Who owns what

The practice draws the line early. The integrator owns the integration they built: the connections between the robots, the controllers, and the warehouse system. The robot vendor owns the robots and the vendor's own software. The practice owns nothing on the floor. It builds the agent or workflow on Czar and declares the routes by which that agent may call the systems the others own.

That split keeps responsibilities legible. When a robot behaves unexpectedly, the question of whether the agent asked for it is answered by the run record, and the question of whether the robot did what it was asked is the vendor's. Nobody has to guess.

Declared routes, not shared credentials

Substrate reaches on-premise systems through routes declared in the version. A route names a system and what the agent may do with it. The integrator or the system owner provides the endpoint on their side; the practice declares the route on the appliance side; the customer's role publishes the version that contains it.

There is no shared credential handed around and no agent with general access to the network. If the robot vendor's fleet software is not a declared route, the agent cannot reach it, and the record shows that it did not. The vendor can read the route definition and know exactly what the agent will ask of their system.

Working sessions with the integrator

In a forward-deployed engagement the engineers sit with the integrator the same way they sit with the desk. They learn what the warehouse system expects to receive, which fields matter, which failures the integrator has seen, and where a person on the floor still steps in. That knowledge shapes the bounds in the version.

The integrator often knows things about the floor that no document holds: which dock is slow, which label printer is unreliable, which step is really done by a supervisor with a radio. The agent is better for having those things written into its approval points.

Working with the robot vendor

The robot vendor's interest is that nothing the agent does puts the vendor's safety system in question. The practice shares that interest. The agent does not replace the robot's own safety controls and is not built to reach around them. Where the agent decides, the robot's controls still decide last.

What the vendor gets from the engagement is a clear statement, in the version, of what the agent will send and when a person has approved it first. Many vendors find that more comfortable than an integration they cannot see.

In a mixed estate

A site may have one hall air-gapped and another connected to the systems the customer already secures. Integrators and vendors are used to one or the other. The practice builds for the posture of each segment and does not ask the vendor to change theirs. A route declared in the air-gapped hall reaches only what is in that hall. The split is described in how the practice works inside your posture.

When the engagement ends

The integrator and the vendor keep their relationships with the customer, as before. The customer's team keeps the version, the declared routes, and the record. If the integrator adds a system later, the site team adds a route and publishes a new version; the notes cover it. If the robot vendor changes an interface, the same. Neither needs the practice back for an ordinary change, and the practice is not a standing party to the floor. Where a larger change is wanted, after the engagement: support and the next version describes how it is scoped.