On-device Agents

Devices that diagnose themselves and guide your operators

Service quality should not depend on a technician being on site. An agent on the device diagnoses faults against device data and service history, and guides users to the right next step, networked or fully local.

Let's get in touch

loop on the device: recognise, decide, act

perspectives in every assessment: device and AI

connectivity needed for the local-only variant

Qualification

When an on-device agent is the right move

These are the situations where service and operation no longer scale with your technicians, and the device itself has to help.

Every fault needs a technician
A technician has to be on site or on the phone for each malfunction, however routine the underlying cause turns out to be.
Knowledge that walks out the door
Troubleshooting know-how lives with a few experts instead of in a knowledge base that improves with every case.
Service quality varies by country
You cannot deliver the same service quality worldwide, especially where technician dispatch is slow or costly.
One interface for every operator
End users and service technicians go through the same fixed interface, regardless of training, language, or role.
AI or rules? Nobody can say
There is no structured way to decide between rule logic and an agent, so budgets go to AI where rules would do, or nowhere.

Every fault needs a technician

A technician has to be on site or on the phone for each malfunction, however routine the underlying cause turns out to be.

01.

Knowledge that walks out the door

Troubleshooting know-how lives with a few experts instead of in a knowledge base that improves with every case.

02.

Service quality varies by country

You cannot deliver the same service quality worldwide, especially where technician dispatch is slow or costly.

03.

One interface for every operator

End users and service technicians go through the same fixed interface, regardless of training, language, or role.

04.

AI or rules? Nobody can say

There is no structured way to decide between rule logic and an agent, so budgets go to AI where rules would do, or nowhere.

05.

Capabilities

What an on-device agent does for your device

Agents that reason over your device data and act where they are needed, built only where rules run out.

Faults diagnosed at the device.
The agent matches the fault against device data, manuals, and earlier service tickets, so a share of issues never reaches a technician.
Networked or fully local.
Connected, the knowledge base grows with every ticket and technician resolution. Local-only, a lighter agent runs without any connectivity.
Technicians as allies.
Service technicians get a pre-diagnosis before they arrive, and their resolutions feed the knowledge base the agent learns from.

The next step, before the question.
The device reads what the user is about to do and brings up the matching controls, so no question has to be typed first.
Expert level for every operator.
Operation is guided so that users without specialist training can work the way your most experienced operator does.

Sensor data with untapped relationships.
Where several factors interact and identical readings call for different behaviour, an agent may find patterns that rules cannot express.
Rules first, agents second.
Where an outcome can be expressed as rules, a deterministic system is cheaper, verifiable, and recommended instead.

Validated against your data.
Your own data shows up front whether the intended outcome is reachable, so no budget goes into a goal the device cannot meet.
A plan if data is missing.
If it is not, you get a documented answer on which data collection would be needed to get there.

We spoke with several providers. Some wanted to sell us a product. Cloudflight wanted to understand our mission. That made all the difference.

Christian Steigelmann

Managing Director (OpenTechCloud)

Reference

10M service requests a year, answered with the right fix

DEBAG is one of the leading manufacturers of professional baking ovens in the bakery industry. In a rapidly changing market, the company aims to simplify the usability of all appliances for various user groups. Together, we developed a platform for DEBAG's products that enables both automatic and manual control of the processes. The design of our solution was recognized with an iF DESIGN AWARD.

100%

of devices networked in one cloud view

operating concept across all devices

Read case study

Collaboration

This is how your on-device agent is built

The same path as every device project, with one extra step: proof that your data can carry the agent.

1
Product vision
Which service or operating problem should the agent solve, and where should your device stand in a few years?
2
Concept validation
Rapid prototypes and design stay ahead of development, so device and agent are assessed from both sides before series work.
3
Prototype, design, build
Rapid prototypes and design stay ahead of development, so device and agent are assessed from both sides before series work.
4
Maintenance to succession
After go-live, the agent is maintained and evolved to its successor. In the networked variant, knowledge grows with every ticket.

Trust

Why manufacturers build on-device agents with Cloudflight

One system, one loop

Recognising a situation, choosing the action, and carrying it out happen in one system on the device, built on your device data, not general knowledge.

Two disciplines, one assessment

Embedded engineering and agentic AI evaluate your case together, so the architecture is not decided by whichever discipline owns the project. You do not coordinate two vendors.

Honest about rules

Where rules solve the problem, we say so, even if that means no agent gets built. You pay for agent architecture only where it earns its place, not where a cheaper system already does the job.

Embedded competence first

Before the agent question comes the device question. Our embedded and HMI engineering is the foundation every agent is built on, from controller to interface.

One system, one loop

Recognising a situation, choosing the action, and carrying it out happen in one system on the device, built on your device data, not general knowledge.

Two disciplines, one assessment

Embedded engineering and agentic AI evaluate your case together, so the architecture is not decided by whichever discipline owns the project. You do not coordinate two vendors.

Honest about rules

Where rules solve the problem, we say so, even if that means no agent gets built. You pay for agent architecture only where it earns its place, not where a cheaper system already does the job.

Embedded competence first

Before the agent question comes the device question. Our embedded and HMI engineering is the foundation every agent is built on, from controller to interface.

Book a meeting

Find out if your device needs an agent

30 minutes with one of our embedded and AI engineers. We look at your device, your service cases, and whether an agent or rule logic fits better.

FAQ

Questions manufacturers ask about on-device agents

No. A local-only variant runs fully on the device with a narrower knowledge scope. Where connectivity is available, a networked variant learns from a growing base of tickets, manuals, and technician resolutions.

How many service calls could your device answer itself?

Loading HubSpot form...

Devices that diagnose themselves and guide your operators