An AI can describe how to cool a room. Getting connected equipment to carry out a useful change is a different engineering problem. The system needs a current measurement, the identity of the equipment, an available command and a way to check what happened after the request left the software.

Physical AI brings intelligence into that relationship with the real world. Robots are a prominent example, but buildings, industrial equipment and other connected systems raise many of the same practical questions. What does the system know about its surroundings? What is it allowed to change? And what evidence will show that the intended result occurred?

At Kilo, an IoT platform for monitoring and controlling connected devices, we work on the operational connection between an AI request and a device workflow. You can explore that connection with an emulated device before introducing real equipment. Understanding the broader category first makes it easier to choose a sensible first project and to judge what a platform actually provides.

What is physical AI, and how does it work?

Physical AI refers to AI systems that use information about the physical environment to understand it and guide or perform actions within it. A useful way to follow the process is observation, interpretation, decision, action and feedback. The details vary substantially between a robot moving through a warehouse and an assistant operating connected equipment.

NVIDIA's physical AI overview emphasizes autonomous machines, spatial understanding, simulation and training. IBM's explanation also discusses systems that combine perception and decision-making with interaction in the real world. These explain why physical AI involves more than producing text about a physical object.

Imagine a hypothetical ventilation project. A sensor reports conditions in a room. Software associates the measurement with the correct space and checks its freshness. An AI component helps interpret the situation or propose a response. An authorized operation can then request a supported controller setting. Subsequent readings help establish whether conditions changed as expected.

Every transition has a question attached. Is the measurement trustworthy? Does the proposal match the available equipment? Can the controller receive it now? Does the response confirm delivery, device state or the actual environmental outcome? Keeping those questions separate makes the workflow easier to test.

This does not mean every useful automation needs AI. A fixed rule that starts a response at a specified threshold remains conventional automation. It may be the right solution. AI can assist configuration or interpretation while that explicit rule continues to govern the repeatable action.

Physical AI examples: robots, buildings and connected equipment

The term covers several kinds of systems, which is why a search for a physical AI platform can return products that solve very different problems.

Robots that adapt to their surroundings

A warehouse robot may need to recognize objects, plan movement and adjust when its surroundings change. NVIDIA describes examples involving mobile robots, manipulators and vehicles, alongside tools for simulation and training. Here, geometry, motion and perception are central. An IoT dashboard alone does not provide those capabilities.

Systems that interpret physical-world signals

Another approach concentrates on making sensor information useful to models and applications. Archetype AI presents its Newton model around interpreting signals from the physical world. When evaluating that kind of offering, examine the supported inputs, deployment requirements and outputs your application will consume. A model's interpretation still needs an appropriate operational workflow if it will lead to equipment changes.

Buildings and connected equipment

A building project might combine sensor readings, equipment information and commands exposed through an IoT platform. The intelligence could help a person investigate a condition or request an available operation. This is the area addressed by Kilo's physical AI platform: connecting AI-assisted work to device context, configured commands and automation controls.

For example, a hypothetical operator may ask which commands a test controller supports and then request one. Kilo's built-in assistant can list existing commands, show the proposed parameters, ask for confirmation and report the execution status. That is a documented workflow, not a claim that Kilo supplies a robotics foundation model or that every controller can be operated this way.

A temperature chart or occupancy dashboard can support a future project, but monitoring on its own should not be presented as an implemented AI deployment. The useful question is which part of the system actually uses AI, and what decision or task changes because of it.

Physical AI vs generative AI and agentic AI

These terms describe different aspects of a system and can overlap.

Generative AI describes systems that generate content such as text, images or code. In an IoT project, a language model might explain readings or help produce a rule. A generated instruction is not evidence that equipment followed it.

Agentic AI emphasizes carrying out tasks through steps and tools. An agent might look up a device, inspect a configuration and request an operation. Its environment can be entirely digital. Whether it should be allowed to perform a particular action is a separate design decision.

Physical AI emphasizes interaction with the physical environment. A project may use a generative model and an agent, but it also needs suitable sensing, action mechanisms and feedback. The consequences extend beyond what appears in the chat window.

AIoT, the Artificial Intelligence of Things, emphasizes combining AI with connected devices and their data or management. Our AIoT architecture and first-project guide explains the device, connectivity and application layers. AIoT can support physical AI, while many AIoT projects focus on analysis or configuration without autonomous actuation.

For a buyer, the labels are a starting point. Ask a provider to demonstrate the exact task you want to perform and identify which parts are implemented in the product, supplied by another service or left to your team.

