At IROS 2026 in Pittsburgh, one of the demonstrations that kept drawing a crowd was a robot arm doing something deliberately ordinary: opening a taped cardboard box. Viam’s BoxBot used image-based visual servoing to cut along tape seams just 1–2 mm wide, then handed off to a fine-tuned vision-language-action (VLA) model to peel back the flaps. Both ran on a single machine, with the policy executing locally on an NVIDIA Jetson Orin Nano. A few steps away, visitors could move an SO-101 leader arm, watch a follower arm copy it, then record and replay the episode.
The work on that booth is led by Shannon Bradshaw, Viam’s SVP of Product and Education. Bradshaw and Viam founder and CEO Eliot Horowitz go back to MongoDB, where Bradshaw ran education and helped build the developer programs that supported the database’s growth. At Viam, the New York-based software platform Horowitz founded in 2020 to build, deploy and manage robots, the two are applying a similar playbook to robotics.
RobotToday, an IROS 2026 media partner, followed up with Bradshaw after the conference. One idea runs through his answers. AI agents are making robots much faster to build, so the hard part is shifting to everything around the model: the facts about the machine, the limits on what it is allowed to do, and proof that a task actually got done. Viam calls that layer “the harness for physical AI.”
Infrastructure problems start at robot number three
Viam was founded on the premise that robotics developers should not have to build their own software infrastructure. What customers taught the company, Bradshaw says, is how early that infrastructure starts to matter.
“You don’t need to reach a fleet of 50 or 100 robots before running into problems with configuration, remote diagnostics, and monitoring. Those challenges can emerge when you’re scaling from one robot to three or four, usually the moment a robot has to run without an engineer standing next to it.”
He says Viam has seen that pattern in manufacturing, marine, logistics and hospitality. Over the past year a second lesson arrived: customers’ engineering teams now use AI coding agents to write applications and build integrations, and those agents need context about the machines they run on and the physical world around them.
That is where the harness idea comes from. “Viam serves as the harness for physical AI, giving any agent the facts about the machine it’s working on, enforcing limits on what that machine is allowed to do, and checking whether the work actually got done,” Bradshaw says. “Agents have made it possible to get a robot doing something impressive in days. But a demo only has to work once, in a controlled setting. In real-world deployments, the harness is the difference between a fast demo and a production robot that’s reliable, safe, and scalable.”
In practice, the harness is Viam’s modular architecture and API abstraction layer, plus agent skills, documented APIs and a set of tools in the Viam MCP server. Together they let agents work with a wide range of hardware components. A registry of hardware controllers and services covers model training and deployment, perception and actuation, and fleet monitoring and management.
Why teams with ROS 2 still adopt Viam
For teams that already run ROS 2 and their own cloud tools, Bradshaw says two problems usually bring them to Viam: the build and the fleet. Getting the first robot into production still means integrating hardware from different vendors and writing a lot of glue code before the application works. After that, every new machine in the field has to be deployed, updated and monitored. Home-grown layers, he says, tend to cover part of the job without the remote diagnostics, configuration management and fleet-wide updates teams need, and keeping them running pulls engineers away from the product itself.
His example is Canyon Runner, a marine services company that needed real-time data from hundreds of boats, each with different onboard electronics and patchy connectivity at sea. Using Viam, Canyon Runner integrated each boat’s marine electronics in just over two months, a project it had expected to take years. According to Bradshaw, the resulting fleet-wide view cut time per customer in half and helped grow the company’s customer base by 30%. “As more teams build with AI agents, that same foundation is what lets agents work across a whole fleet,” he says.
BoxBot: deciding where AI belongs
Before IROS, Bradshaw summed up the BoxBot project in one line: “The question isn’t whether to use a VLA, it’s where.” Two Viam engineers collected 125 teleoperated demonstrations with a VR controller, about five hours of data over four days. The team fine-tuned the open SmolVLA model with LeRobot, and the code and dataset are published on Hugging Face.
BoxBot has two very different jobs, and Bradshaw says each got the method that suited it. Cutting the tape along a seam needs high precision, so the team used image-based visual servoing, which keeps adjusting the arm’s motion based on what its cameras see. Opening the flaps is a different problem. “Cardboard is deformable, and the manipulation involved is much harder to model analytically,” he says. That task went to the learned VLA policy, fine-tuned on human demonstrations, while conventional motion planning handles the rest of the application.
He expects that boundary to keep shifting as models improve. What must not shift is the safety layer underneath.
“The limits on where the arm can go and what it can hit have to hold no matter which approach is in control. That’s the importance of the harness in physical AI. We can combine different approaches in one application and swap them as models improve, while the guarantees stay in place.”
What a small arm can teach
The SO-101 station at IROS was built as an entry point. The leader-follower setup let visitors move one arm to control another, then capture and replay the motion, showing how Viam can control hardware and collect data for model training. Because Viam exposes consistent APIs for arms, cameras and sensors, much of what a developer learns on a desktop arm carries over to larger systems without rewriting the application.
Some things do not carry over, and Bradshaw is blunt about which. “What doesn’t transfer is certainty,” he says. “In simulation, you know exactly where the camera sits relative to the arm. On a real desk, it’s wherever someone mounted it, and if the application or an AI agent assumes the wrong position, everything built on that assumption is off.” Simulation also reports for certain whether a task succeeded. On real hardware that has to be checked, which is why Viam has agents confirm their results through the robot’s cameras “instead of taking their word for it.”
SurfaceAI: the hardware you start with is rarely the hardware you keep
Viam’s SurfaceAI product, which sands large, customized parts such as fiberglass surfaces, has been a field test for the platform. Bradshaw points to depth cameras. The team started with an off-the-shelf camera to scan fiberglass, but as it pushed toward production-quality sanding it ran into limits on point-cloud accuracy, scanning distance and glare from reflective surfaces.
The team evaluated alternatives and changed cameras more than once. Because Viam abstracts the hardware interface, none of those changes required rewriting the perception code, motion planning or sanding logic. “With Viam, you can swap hardware without rewriting your application,” Bradshaw says, “and that’s critical in production, where the hardware you start with is rarely the hardware you need over time.”
Platform or custom work?
As SurfaceAI shows, Viam also does application-specific engineering, so it has to decide what goes into the shared platform. Bradshaw’s rule is simple: “If a capability makes the platform more useful for every team building on it, it belongs in the platform. If it’s specific to one customer’s business, it stays custom.”
Over time, Viam wants custom work to become shared building blocks. Teams build their application-specific pieces as modules and can choose to publish them; sharing is opt-in. Bradshaw expects AI agents, which now write more of those modules, to grow the library faster. Some customers build the custom layer themselves. At CompScience, Viam handled camera discovery, video storage and remote device management, while CompScience built its own upload module and safety analytics. For businesses without in-house robotics engineers, Viam’s team “acts as the bridge,” building alongside them until they can take the work over.
Teaching software engineers to work in the physical world
Viam launched its free Viam Education program in July 2026. It now offers three self-paced courses: Viam 101 (robotics fundamentals, taught in simulation), Viam 102 (production-ready module development) and an SO-101 course on teleoperation and motion capture with real hardware. Hackathons and community events round out the program, including a one-day hackathon with SPC, a Fine Motor Skills robot hackathon and the “Code That Moves” robot hackathon.
The target audience is robot builders: software engineers moving into robotics and physical AI, and experienced roboticists who want to learn the platform. At several recent hackathons, Bradshaw says, more than half of participants were software engineers, including people already working at robotics companies and founders building their own startups. For them, the biggest adjustment is the physical world itself, with its motion, calibration, mixed hardware and real-world variability. Most traditional software runs in far more predictable conditions.
Bradshaw is candid that education is part of Viam’s developer adoption strategy. He says the courses still have to be useful in their own right, which sometimes means covering solutions and technologies that are not specific to Viam. Enrollment and completion are useful indicators, but they are not the goal.
“For me, the ultimate measure of success is whether someone can take what they’ve learned and build something independently.”
The question he cares about, he says, is whether someone who finishes a course or a hackathon goes on to build an application of their own without a set of instructions from Viam. The learning also runs both ways. Watching where developers struggle shows Viam what to improve in its courses and in the platform itself.
More hands-on events are on the calendar. Viam is running the Harnessing Physical AI & Data Hackathon with MongoDB in San Francisco on October 29–30, followed by the Edge of Intelligence Hackathon with Intel on November 13 at Viam in New York City. Between events, Viam also hosts Open Labs on Fridays.
A common layer for cross-border deployments
Asked about Chinese robotics companies expanding into US and European operations, Bradshaw described the integration gap in general terms. A single application may combine an arm from one supplier, cameras from another and a separate system for monitoring and management, and joining them can take a lot of custom engineering. Viam addresses part of that with a hardware-agnostic platform and common APIs across a wide range of arms, cameras and sensors.
Remote support is the other half. For connected machines, Viam provides diagnostics, logs and monitoring, which reduces the need for engineers to travel to a customer site whenever something goes wrong. Bradshaw says the same applies to AI agents: “Because each machine’s hardware, setup, and limits are defined in one place, an agent can work on a deployment from anywhere without guessing about the robot it’s working with.”
The next milestone: agents that work when nobody is watching
Bradshaw names Viam’s hardest challenge for the next 12 months plainly: making AI agents reliable enough to work with physical machines. At Viam’s hackathons, developers already use tools such as Claude Code and Codex to learn the platform and build working applications. Engineers who have never touched a robot arm, he says, can get one moving and doing something useful in under an hour.
“Getting a robot moving at a hackathon is different from an agent operating one in a real facility, every day, without someone watching,” he says. To close that gap, agents need reliable information about the hardware in front of them, what it can do and which actions they are allowed to take. “Those aren’t things we can leave to a model to figure out on its own.”
Success, in his view, would mean developers taking on increasingly complex robotics applications with less custom engineering and less manual intervention. The broader goal, Bradshaw says, is for developers to spend less time building and maintaining the infrastructure around their robots and more time on what those robots can actually accomplish.
Leave a comment