From Firmware to an Embedded Agent Runtime: Coexistence on Linux-Class Edge Hardware
From Firmware to an Embedded Agent Runtime
An embedded agent runtime does not replace firmware wholesale — it sits on top of it. Conventional firmware (drivers, control loops, the RTOS) keeps owning the hard-real-time and safety layer; an agent runtime adds a higher, data-driven decision layer that reads sensors, reasons, and acts through typed nodes. On Linux-class embedded hardware the two coexist: the RTOS/Linux stack handles deterministic I/O, and a containerized runtime like the open-source edge-agents runtime handles the agent graph.
This page builds on Embedded Agent vs Firmware by grounding the comparison in a concrete runtime, and shows how the architecture layers map onto an actual execution model.
Firmware and an agent runtime own different layers
| Concern | Conventional firmware / RTOS | Embedded agent runtime |
|---|---|---|
| Timing | Hard real-time, deterministic WCET | Soft real-time, event- and data-driven |
| What it owns | Drivers, control loops (PID), safety interlocks | Perception → reasoning → action as a graph |
| How logic is expressed | Compiled C/C++, fixed at build time | Data: a *.workflow.json graph, swappable |
| Update model | Full firmware flash, A/B partitions | Update the workflow or container image |
| Failure stance | Must never be preempted | Degrades gracefully; falls back to firmware |
The agent runtime is the layer that used to be a pile of hand-written if/else policy code bolted onto the firmware. Moving that policy into a typed graph makes it auditable, swappable, and — when the runtime is open-source — reviewable.
Mapping the architecture layers onto edge-agents nodes
The embedded agent architecture defines perception, reasoning, action, and messaging layers. The edge-agents runtime executes a directed graph of typed nodes, and each architecture layer maps onto a node category:
| Architecture layer | edge-agents node category |
|---|---|
| Perception | Hardware-I/O nodes: GPIO, ADC, UART, edge triggers (read side) |
| Reasoning | LLM nodes (multi-provider or local SLM) + control-flow nodes |
| Action | Hardware-I/O nodes: GPIO, DAC, PWM (write side); local calls |
| Messaging | MQTT transport node for device-to-device agent messaging |
| State / memory | Memory nodes, executed as part of the state machine |
Because the whole graph runs as a state machine, the runtime’s behaviour is deterministic with respect to its inputs — a property firmware engineers expect and that distinguishes this model from an open-ended scripting loop.
A minimal workflow reads a sensor, reasons over it, and publishes a result:
{
"nodes": [
{ "id": "read", "type": "gpio.read", "pin": 17 },
{ "id": "decide", "type": "control.branch", "on": "read" },
{ "id": "emit", "type": "mqtt.publish", "topic": "agents/line3/status" }
],
"edges": [
{ "from": "read", "to": "decide" },
{ "from": "decide", "to": "emit" }
]
}
Coexistence on the STM32MP25 and ctrlX CORE
The clearest coexistence story is a Linux MPU like the STM32MP25 (Cortex-A35). Such parts often pair Cortex-A application cores running Linux with Cortex-M coprocessor cores running an RTOS or bare-metal firmware. The deterministic control loop and safety interlocks stay on the firmware/RTOS side; the edge-agents runtime runs as a ~30 MB container on the Linux side, talking to the firmware through the kernel’s device interfaces. The same pattern applies to the Bosch Rexroth ctrlX CORE: the runtime is an application on the controller’s Linux layer, not a replacement for its real-time control firmware.
This is the layer separation that makes “agent runtime and firmware” the right framing rather than “agent runtime instead of firmware.” The runtime is not a target for bare-metal Cortex-M deployment — that remains on the roadmap; see Embedded Agent Hardware Support for the full supported-vs-roadmap split.
Source and next steps
- Repository: github.com/ForestHubAI/edge-agents — the runtime described here.
- Platform: ForestHub.ai — the platform behind the runtime.
- Contrast: Embedded Agent vs Firmware — the conceptual comparison this page grounds.
Related pages
- Embedded Agent vs Firmware — the conceptual comparison.
- Open-Source Embedded Agent Runtime — the runtime in full.
- Embedded Agent Hardware Support — supported vs roadmap targets.
- Embedded Agent Architecture — the layers mapped above.
This page is part of a ForestHub.ai knowledge hub. Working out where an agent runtime sits next to your firmware? Book a meeting →