What does a physical AI platform do?

A physical AI platform should be evaluated against the layer of the problem it solves. For robotics, that may include model training and simulation. For connected equipment, the practical requirements include device context, permissions, command execution, automation testing and feedback. Compare products against the same use case instead of assuming that they are interchangeable.

Preserve the device context

The system must know which asset a request concerns. Names, measurements, timestamps and configured capabilities should remain associated with the correct device throughout the workflow. If an operator asks about a cold room, an answer about a similarly named sensor somewhere else is not useful.

Kilo provides device operations through its built-in assistant and an MCP server for compatible external clients. Inspect the actual available tools and their access requirements. Connecting a client does not create missing hardware capabilities.

Separate permission from confirmation

Permission answers whether the user or integration may perform an operation. Confirmation answers whether the proposed operation should proceed on this occasion. A clear project needs both questions addressed at the appropriate point.

Kilo's built-in assistant asks for confirmation before its direct device-command execution. An autonomous Rules Engine workflow can dispatch a deliberately configured command without a person approving each run. An external MCP client has its own approval behavior, which you must configure and test. Do not assume that connecting a client copies every interaction of the built-in assistant.

Use configured commands and check their result

A natural-language request is too ambiguous to be a device protocol. Kilo's assistant executes existing command definitions with typed parameters rather than inventing a payload. The device must support the operation and be able to receive it.

Dispatch and feedback are separate. A sent request may still be waiting for delivery; a delivered command may still need supported state verification. If the real objective is a change in the room, inspect the relevant subsequent measurement too. Choose an appropriate timeout and a response to missing or contradictory feedback in your project design.

Test the operation and control its release

Kilo's debugger offers Execute, Skip and Mock for supported side-effect nodes. Execute performs the real action and is selected initially. Select Skip or Mock deliberately when testing logic without that action. A mocked result proves something about the rule's handling of that response; it does not prove that a real actuator moved.

Rule history serves another purpose. Restoring an earlier Kilo rule creates a new version in the editor's draft. You then build and deploy it; the currently deployed artifact continues until a replacement is deployed. This preserves a reviewable release process, but it does not undo past physical effects. The debugger and version-history documentation explain these controls.

Physical AI for IoT: test a first device workflow

A useful first exercise is small enough that you can explain every step. Use an emulated device, inspect the information available to the assistant and test one configured command. This is a learning workflow, not evidence that a building or industrial process is ready for autonomous operation.

  1. Create a small test project. Start free in Kilo. The current free plan supports up to five devices, one dashboard and one rule. Use one clearly named emulated device first, following the emulator instructions. Enable command support if this exercise requires it.
  2. Establish the baseline. Read the device's current values and timestamps. Confirm that the test device is the one you intend to use. If a value is missing or stale, resolve that before asking an AI to reason from it.
  3. Inspect the available operation. Follow the device-command guide to configure an appropriate test command with its expected inputs. Ask the assistant to list the commands already defined. Do not treat a suggestion as proof that a command exists.
  4. Review the request. Ask the built-in assistant to run that test command. Read the proposed device and parameters in the confirmation. Cancel an incorrect request and correct its context before trying again. If using an external MCP client instead, verify that client's approval policy before enabling write operations.
  5. Check the reported outcome. Inspect execution status and any configured verification. Record what each result establishes and what remains unknown. An emulated result exercises software behavior; it does not establish radio coverage, hardware response time or physical performance.
  6. Test a failure path. Consider an unavailable device, missing feedback or invalid input. Identify what the operator will see and who should respond. A successful demonstration is more useful when the team also understands how an unsuccessful attempt is reported.

When you are ready for real equipment, verify its model, protocol, command support, connection and installation requirements. Kilo documents commands for supported MQTT devices, Class C LoRaWAN devices and command-enabled emulated devices. Class A LoRaWAN devices receive after uplinks and are not always available for on-demand commands. Compatibility needs to be checked at the device level.

You can purchase project hardware from Kilo Electronics, the separate hardware store. Hardware, connectivity and any applicable model-provider usage are separate costs. Use Kilo's pricing to select the platform capacity needed as the project grows; a larger illustrated deployment should not be assumed to fit the free plan.

My starting point would be a workflow you can explain plainly: this device supplied this reading, this person approved this configured operation, and this feedback tells us what happened. Once that works, you have a concrete basis for deciding where more intelligence or autonomy will help. Explore Kilo's device-control workflow to see the product controls behind that first project.