What Is an MCU Agent? A Precise Definition
What Is an MCU Agent?
An MCU agent is an event-driven firmware program running on a microcontroller that: reads sensors, applies local decision logic (which may include TinyML inference), acts on outputs or actuators, communicates state and events over a structured protocol (MQTT, CoAP, HTTP), and — when its on-device capability is exhausted — delegates complex reasoning to an edge server or cloud endpoint.
This definition rules out a few things immediately. A sensor node that just reads a temperature and publishes every 10 seconds is not an agent — it has no decision logic, no goal, no state machine. A full LLM running on-device is not what we mean either — that cannot run on a Cortex-M class device with 256–512 KB of SRAM. The MCU agent sits between: it acts locally, communicates with structure, and knows when to ask for help.
What does “agent” mean in this context?
The term borrows from autonomous systems design: an agent perceives its environment (sensors), maintains internal state, decides (evaluate a condition, run a classifier, check a threshold), acts (toggle a relay, publish an alert, buffer data), and may communicate with other agents or services.
On an MCU this translates to:
- Perception — ADC, I2C sensors, SPI, GPIO interrupts, serial streams.
- State — A finite state machine in SRAM; policy parameters that can be updated over MQTT.
- Inference (optional) — A quantized ML model (TFLM, Edge Impulse EON, CMSIS-NN) running on-device.
- Action — GPIO, PWM, UART output, actuator control.
- Communication — MQTT publish/subscribe, CoAP, HTTP POST to an edge or cloud endpoint.
- Delegation — An HTTP or MQTT request to an LLM endpoint or fleet agent when local logic is insufficient.
What actually runs on the MCU?
| Component | Runs on-device? | Notes |
|---|---|---|
| Sensor I/O drivers | Yes | ADC, I2C, SPI, UART |
| Event detection (threshold, debounce) | Yes | Low overhead C logic |
| RTOS task scheduler | Yes | FreeRTOS, Zephyr, bare-metal |
| Quantized ML inference | Yes (on capable MCUs) | TFLM, EON compiler; needs ≥64 KB SRAM |
| MQTT / CoAP client | Yes | lwIP, esp-mqtt, Zephyr net stack |
| Full LLM reasoning (e.g., GPT class) | No | Runs on edge server or cloud |
| Vector DB / RAG retrieval | No | Off-device |
| Complex planning chains | No | Delegated via HTTP/MQTT |
What are the hardware constraints?
An MCU agent must be designed around the physical limits of the target silicon. These numbers are not negotiable:
| Device | Core | Clock | SRAM | Flash |
|---|---|---|---|---|
| ESP32-S3 | Dual Xtensa LX7 + vector ISA | 240 MHz | 512 KB | External (16 MB max) |
| STM32H743 | Cortex-M7 + FPU | 480 MHz | 1 MB (864 KB user SRAM) | 2 MB |
| STM32MP157 | Cortex-A7 + Cortex-M4 | 650 / 209 MHz | 708 KB (M4 side) + DDR | — |
| RP2040 | Dual Cortex-M0+ | 133 MHz | 264 KB | External via QSPI |
| nRF52840 | Cortex-M4F + DSP | 64 MHz | 256 KB | 1 MB |
These SRAM figures are the hard ceiling for ML model activation memory. TensorFlow Lite Micro requires the model + activations to fit. A typical keyword-detection model needs ~30–80 KB of RAM; a small image classifier may need 200–400 KB.
How does delegation work?
When the agent’s local logic cannot answer a question — “is this vibration signature anomalous in a context-sensitive way?” — it packages its sensor state and sends a request upstream:
/* Pseudocode: delegation request via MQTT */
cJSON *payload = cJSON_CreateObject();
cJSON_AddStringToObject(payload, "device_id", DEVICE_ID);
cJSON_AddNumberToObject(payload, "feature_vec_rms", ctx.rms);
cJSON_AddStringToObject(payload, "local_class", "uncertain");
char *json_str = cJSON_PrintUnformatted(payload);
esp_mqtt_client_publish(client,
"agents/" DEVICE_ID "/delegate",
json_str, 0, 1, 0); /* QoS 1, retain=0 */
cJSON_Delete(payload);
free(json_str);
The edge or cloud endpoint processes the request and publishes a response to agents/<deviceid>/cmd. The MCU agent listens, receives the decision, and acts. The reasoning capability itself never touches the MCU.
What the MCU agent is NOT
- It is not a “tiny LLM” on a microcontroller. No GPT-class model runs in 512 KB of SRAM.
- It is not just an MQTT publisher. A sensor node that blindly reports data has no agent logic.
- It is not equivalent to TinyML. TinyML is ML inference on small devices — one tool the agent may use. The agent is an architectural pattern; TinyML is one possible capability within it.
- It is not a cloud agent with a small footprint. An MCU agent is edge-first: it acts locally first and escalates only when necessary.
When would you build an MCU agent?
- You need sub-50ms local response (relay trip, motor stop) that cannot wait for a network round-trip.
- You want local anomaly detection without streaming raw sensor data to the cloud.
- You need offline resilience — the agent must act even when connectivity drops.
- You want the device to be command-able: receive updated thresholds, new model weights (OTA), or behavioral changes without reflashing.
Platform example: ForestHub.ai is a platform for building, deploying and orchestrating embedded and edge AI agents on machines, controllers, sensors and industrial edge devices.
FAQ
Q: Can a Cortex-M0 run an MCU agent? Yes, with constraints. The M0 has no DSP extensions and no FPU, so ML inference is slow or impractical. The event loop, MQTT client, and state machine run fine. ML inference is better suited to Cortex-M4F (DSP + FPU) or higher.
Q: Does the agent need an RTOS? Not strictly. A super-loop with interrupt handlers works for simple agents. FreeRTOS or Zephyr become worthwhile when you need concurrent tasks (sensor sampling + MQTT + OTA update), memory protection, or a rich driver ecosystem.
Q: How is this different from just using FreeRTOS tasks? An RTOS gives you scheduling primitives. The agent pattern is a software architecture built on top of those primitives: it defines how perception, decision, action, and communication are structured and how state transitions happen.
Q: Can the agent update its own logic? Yes — via OTA firmware updates or by receiving policy parameters (thresholds, model weights) over MQTT. Receiving new TFLM flatbuffer model weights via OTA is an established pattern on ESP32 and STM32.
Q: Is security built in? Not automatically. You need to enable TLS for MQTT (port 8883), verify broker certificates, manage device credentials (ideally in a secure element), and sanitize incoming command payloads before acting on them.