Ask an AI to explain how a robot could inspect a building and it can produce a convincing answer. Give it access to the building and the harder questions begin. Which sensor belongs to which room? What can the robot actually do? Who is allowed to send it there? How will anyone know whether the inspection happened?

Those questions are the infrastructure behind Physical AI. A model can understand a goal, but understanding is not a connection to equipment. The system still needs a dependable way to turn that goal into operations supported by real devices.

An IoT server provides a useful part of that connection. It brings together device information, different communication technologies and controlled operations. That allows AI to work with a consistent view of the installation instead of rediscovering how every sensor, controller and machine behaves. The interesting opportunity is what becomes possible when those abilities are available together.

Physical AI architecture: from sensor data to confirmed action

A practical Physical AI architecture separates several jobs. Sensors observe the environment. Software keeps those observations associated with the right equipment. AI interprets a request or situation. An execution layer carries out permitted operations. Feedback helps establish the outcome. Each part contributes something the others cannot simply assume.

Consider an illustrative inspection workflow. A building sensor reports activity in a room. An AI-assisted system considers the event and the available context, then proposes that a robot inspect the location. The robot needs to receive a supported mission request. Its own systems handle navigation, and the mission interface returns whatever progress and result information it provides.

That process involves more than moving a message between two systems. The room needs to mean the same place throughout the workflow. The observation needs a timestamp. The proposed task needs to match an available robot capability. The result needs to remain connected to the original request. Otherwise, the software may appear coordinated while people still have to reconstruct what happened.

It helps to distinguish three kinds of success. The software accepted a request. The command reached its destination. The physical task produced the intended result. Depending on the device and its feedback, those may be separately observable events. A platform can accurately report successful dispatch while the actual outcome remains unknown.

The architecture becomes more useful when it preserves those distinctions. A model can explain the available evidence instead of guessing from a single green status. An operator can see where a task stopped. A developer can investigate the right part of the system. Reliability comes partly from making incomplete results understandable, rather than trying to make every response sound successful.

IoT server: how AI discovers devices and their commands

AI needs more than a list of raw measurements. A useful device record describes which physical asset exists, what information it reports and which actions are configured for it. A temperature value, a door state and a robot mission result are not interchangeable just because they can all be represented as data.

An IoT server supplies that operational context. It can preserve device identities, organize measurements and expose configured capabilities through interfaces used by people or software. An AI client can then ask about actual equipment rather than relying on a general description of what a typical device might support.

Commands are especially important. “Lower the setting” sounds clear in conversation but leaves several unanswered questions: which device, which setting, what value and which permitted range? A defined command gives the operation a name and structured parameters. The model can work with those available choices rather than inventing a payload that looks technically plausible.

This is the purpose of Kilo's Physical AI platform. The Kilo IoT Server connects device context, supported commands and automation to AI-assisted workflows. It acts as an operating layer for physical-world tasks: the model contributes interpretation, while the server supplies the configured operations and their records. That is an infrastructure role, not a claim that Kilo replaces a robot's onboard intelligence.

There are different ways to reach that layer. The built-in assistant works inside the platform. Compatible external AI clients can use the tools exposed through Kilo's MCP server. Custom software can use supported APIs. The choice depends on the interaction being built, and available actions still depend on configuration and permissions. Connecting a client does not create missing capabilities in the equipment.

Discovery also needs to remain current. A device might be renamed, moved or taken out of service. A previously available operation may no longer suit the installation. Treating an old conversation as the permanent description of a building would make the model's context drift away from reality. Live platform records provide a better starting point for a new request.

IoT protocols: connecting equipment that speaks different languages

A building can contain equipment chosen at different times for different reasons. Low-power sensors may use LoRaWAN. Other devices may publish through MQTT. A robot or another application may expose an API. These technologies solve different communication problems, so uniformity is not something to assume at the hardware level.

An IoT server can make those differences easier for applications to work with. Connectors handle supported communication paths, while device definitions and mappings give incoming data a usable meaning. The goal is not to erase every difference. It is to stop each new application from having to rebuild the same understanding of the installation.

Units and timing show why this work matters. Two sensors reporting a value of 20 may be measuring completely different things. Two temperature sensors may use different units. A device reporting every few minutes has a different freshness profile from one providing frequent updates. A shared interface still needs to preserve those facts for the model and the workflow consuming them.

Control has its own constraints. Some connected devices only report observations. Others accept commands, but their receive behavior depends on their technology and configuration. A battery-powered sensor designed to conserve energy is not automatically available for an immediate downlink. “Connected” describes a communication relationship, not a promise of instant two-way control.

