We're experiencing, for the first time, that the physical world can be automated, not through rigid industrial machinery, but through agile service robots that can move safely in everyday environments. Yet every discussion with hospitals, municipalities, or retail companies begins with the same question:
"Why should we focus on robotics now?"
The honest answer: Not because robots are ready, but because everything around them isn't.
This mismatch has shaped our work from day one. The machines themselves have made enormous progress in recent years: they navigate reliably, avoid people, carry loads, and work shifts where no staff is available anymore. And yet, in practice, many of these machines sit idle or are confined to a single, narrow corridor. The reason is rarely the robot. It lies in an environment that isn't prepared for it.
The Real Bottleneck Isn't Robots: It's Missing Infrastructure
Demographic shifts create bottlenecks across many industries. Robotics could help, but before it delivers real value, fundamental questions must be answered:
- How do robots open doors or use elevators?
- How do they communicate with existing IT systems?
- How are they embedded into processes designed for humans?
- How does a workflow run without manual approval?
In short:
Robots only relieve burden when buildings and processes are robot-ready.
Yet this foundation is missing in almost every organization.
This is not a technical footnote, it is the decisive lever. A robot that travels a route but has to wait at every fire door for a human to open it automates nothing. It merely shifts the work. Real relief only emerges when the door itself becomes part of the workflow, when the elevator responds to the robot, and when the target system knows about the arrival. The actual investment, therefore, lies not in the device but in the connection between device, building, and process.
We Need Middleware for the Physical World
In software, we know: Without operating systems and APIs, chaos emerges. In the physical world, the current state is identical:
- individual robots
- individual apps
- individual gateways
- individual elevator or door systems
- individual siloed solutions
But no common layer that orchestrates everything.
When physical workflows need automation, that's exactly what's required:
An interoperability layer. An operating system for buildings, robotics, and IT. A common language for the physical world.
The analogy to the computer is more than a figure of speech here. No one today would write an application that has to speak directly to every individual printer model, every graphics card, and every network adapter. An operating system abstracts that diversity away and provides a common interface. This is exactly the abstraction layer that is missing in the physical world. Every door manufacturer, every elevator supplier, every robot maker brings its own logic, and without a mediating layer, each integration has to be built individually and by hand. That does not scale.
Why This Step Is Critical Right Now
Many facilities are on the verge of their first service robotics investment. This is precisely where risk emerges:
Starting now without vendor-agnostic architecture creates tomorrow's lock-in.
Once robots are integrated with doors, elevators, or internal processes in vendor-specific ways, dependencies form that are difficult to untangle.
Meanwhile, requirements are increasing:
- more access control
- higher security standards
- highly heterogeneous door and elevator systems
- diverse IT landscapes
Without a common layer, complexity and costs grow, long before measurable relief occurs.
This is especially true wherever robotics is deployed in critical or sensitive environments. Tying a platform proprietarily to a single vendor surrenders not only commercial bargaining power but also control over data flows, security updates, and your own roadmap. An open, vendor-agnostic architecture is therefore not an ideological position but a sober risk decision. It keeps open the options you will still need in five or ten years.
Robotics Doesn't Scale Through Better Robots, but Through Compatible Infrastructure
This sounds counterintuitive but is crucial:
- The fastest robot doesn't deliver the greatest relief,
- but the process that runs without human intervention.
Real-world example: A transport process only relieves burden when the robot can
- open doors,
- use elevators autonomously,
- automatically notify target areas,
- require no manual approval.
Robots don't replace people, they replace journeys. And journeys are only automatable when all components communicate with each other.
It is the classic case of a chain that is only as strong as its weakest link. A transport that runs almost entirely autonomously but needs a manual approval at a single door still ties up staff at exactly that point. The benefit does not partly disappear, it almost entirely disappears, because a person has to accompany the whole route or at least remain available. Scaling only emerges once the last manual breakpoints are gone, and that is a question of infrastructure, not of robot speed.
Why We Founded Athegus
Athegus is a spinoff from Deggendorf Institute of Technology. In our research projects, we saw the same pattern for years:
- Robots function.
- Buildings function.
- But the connection is missing.
From precisely this gap, Axiona emerged: a platform that integrates robots, doors, elevators, and IT into unified workflows.
On this foundation, we build industry-specific products:
- hospOS for hospitals
- shoppiOS for retail
- lodgOS for hospitality
- aviaOS for airports
- tutoOS for guided trainings, e.g. in gyms
- fabOS for industrial micro-transport
The core remains consistent:
Interoperable. Secure. Modular. European.
We deliberately do not claim that software alone solves every problem. Software does not automatically make anyone compliant, and a platform replaces neither good processes nor the organization's own responsibility. What a common layer delivers is both more concrete and more modest: it reduces the number of individual integrations, it makes dependencies visible, and it creates the precondition for security and data protection to be enforced systematically at all.
What This Means for Organizations That "Don't Have Robots Yet"
These facilities benefit most from early architecture planning:
- Which processes are suitable for automation?
- Which building technology must be connected?
- How do you remain independent from vendors?
- How is data privacy ensured?
- How do you reduce future operational overhead?
Addressing these questions now avoids future lock-ins, and establishes the foundation for genuine relief.
The greatest lever, then, lies not in acquiring the first robot but in the order of the decisions. A facility that first understands its processes and its building technology, and only then selects the right device, retains control. A facility that begins with the device and retrofits the infrastructure around it builds in exactly the dependencies that become expensive later. Early architecture planning is therefore not a delay but the fastest path to a system that genuinely holds up over time.
Conclusion: Automating the Physical World Starts with Architecture, Not Robots
Our "Hello World" isn't a robot driving down a corridor.
Our "Hello World" is infrastructure that relieves physical work, in hospitals, retail, hotels, industry.
The future doesn't belong to devices. It belongs to the processes we can automate through them.
Anyone starting today should therefore not ask first for the best robot, but for the architecture that can carry it. To read more about how we think about digital sovereignty and interoperability together, see Sovereignty.