EdgeEmbed HIL SDK — hands and eyes for AI agents on hardware

AI agents now write embedded software — but they can't validate it blind. The edit → deploy → observe → fix loop has to close on a real target, at the iteration speed AI development demands.

The EdgeEmbed HIL SDK is EdgeEmbed's first fully open-source product: the public hardware-in-the-loop protocol that lets a client — an AI agent, a test script, your CI — talk to a target board through one stable gRPC API, plus everything you need to try it without any hardware at all.

Repository: github.com/EdgeEmbedAI/edgeembed-hil-sdk

What's in the box

Piece	What it does
protocol/	The public EdgeAgentService protobuf contract
client/	Go client bindings and helpers (Dial, resource refs, status)
simulator/	A local, in-memory implementation of the agent service — a mock board on your PC
provider/	Provider interfaces + mock GPIO, log, and deploy providers
profiles/	The JSON board-profile model that declares what clients may touch
examples/	Runnable clients: describe, GPIO drive, log assert, deploy-exec
conformance/	Public compatibility checks for agent implementations

The first public contract is intentionally small: Describe and Health for discovery, GpioRead/GpioDrive, LogTail/LogAssert, and a bounded DeployExec.

Quick start — no board required

Requirements: Go 1.25+.

git clone https://github.com/EdgeEmbedAI/edgeembed-hil-sdk.git
cd edgeembed-hil-sdk
make test

Start the local simulator (a mock board) in one terminal:

go run ./examples/simulator

Then drive it from another:

go run ./examples/describe   -target localhost:9090
go run ./examples/gpio-drive -target localhost:9090 -alias user_led -value true
go run ./examples/log-assert -target localhost:9090
go run ./examples/deploy-exec -target localhost:9090

A real board uses the same client-side call shape — the endpoint just points at the target's agent daemon instead of localhost.

The safety boundary

The design carries the same philosophy as the EdgeEmbed Runtime: what a client is allowed to do is declared, not assumed.

• The board profile (JSON) says what exists and what is permitted: which resources are discoverable, readable, or drivable, under which friendly alias.
• Drive operations require a profile-bound alias — a client can never actuate a raw hardware ID it happens to know. The board owner decides that user_led is safe to drive and button0 is read-only; the client doesn't need to know (and can't exploit) what they map to underneath.

That rule is what makes it sane to point an AI agent at real electronics.

Learn more

The repository's docs/ directory covers the architecture, the profile and provider models, the simulator, and each example in detail — start with docs/concepts.md. Contributions welcome; see CONTRIBUTING.md.