In this guide
AI Agents on ESP32: Agentic IoT Final-Year Projects
An agentic IoT system is one that observes its environment, reasons about what it sees, acts on its own, remembers what happened, and can explain why it decided what it did. On an ESP32, that loop is genuinely buildable in 2026 — but only if you split the work honestly: the chip senses and acts, a small local model does the reasoning. This guide shows three working patterns, the parts, the code shape, and the limits you should state in your report.
Why agentic IoT is a strong theme for 2026-27
The agentic-AI wave that swept software in 2025 is now reaching embedded. Open-source builders are wiring ESP32 boards to local language models over MQTT, Espressif's own tooling keeps pushing ML closer to the chip, and edge-AI problem statements keep showing up in hackathons. For a final-year project, the timing is good: the idea is fresh enough to stand out, but the parts are cheap and the software is all open source.
There is also a viva advantage. Almost every examiner asks some version of "what is intelligent about your project?" A system that logs not just its sensor readings but its reasoning — "turned the fan on because temperature rose 3°C in 20 minutes while the room was occupied" — answers that question with evidence instead of adjectives.
The one honest constraint: the LLM does not live on the ESP32
Do the RAM arithmetic before anything else. A 7-billion-parameter model, quantised to one byte per parameter, needs roughly 7 GB of memory. Even a tiny 0.5B model needs about half a gigabyte. The ESP32-S3 — the most capable chip in the family for AI work — has 512 KB of SRAM and at most 8 MB of PSRAM. That is roughly a thousand times too little.
So whenever you see "LLM running on ESP32", what is really happening is one of two things: the reasoning runs on a nearby computer (your laptop or a Raspberry Pi) while the ESP32 handles sensing and actuation, or the "agent" is a much smaller on-device ML model doing perception while something else does the thinking. Both are legitimate engineering. Claiming the full LLM runs on the chip is not. State the split architecture in your report and your viva goes smoothly; hide it and the first technical question sinks you.
Pattern 1: host-reasoned agent (the default build)
This is the pattern behind the open-source project "Agentic IoT with Local LLM" by Indian builder Aaryan Gupta (MIT licence): an ESP32 reads temperature and humidity, publishes the readings over MQTT, a Python agent on a laptop feeds them to a local Ollama model, the model decides an action and explains it, and the command travels back over MQTT to the ESP32. The loop is observe → reason → act → remember → explain, with no cloud API and no subscription.
How it works, step by step:
- The ESP32 connects to Wi-Fi and to a local MQTT broker (Mosquitto running on your laptop or a Pi — no cloud account needed).
- Every few seconds it publishes a JSON reading to a topic like
agent/node1/telemetry: temperature, humidity, a timestamp. - The Python agent subscribes to that topic, keeps a short rolling history, and every few readings asks the local LLM for one JSON decision plus one sentence of reasoning.
- The agent validates the reply against a strict schema (only known commands allowed), publishes the command to
agent/node1/cmd, and appends the decision plus its explanation to a local log. - The ESP32 subscribes to the command topic and drives a relay or LED. A small dashboard (Streamlit in the reference build) shows the live sensor stream next to a "why" column of explanations.
ESP32 firmware shape (Arduino):
#include <WiFi.h>
#include <PubSubClient.h>
#include <DHT.h>
// connect Wi-Fi, then connect to the local Mosquitto broker
// every 5 s: read DHT22, publish JSON to agent/node1/telemetry
// on message at agent/node1/cmd: parse {"action":"FAN_ON"}
// -> digitalWrite(relayPin, HIGH)
Python agent shape:
import json, paho.mqtt.client as mqtt, ollama
history = []
def on_telemetry(msg):
reading = json.loads(msg.payload)
history.append(reading)
del history[:-12] # keep a short rolling window
if len(history) % 4 == 0:
resp = ollama.chat(model="mistral", messages=[
{"role": "system",
"content": "You control one fan. Reply ONLY with JSON: "
"{\"action\": \"FAN_ON\" or \"FAN_OFF\", \"why\": \"<one sentence>\"}."},
{"role": "user", "content": json.dumps(history)},
])
cmd = json.loads(resp.message.content) # validate keys before use
client.publish("agent/node1/cmd", json.dumps({"action": cmd["action"]}))
log_decision(cmd) # append to decisions.csv for your report
Two engineering details matter here. First, never let the model emit raw GPIO commands — constrain it to a fixed action set and validate before acting. Second, budget a few seconds per LLM decision on a laptop CPU, so this loop supervises; anything time-critical stays in the ESP32 firmware as plain thresholds. The reference project is explicitly v0.1 educational code, not safety-critical — treat it as a starting scaffold, not a finished product.
Pattern 2: on-device tinyML agent (ESP32-S3)
If you want the intelligence physically on the chip, the ESP32-S3 is the right part: dual-core Xtensa LX7 at 240 MHz, vector instructions that accelerate neural-network kernels (Espressif's ESP-DL library), 512 KB SRAM with up to 8 MB PSRAM on the right devkit variant, native USB, and a camera interface. It runs genuinely useful small models: wake-word detection, person detection from a camera, vibration-anomaly detection on a motor.
A strong build: a wake-word model listens continuously; on hearing the keyword it wakes a tiny command classifier ("light on", "fan off"); the S3 drives the relays directly. Everything runs in milliseconds, fully offline, no laptop in the loop at runtime. The trade-off against Pattern 1 is reasoning depth — the chip classifies, it does not explain or plan. For many examiners, a live offline demo of this is more convincing than any architecture diagram.
Pattern 3: hybrid — perception on the chip, planning on the host
Combine the two. The S3 runs person detection and only wakes the host agent when something worth reasoning about happens ("person entered the lab after 11 pm"). The host LLM then plans a multi-step response — turn on the porch light, send an alert, log the event with an explanation — and the ESP32 executes. You get the S3's real-time perception, the LLM's planning and explanations, and a demo story that is easy to narrate in a viva.
Bonus pattern: sensing without sensors (Wi-Fi CSI)
The ESP32-C3 can read Wi-Fi Channel State Information — the fine-grained measurements of how radio signals bounce around a room. A moving person disturbs those subcarriers, so the chip can detect presence with no PIR sensor and no camera. The open project caresense_pro demonstrates exactly this: ESP32-C3 plus CSI for privacy-preserving motion sensing. It is a strong differentiator for smart-room builds, with one honest caveat you should own in your report: CSI needs per-room calibration, because every room's radio reflections are different.
Parts and budget (India)
- ESP32-S3 devkit (pick the N16R8 variant with 8 MB PSRAM if you plan camera or tinyML work) — under ₹1,000
- ESP32-C3 devkit as a cheaper sensor node for Pattern 1 — a few hundred rupees
- BME280 or DHT22 sensor, a relay module, breadboard and jumper wires
- Any 8 GB laptop as the agent host (Ollama runs small models fine on CPU), or a Raspberry Pi 4/5
- Mosquitto MQTT broker on the same host — free, local, no cloud dependency
The whole build sits comfortably inside the usual student project budget, and devkits plus sensors tend to get cheaper during the October festive sales.
Demo and viva preparation
Demonstrate the explanation, not just the actuation. Put the decision log on screen: timestamp, sensor trend, action, and the model's one-sentence "why". Examiners will ask "why not just use if-else thresholds?" — the answer is that thresholds cannot fuse context (time of day plus occupancy history plus trend), while the agent can, and it shows its work. They will also ask "what happens when Wi-Fi drops?" — build the answer: the firmware falls back to local thresholds, the agent reconnects and resumes. A limitation you engineered around is a feature in a viva.
Limitations to state in your report
- LLM decisions take seconds on a laptop CPU, not milliseconds — the model supervises, the firmware enforces.
- Small local models hallucinate; the strict JSON schema and action validation are load-bearing parts of the design, not optional extras.
- Wi-Fi must stay up for Patterns 1 and 3; battery operation needs a deep-sleep design you should scope explicitly.
- The reference builds are educational starting points, not certified for anything safety-critical.
Frequently asked questions
Can the ESP32 run a full LLM?
No. The RAM arithmetic in this guide shows why — gigabytes needed, kilobytes available. Use the split architecture (chip senses and acts, a local host reasons) or accept a cloud API's cost and privacy trade-offs.
Do I need internet access for the local-first build?
Only once, to download the Ollama model. After that, Mosquitto and Ollama run on your own network and the demo works on hostel Wi-Fi or with no internet at all.
ESP32, ESP32-S3, or ESP32-C3 — which one?
S3 for camera or on-device ML, C3 for cheap sensor nodes; the classic ESP32 is fine for the MQTT telemetry side of Pattern 1. Match the chip to the pattern.
How much will the build cost?
The devkit is under ₹1,000; sensors, relay and wiring add a few hundred more. The software — Arduino, MicroPython, Mosquitto, Ollama and the reference projects — is all free and open source.
Is one of these patterns enough for a final-year project?
Yes, if you implement it end to end: working hardware, the decision log, a dashboard, and a report that states the architecture and limits honestly. The explainability angle is what lifts it above a standard IoT build.
What if my laptop has no GPU?
You do not need one. Ollama runs small models on an ordinary CPU; the ESP32 side needs no GPU at all.
What is coming next
Projectech is publishing project listings around these exact patterns over the coming days — an ESP32-S3 voice-controlled edge agent, a local-LLM home controller built on ESP32 plus MQTT plus Ollama, a Wi-Fi CSI presence detector on the ESP32-C3, and an autonomous greenhouse agent. This guide is the map; those listings will be the buildable destinations.