# PAL: Giving AI Agents Hands in the Physical World

> Source: <https://dev.to/hanasite/pal-giving-ai-agents-hands-in-the-physical-world-48mj>
> Published: 2026-06-27 20:11:18+00:00

REPL Is All You Need.A 19-year-old's proposal for an open standard that lets AI Agent control hardware directly.

AI agents can write code, search the web, deploy servers, and manage databases. They're incredibly capable — inside a container.

But ask your favorite AI to **flip a relay**, **read a temperature sensor**, or **scan an I2C bus** — and it can't. Not because it doesn't know how. It knows exactly what `machine.Pin(5, Pin.OUT)`

does. It just has nowhere to run that code.

**AI agents lack a physical execution terminal.**

CLI tools gave LLMs hands in the digital world (`df -h`

, `pip install`

, `docker compose up`

). Embedded systems can give them hands in the real world (`GPIO.on()`

, `ADC.read()`

, `I2C.scan()`

). But nobody has defined a standard for how agents should talk to hardware.

That's what PAL is.

Espressif's "Chat Coding" framework puts a full AI agent on an ESP32-S3 — ReAct loop, LLM calls, tool registry, IM channels (Telegram, WeChat), Event Router. It's impressive engineering. It's also the wrong architecture.

A lighter ESP32 agent. Same architecture, GPIO bugs confirmed. Toy-grade.

Rock solid. But adding a new operation means: write C → compile → flash → reboot. 10 minutes minimum. Agents can't iterate at that speed.

Python libraries everywhere, but 30-second boot, 5W power draw, $35+ cost, no hard real-time. Overkill for controlling a relay.

Here's what everyone missed: **Python's REPL and an AI agent's interaction model are isomorphic.**

```
REPL loop:                    Agent loop:
  >>> type code                 receive task
  execute                       reason → generate code
  see output                    send code to REPL
  >>> type next                 observe result → adjust
```

You don't need a tool registry. You don't need JSON schema. You don't need a Skill Registry. **The REPL is the world's simplest IPC.**

And Python? It's the language LLMs generate best — 25% of GitHub public repos, versus <0.5% for Lua. Claude has seen millions of `machine.Pin()`

calls in training data. It knows how to write this code.

```
┌──────────────────────────────────────┐
│         Cloud Agent (AstrBot)         │  ← Reasoning, planning
└──────────────┬───────────────────────┘
               │ WebSocket JSON
┌──────────────▼───────────────────────┐
│        ESP32-S3 PAL Terminal          │
│                                       │
│  Core 0 (C, FreeRTOS, NEVER CHANGES): │  ← Hard real-time
│  · SPI/I2C/UART drivers               │
│  · Hardware watchdog                  │
│  · WiFi auto-reconnect               │
│  · Pin ownership table                │
│                                       │
│  Core 1 (MicroPython, ANYTHING GOES): │  ← Agent playground
│  · WebSocket → JSON → Python exec     │
│  · machine module → hardware          │
│  · uasyncio → concurrent tasks        │
│  · Crash? Core 0 restarts you.        │
└──────────────────────────────────────┘
```

**Core 0 is the brake pedal. It never changes. Core 1 is the steering wheel. The agent can grip it however it wants.**

If the agent writes an infinite loop? Core 0 detects heartbeat timeout → restarts Core 1 VM. If the agent tries to access system pins? `machine.Pin()`

returns `OSError`

. If the agent crashes? Core 0 keeps running. Physical control link never breaks.

No tool schemas. No pre-registration. Just Python code over WebSocket:

**Agent → Terminal:**

```
{
  "version": "1",
  "id": "msg_001",
  "type": "exec",
  "code": "from machine import Pin; Pin(5, Pin.OUT).on()",
  "timeout_ms": 10000
}
```

**Terminal → Agent:**

```
{
  "version": "1",
  "id": "msg_001",
  "type": "result",
  "stdout": "",
  "stderr": "",
  "error": false,
  "exec_time_ms": 12
}
```

That's it. One round-trip over WiFi: <10ms. Python execution: <1ms.

Physical execution needs determinism, low latency, 24/7 stability. AI reasoning needs elastic compute, large memory, frequent iteration. Forcing both onto one MCU is asking one chip to do two contradictory things.

A single cloud agent can manage dozens of PAL terminals across a factory floor. Agent-on-Device requires one agent instance per node — no global perspective.

Cloud agent misbehaving? Cut the WebSocket. It's over. Agent-on-Device misbehaving on an MCU? You wait for the hardware watchdog to trigger — that's your only recovery mechanism.

Hermes-style skill accumulation, vector databases, MCP tool chains, SQLite persistence — all mature AI infrastructure. None of it needs to be squeezed into 8MB of PSRAM.

**PAL IS:**

**PAL IS NOT:**

PAL is a **draft specification (v0.1)**. I'm a freshman at Anhui University of Science and Technology. The reference implementation (ESP32-S3 Core 0/1) is under development.

*Note: I'm currently preparing for exams and still learning how to express technical ideas fluently in English, so I used Claude to help draft and polish this post. All ideas, architecture, and the PAL specification itself are my own work.*

This spec is open for discussion. I'm looking for:

"The best way to predict the future is to define it."

— PAL v0.1, 2026