Android XR on the floor: read access, never control

A maintenance technician stands in front of a stopped press and asks the assistant in her glasses a simple question: why did it stop? To answer, something has to see the press, work out which press it is, read its alarm history, perhaps look up the last maintenance job, and say the answer in her ear. Each of those steps is a flow of data, and each one runs somewhere. Some on the glasses, some in a platform vendor’s cloud, some in the plant’s own systems.

That is the architecture question behind Android XR, and it is worth answering before the first pair of glasses reaches the floor rather than after.

What Android XR is

Android XR is Google’s platform for XR devices: headsets, glasses with displays and audio glasses, with Gemini as the assistant layer, developed with Samsung and Qualcomm. The first device was Samsung’s Galaxy XR headset in October 2025. At Google I/O in May 2026 Google showed smart glasses built with Samsung and Qualcomm, with frames from Warby Parker and Gentle Monster among others. Audio glasses work with a phone, and the Gemini agent carries out multi-step tasks on the phone in the background while the glasses act as its voice and camera. Samsung has announced its own glasses with Gemini for November 2026. XREAL Aura, priced from USD 1,279, is the first priced Android XR device in the display-glasses class; what it could mean at a workstation is in XREAL Aura on the shop floor.

For developers, the Android XR SDK includes Jetpack XR, SceneCore and ARCore for Jetpack XR. For glasses there is Jetpack Projected, where the app runs on a host device such as a phone and projects the experience to the glasses, and Jetpack Compose Glimmer for interfaces on see-through displays. There is a glasses emulator and an API that tells an app whether the device is being worn.

The real cause: an agent on glasses is three systems, not one

The glasses are the visible part. Behind them sit the device’s own compute, the platform vendor’s services and the plant’s systems. How much of the agent’s work happens locally and how much in the cloud or on the phone is not publicly documented, so nobody should plan on an assumption either way. What a plant can decide is what each of the three is allowed to see and do.

Where it goes wrong

The camera stream leaves the building. A photo of a fixture, a drawing pinned to a cabinet, a customer’s part on the bench. If the assistant answers by sending images to a general-purpose cloud service, production knowledge leaves the plant one question at a time, under terms the plant did not write.

The agent is given write access because it is convenient. It starts innocently: let the assistant acknowledge the alarm, then reset the fault, then restart the cycle. Each step is small. Together they put a voice-driven agent inside the control path, which is exactly where nothing we build ever goes. Permissions for an agent are about actions, not only about the camera.

The answer comes from the wrong source. A general assistant can explain what a hydraulic fault usually means. It cannot know that press four had its seal replaced on Tuesday unless it reads the plant’s own record. A confident generic answer at a machine is worse than no answer.

One personal account owns a floor device. A device signed in to someone’s own account, with its history and settings tied to that person, is not a device the plant controls.

The floor depends on the line to the vendor. If the assistant needs the cloud to tell the operator anything, the moment the connection drops is the moment the glasses go quiet, which is when a shift should keep running.

How we think about it: an endpoint, not a brain

None of this is a MESCATOR feature today. It is how we would approach glasses on the floor, and it works whatever platform eventually wins.

Treat the glasses as an endpoint, like a terminal. They authenticate a person and display what that person may see. The intelligence about the plant lives in the plant’s own system.

Keep production data and camera images with the manufacturer. Machine signals, works orders, genealogy and anything the camera captures are processed on infrastructure the plant controls. If a cloud service is used for something generic, such as speech recognition, it is a deliberate, written exception rather than the default.

Read, yes. Control, no. The agent may read state, the current instruction revision, the works order and a genealogy query. It may draft a note or a traceability entry for a person to confirm. It never writes a setpoint, resets a fault or starts a cycle, whatever the platform would technically allow.

Keep the logic on a host you manage. Jetpack Projected’s model, an app running on a host device and projecting to the glasses, means the code that talks to the plant can sit on a company-managed device rather than in an assistant you do not configure.

Log every question and every answer. Who asked what, which source answered, at what time. That is what makes an agent’s answer something a supervisor can check afterwards.

MESCATOR itself runs on your premises and keeps working offline, and it reads the floor without controlling it, which is the position an agent in glasses should inherit. More on the MESCATOR homepage.

A test for this week

Take one question a technician would ask the glasses, such as “why did press four stop?”. On paper, list every piece of data needed to answer it and where each one lives today: on the device, in a vendor’s cloud, or in your own systems. Mark every flow that would carry an image or production data out of the building.

Then list every action the agent could be tempted to take after answering. Cross out anything that touches a machine. What is left, and every line where you wrote “don’t know”, is the brief for a pilot, and you can try it in the glasses emulator before any hardware is sold in Europe.