A Letter from our CTO
Deployments must be repeatable, not bespoke.
We are building MANTA because we refused to accept that every field deployment has to be a bespoke systems integration project. Software can now reason and plan with increasing capability, but the moment it tries to touch the real world, whether a farm, a factory or a pipeline, it encounters a different problem. Getting code to reliably observe conditions and operate equipment still too often means custom wiring, protocol translation and fragile middleware. Intelligence needs physical access. That requires infrastructure in the environment, and you cannot build that infrastructure with pure code.
That is why we build from the physical interface up: hardware, firmware and the software contract above them. MANTA builds Physical AI infrastructure—a shared foundation of power, compute and connectivity, with configurable perception, control and integration. It connects real-world conditions and equipment to AI and autonomous machines. Our hardware is already deployed on industrial sites, and we are developing the machine-native interface through which intelligence can discover connected capabilities, access observations and request permitted actions. Hardware will change beneath us, but the contract must hold. The principles below explain how we build to that standard.
1. Principles
- The world is the source of truth. Software must distinguish measured physical state from assumptions.
- The interface is stable. Hardware evolves beneath it.
- Execution lives close to the machine as far as reliability, safety and latency require.
- Intelligence and control are separate concerns.
- Failure is a normal operating condition.
- Security spans the whole path, from interface to device.
- Deployment is repeatable, not bespoke.
2. The Gap
Software can increasingly reason, plan and act. But much of its access still stops at the screen.
The physical world—industrial sites, water systems, mines, farms and buildings—still runs on heterogeneous hardware, legacy protocols and one-off integrations. Conditions change beneath the surface. Equipment is spread across a site. Power and connectivity cannot be taken for granted. A camera or a capable model does not make that environment accessible.
The gap is a missing layer between intelligence and the physical world.
3. Physical AI Infrastructure
Physical AI infrastructure gives intelligence a way to observe the world and a way to act.
It starts with hardware in the environment: power, compute, connectivity and interfaces to sensors and equipment. Above that foundation, a machine-native interface makes physical observations and capabilities accessible to applications, agents and autonomous machines.
A drone can contribute an aerial view. Ground sensors can reveal conditions beneath the surface. Connected equipment can provide a means to act. MANTA is building the shared infrastructure through which these systems can access site conditions and equipment capabilities, without rebuilding the entire integration for every deployment.
4. Boundary of Responsibility
To scale Physical AI infrastructure, the boundaries between intelligence, infrastructure and physical machinery must be explicit:
- What MANTA connects to: Existing AI models, applications, autonomous systems and physical equipment. Robots retain their own navigation and manipulation systems. Existing equipment protections and dedicated safety interlocks remain authoritative.
- What MANTA owns: The field hardware, local runtime firmware, equipment interfaces, machine service abstraction and developing machine-native API contract. Focused applications deliver useful work today and help define the capabilities of the shared platform.
- Where responsibility hands over: Applications, agents and autonomous machines request observations or actions through MANTA’s machine-native interface. MANTA’s role is to translate supported requests into local operations, enforce configured permissions and operating limits, and report the available evidence of the result. A command being accepted is not the same as a physical outcome being verified.
System Architecture Flow
| Layer | Responsibility |
|---|---|
| Applications · Agents · AI Systems | Reasoning · planning · operational intent |
| Machine-Native Interface | Observations · capabilities · permitted actions |
| Machine Services | Identity · state · capability · execution · verification · fleet |
| Firmware | Runtime · drivers · local control |
| MANTA Hardware | Compute · I/O · connectivity · power |
| The World | Conditions · sensors · equipment · actuators · controllers |
5. Why It Starts With Hardware
The gap is the missing layer between intelligence and the physical world. That layer starts at the machine: wiring, signals, power and environment. In the real world, equipment exposes voltages, serial lines and legacy protocols, or nothing at all, and sites lose power and connectivity.
Software defines the contract, but hardware must fulfil it. A software representation of a valve cannot move it. A model cannot observe a condition that no sensor measures.
If the physical connection is unreliable, the abstraction above it is unreliable too. State can be stale. Equipment can be unreachable. An acknowledged command may never produce the intended result. Those realities must be handled at the boundary and made visible to the systems using it.
That is why MANTA reaches all the way to bare metal. We own the layer where software meets the machine: the hardware, I/O, communications, firmware and machine services that turn physical conditions and equipment into something software can address.
- Connects through configurable sensors and equipment interfaces, including analog, digital, serial and supported industrial protocols.
- Executes supported functions locally, with defined behaviour when connectivity is lost.
- Uses available physical feedback to verify results and reports uncertainty where confirmation is unavailable.
Firmware and machine services build on that foundation to make connected capabilities discoverable, understandable and operable through a common interface.
So MANTA is a hardware company. We design and manufacture field-deployable devices and build the firmware and machine services on top of them. Owning the stack from the physical interface up lets us engineer cost, reliability and capability together, and lets what we learn in the field feed directly back into the hardware.
That is what turns connecting the physical world from a bespoke integration exercise into a repeatable deployment system.
6. Hardware
MANTA hardware is built for the world as it is:
- A shared core of power, compute and connectivity
- Configurable peripherals for perception and control
- Analog, digital, serial, fieldbus and industrial protocol support, defined by the hardware configuration
- Harsh, remote and power-constrained environments
- Multi-protocol networking and intermittent backhaul
- Modular, repeatable manufacturing
- Remote provisioning, configuration and diagnostics
7. Firmware and Local Runtime
Firmware provides deterministic execution for supported local functions. Physical operations need not depend on a network round trip, and losing connectivity should trigger defined behaviour rather than an undefined state.
The runtime handles device interfaces, local control and recovery. Higher-level intelligence can request an action, but local operating limits and existing equipment protections govern its execution. Behaviour under stale inputs, power loss and reconnection must be specified as deliberately as normal operation.
8. Machine Services
We are building machine services to give connected physical capabilities a consistent software representation:
| Concept | Question it answers |
|---|---|
| Identity | What is this, and where is it? |
| Capability | What can it observe or do? |
| State | What is known now, and how current is it? |
| History | What has it observed or done? |
| Action | What am I permitted to request? |
| Verification | What evidence confirms the result? |
Machine services expose observations and actions in terms software can use: pressure, temperature, equipment state or a permitted operating command. Tool call mapping translates supported action requests into the device protocols and local operations required to carry them out. Units, timestamps, operating limits and feedback remain part of the contract, so a common interface does not hide physical reality.
Machine services also manage fleets: provisioning, configuration, updates and recovery.
9. The Machine-Native Interface
We are developing a machine-native interface as the stable contract between intelligence and MANTA’s deployed infrastructure. Applications, agents and autonomous machines can discover what is connected, understand what it can observe or do, and request access within defined permissions.
The aim is to support a closed loop: observe conditions, request an action and inspect the result. Local execution and equipment protections govern what can happen at the physical boundary.
Hardware, protocols and equipment will evolve. The interface must preserve clear meaning as they do.
10. Conclusion
To build Physical AI infrastructure, we made a deliberate architectural choice: own the stack from the physical interface to the software contract. We design the hardware, build the firmware and develop the machine services that make connected conditions and equipment accessible to intelligence.
We chose the hard path because you cannot fix a physical boundary with pure code.
Each deployment extends that foundation. The ambition is a world intelligence can observe and operate, built through repeatable infrastructure that does useful work today.
— Jr