Spatial Computing and AI
Building spatial applications for the small set of tasks that genuinely justify headworn hardware — hands occupied, information needed in place — and saying so when a tablet would serve better.
Spatial computing has a short list of applications where it is clearly better than a screen, and a long list where it is a more expensive way to do something a tablet already does. The engagement usually begins by working out which list your use case is on.
Spatial computing combines understanding of physical space — surfaces, objects, position, hands and gaze — with digital content anchored to it, on headworn or handheld devices. AI provides the perception: recognising what is there, where the user is, and what they are attending to.
When headworn hardware is genuinely justified
| Situation | Why the device earns its place | Maturity |
|---|---|---|
| Hands occupied with the task | A tablet would have to be put down | Strong; the clearest case |
| Information must align with a real object | Position on the thing itself, not described | Strong for guided assembly and maintenance |
| Remote expert needs the wearer's view | Shared perspective plus annotation in place | Mature and widely deployed |
| Training in a space that is unavailable | Simulated environment beats slides | Good |
| Design review at true scale | Judging size and fit in situ | Good for a bounded session |
| General productivity work | It usually does not | A screen is better |
Comfort is a design constraint, not a detail
Sessions are limited by weight, heat, eye strain and how the device sits, and the honest planning number is far shorter than a demonstration suggests. Applications designed for a thirty-minute session that people will actually wear for eight minutes fail for reasons no amount of engineering fixes.
What the AI does here
Recognise the specific object, not the category
Guided maintenance needs to know this is valve seventeen, not that it is a valve. That usually means training on your own equipment rather than relying on a general model, and it is what makes the difference between a demonstration and a usable tool. See object detection.
Anchor content so it stays put
Content that drifts relative to the object is worse than no content, because a misaligned instruction pointing at the wrong component is actively dangerous in a maintenance context. Anchoring is tested in the real environment, including under vibration and changing light.
Read hands and gaze for interaction
Where the hands are occupied, gaze and voice carry the interaction. Both need designing carefully — gaze as a selector is fatiguing if held too long, and voice fails in noisy industrial environments exactly where hands are most likely to be busy.
Respect the frame budget absolutely
Headworn displays are unforgiving about frame rate; dropped frames cause discomfort rather than mild annoyance. Every perception component runs inside that budget or it does not ship, which constrains model size far more tightly than most teams expect.
Handle the privacy question directly
Head-mounted cameras record colleagues, customers and premises. What is captured, what is retained, what is transmitted and how bystanders are informed is settled before deployment, not after someone objects. See data privacy for AI.
How we work
- Test whether the device is warranted against the specific task, with the honest alternative named where it is not.
- Prototype in the real environment early — lighting, noise, vibration and movement break spatial applications in ways an office test never reveals.
- Measure session length with real users, and design to what they will actually wear rather than to what the hardware permits.
- Train perception on your own equipment where specific identification matters.
- Build within the frame budget from the first sprint, because retrofitting performance into a spatial application rarely succeeds.
- Settle the privacy and bystander position before deployment.
How the engagement runs
Whether the hardware is warranted is tested before the application is designed.
Use case and hardware assessment
Whether headworn is justified; device capability, comfort and session length measured with real users.
Environment prototype
Anchoring, tracking and perception tested in the real environment rather than in an office.
Build
Application built within the frame budget, with perception trained on your equipment where needed.
Field testing
Real users, real tasks, real conditions; session length and comfort measured.
Handover
Deployment, privacy position, device management and training handed over.
What you receive
A spatial application people will actually wear, tested in the environment it will run in.
Use case assessment
Whether headworn hardware is warranted, with the honest alternative where it is not.
The application
Built within the frame budget, with content anchored reliably in the real environment.
Trained perception
Recognising your specific equipment where identification matters.
Interaction design
Gaze, voice and gesture designed for the environment's noise and hand availability.
Field test results
Session length, comfort and task performance with real users in real conditions.
Privacy position
What is captured, retained and transmitted, and how bystanders are informed.
Is this the right engagement?
Worth being direct. Spatial Computing and AI is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Workers need information while their hands are occupied.
- Instructions must align precisely with physical equipment.
- Remote experts need to see and annotate a wearer's view.
- Training requires a space or scenario that is unavailable or unsafe.
- Users are available to test with in the real environment.
Choose something else if
- A tablet or screen would serve the task as well or better.
- The requirement is a broader AR or VR experience. See AR and VR AI experiences.
- Sessions need to run for hours, which comfort will not support.
- The privacy position on head-mounted cameras cannot be agreed.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
When is a headset actually better than a tablet?
When the user's hands are occupied with the task, when information has to align precisely with a physical object, or when a remote expert needs the wearer's view. Outside those, a tablet is usually cheaper, more comfortable and equally effective — and we will say so rather than build the more impressive option.
How long will people wear these devices?
Less than a demonstration suggests. Weight, heat and eye strain limit comfortable sessions substantially, so we measure it with your users on your hardware and design to what they will actually wear. Applications built for a session length nobody sustains fail for reasons engineering cannot fix.
Can it recognise our specific equipment?
Yes, and that usually requires training on your own equipment rather than relying on a general model. Knowing that something is a valve is not useful for guided maintenance; knowing it is valve seventeen is the whole point, and that distinction is where most of the perception work goes.
What about cameras recording other people?
It is a genuine issue and it is settled before deployment. What is captured, what is retained, what leaves the device and how bystanders are informed all need positions, and in many workplaces this requires consultation rather than just a policy. See data privacy for AI.
How is this different from AR and VR AI experiences?
AR and VR AI experiences covers building the immersive application generally. This engagement focuses on spatial understanding specifically — recognising the environment and objects, anchoring content reliably, and interacting hands-free. In practice they overlap and we will tell you which framing your project actually needs.
Often paired with this
Most clients combine two or three engagements from the Emerging and Frontier AI pillar. These are the ones that most often run immediately before or after.
Autonomous Systems and Drones
Inspection and survey autonomy with the regulatory route established before anything is built.
Read more →Physical AI and Robotics Integration
Perception and decision-making added to existing robotics, with safety kept out of the learned path.
Read more →Digital Twins and Simulation
Twins scoped to a specific decision, validated against reality, at the fidelity the question actually requires.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.