That is why the building-and-robot example does not require the robot to use the sensor's protocol. It requires the sensor's observation to arrive with enough context, and a separate supported operation to reach the robot's mission system. The server joins the operational information; the robot retains responsibility for its own motion.

Hardware remains a project-specific choice. Appropriate sensors and gateways can be bought through Kilo Electronics, with coverage, power, reporting intervals and compatibility considered together. The software can organize the resulting information, but it cannot correct a sensor mounted where it never sees the event or give a read-only device an actuator it lacks.

Physical AI infrastructure: permissions, feedback and execution history

A model understanding a request does not establish authority to carry it out. Access depends on the connected identity, organization and permitted operations. A system handling several sites or customers must keep those boundaries intact even when a natural-language request sounds reasonable. Familiar device names are not proof of permission.

Approval is a different question. An authorized person may still need to review the specific device, command and parameters before dispatch. Kilo's built-in assistant provides confirmation for direct device-command execution. External MCP clients have their own approval behavior to configure and test. Autonomous rules can perform deliberately configured actions without presenting a chat confirmation on every run.

Feedback then establishes what the operation accomplished. A device might confirm a state change. A later measurement might indicate the expected physical effect. A robot's mission interface might report completion or a failure. Which evidence is available depends on the equipment and integration. Missing feedback should remain visible as missing feedback, rather than being interpreted as success.

Execution history adds continuity. It allows a person to connect a request with the operation that was dispatched and the status that followed. When a result is unexpected, those records provide something more useful than asking the model to explain what it probably did. A good explanation can refer to events the system actually recorded.

Even with those records, some conclusions require care. A controller reaching a requested setting does not prove that an entire room reached the desired condition. A robot arriving at a destination does not prove that its inspection produced a usable observation. The workflow's definition of success needs to match the real purpose of the task, not merely the easiest status to retrieve.

Physical AI platform changes: testing, versioning and rollback

A small rule change can alter how real equipment behaves. Perhaps an inspection now starts after one observation instead of several, or a different branch handles an unavailable device. The important question is what evidence exists before that changed logic is allowed to act. Saving an edit is not the same as proving its behavior.

Workflow testing can use representative inputs to explore the decisions. An old timestamp, a repeated event and an unavailable target each reveal something a normal case misses. Emulated readings can help exercise those paths before all the physical equipment is present. They make the logic observable, but they do not prove radio coverage, robot navigation or mechanical performance.

Kilo's debugger exposes Execute, Skip and Mock for supported side-effect nodes. Execute runs the real handler and is selected initially. Skip avoids that side effect without changing variables; Mock lets the workflow continue using a supplied response. Testing without a real action therefore requires an explicit choice. A debugger session is not automatically a harmless simulation.

Version history answers a different question: which design produced the behavior? In Kilo, restoring an available earlier rule creates a new draft while retaining history. Building and deploying that draft are separate steps. The previously deployed artifact continues until another build is deployed. That makes recovery a deliberate release process rather than an invisible consequence of editing.

Rollback also has a physical limit. Restoring software cannot undo a robot journey that already occurred or another command already carried out. Some ongoing tasks may need a separate supported cancellation or operator response. The useful promise is controlled restoration of logic, followed by a checked deployment—not reversal of the real world.

Those distinctions make testing and versioning part of the application itself. They give an operator a way to understand a change, try its decision paths and recover an earlier design. AI can help author or interpret the workflow while that release process remains explicit. Flexibility and repeatability can serve different parts of the same system.

Physical AI infrastructure FAQ: models, servers and device control

Is an IoT server the AI model?

No. The model supplies capabilities such as interpreting language or observations. The IoT server supplies device context, supported connections and operational controls. Keeping those responsibilities clear makes it possible to change one component without pretending it performs the other's job.

Does every physical action need a new AI decision?

No. Many actions are better described by deliberately configured rules. AI may help build the workflow or interpret an exception while ordinary execution logic handles repeatable cases. Using AI everywhere is not a requirement for useful Physical AI infrastructure.

Does one server make every device compatible?

It can provide a consistent application interface across supported technologies. Each device still needs an appropriate connector, data mapping and available command where control is required. A common interface simplifies integration; it does not eliminate hardware and protocol differences.

What does this infrastructure make possible?

It gives intelligence a practical way to work with an installation's existing capabilities. A model can reason about a task, an IoT server can connect that request to permitted operations, and feedback can show what followed. That is how a convincing explanation in a chat window can become a useful, inspectable operation in the physical world.