The Robot Is Only Part of the Story

When we talk about automation, it is easy to focus on the part we can see. A robot moving material across a warehouse. A machine navigating a changing environment. An industrial arm performing a repeatable task.

I’m interested in that work. I’m also interested in everything that has to happen around it.

Someone has to understand the customer’s requirements, assess the site, document the assumptions, prepare the people, and support the system after installation. When something changes, someone has to figure out what that change affects and who needs to know.

That is a big part of why I’m looking forward to the 2026 Robotics Exchange Summit, hosted by SICK Sensor Intelligence, October 5–7 at SICK’s U.S. headquarters in Bloomington, Minnesota.

I’ll be there speaking about agentic AI and its role across the product lifecycle. I’m also looking forward to sitting in the audience and learning from the people building, integrating, and operating these systems.

A room built around deployment

SICK describes the summit as a forum bringing together OEMs, integrators, and end users across mobile, outdoor, and industrial robotics. The emphasis is on practical experience, safety, standards, and system integration. The program includes Monday networking, mobile and outdoor robotics sessions on Tuesday, and industrial robotics sessions on Wednesday. [1]

That mix matters to me because each group sees a different part of a deployment.

A manufacturer understands the product’s capabilities and limitations. An integrator has to make it work with the systems and conditions around it. The customer lives with the result after everyone else goes home.

Put those perspectives together and the questions get more useful. Where did the original assumptions hold up? What took longer than expected? What did the team discover during installation that could have been identified earlier?

Those are the conversations I want to hear.

Where physical automation meets knowledge work

My contribution to the discussion will focus on the information and coordination work that surrounds a product.

An AI Co-Worker could help organize customer requirements, compare information against an approved checklist, prepare questions for an engineer, or assemble a service history for a technician. The value would come from helping people move through a defined workflow with better information and fewer missed handoffs.

For example, consider a prospective mobile robot installation. The customer provides a facility drawing, photos, and throughput goals. Before the quote is finalized, a sales engineering team needs to understand routes, floor conditions, network requirements, charging locations, and interactions with other activities at the site.

An AI Co-Worker could help organize those inputs and flag missing information for review. It could draft a site-readiness question list and make the assumptions behind the proposal easier to inspect.

The engineer would still need to validate conditions and make the decisions. The opportunity is to make preparation more consistent and help the team discover unanswered questions earlier.

That is the kind of practical use case I want to explore: a specific person, a specific task, and a clear way to tell whether the assistance helped.

What happens when something changes?

Deployment is the beginning of an operating relationship. Facilities change. Products evolve. Service teams learn things. Customer expectations shift.

Imagine a facility changes its layout after a robotic system has been installed. That change could prompt questions about routes, procedures, training, and the assumptions used during the original deployment.

A potential AI workflow could help identify related documents, gather the relevant records, and prepare a review package for the responsible team. It could help track whether the questions have been answered and the approved changes communicated.

The design would need a clear boundary: the system helps people identify and manage the review; qualified people own the technical decisions and approvals.

That boundary is part of making AI useful. A team needs to know what the system can do, where its information comes from, and when it must ask for help.

The information behind the automation

My background in training and technical communications keeps bringing me back to the same question: does the person doing the work have the information they need?

Information can be accurate and still be difficult to use. It might live in the wrong system, refer to an older configuration, or depend on someone remembering a conversation from six months ago.

If we want AI to participate in those workflows, we have to understand the information first. Which source is authoritative? Who maintains it? How is it matched to the product or installation? What happens when two records disagree?

These are product and operations questions as much as technology questions. They require participation from engineering, service, technical communications, training, and the people using the equipment.

I want to hear how others are handling that work, especially as systems become more connected and more capable.

What I’m looking forward to learning

I’m bringing my own perspective, but I also want mine challenged.

I want to hear where integration gets difficult, how teams handle exceptions, and which deployment lessons changed the way they approach the next project. I’m interested in what operators and technicians ask for after using a system for a while. I want to understand which improvements make a measurable difference and which features looked more useful in a demonstration than they turned out to be in practice.

The summit also offers a Speed Share format for short application stories covering a challenge, a solution or concept, and a business outcome. [1] That is a useful structure. It gives people something concrete to discuss and a reason to compare experiences.

There is also a separate Robot Interoperability Framework Workshop on October 8, led by Daniel Theobald of the Intelligent Machine Guild. SICK lists topics including human–robot interaction, sharing robot intent, task and environment semantics, and shared world models. [1]

Those topics raise a broader question I find compelling: how do different systems develop enough shared understanding to work together effectively?

Come find the guy in the hat

I’m looking forward to contributing to this conversation through my work at Subatomic and bringing what I learn back to Hat in the Loop.

The opportunity I see is to connect the physical work with the information, decisions, and coordination that support it. That takes people who understand the machine, people who understand the workflow, and people willing to compare what actually happens in the field.

If you’ll be at the summit, come find me. Tell me where a deployment got complicated, where a handoff broke down, or where your team is still spending too much time finding answers.

I’ll be the guy in the hat, probably asking another question.