How I Use an AI Agent (Hermes) to Coordinate Embedded Development

An AI agent can read a linker map faster than I can, draft a driver in minutes, and review a pull request at 2 a.m. It can also be confidently wrong about hardware it has never touched. In embedded work, where a wrong guess bricks a board, the question is not whether to use agents but how to keep them honest.

Since August 2026 I coordinate most of my development through Hermes Agent, an open-source agent harness, alongside Claude Code. This website is built the same way. The setup is boring on purpose: small tasks, explicit rules, a human at the merge button, and a knowledge base that keeps what we learnt.

In this article I show how a piece of embedded work flows through that setup, from task spec to merged change to reusable lesson, and the guardrails that make it safe.

1. One context file per repository

Every repository carries an AGENTS.md: what the project is, how to build and test it, and the rules that are not negotiable. It is a plain Markdown file in git, so Claude Code, Codex and Hermes all read the same instructions, and a new teammate can read them too.

The rules are short and blunt. For this website they include:

• Never invent technical facts: no register values, timings or “verified on hardware” claims without a source.
• Never publish employer or customer names.
• One task, one branch, one pull request. The human merges.

Reusable know-how (“how to review a PR”, “how to write a lesson page”) lives in skills: small instruction files the agent loads when the task needs them. When several repositories belong together, I open them in one workspace, so the agent sees the whole system instead of one repository at a time.

2. Small task specs, written before the work

Agents do well with a precise brief and badly with a vague wish. Every task is a file with a fixed shape:

The order of the backlog is the priority. The agent picks the first open task whose dependencies are done and follows a fixed protocol: select → prepare → implement → verify → hand back.

3. Separate agents for doing and checking

In Hermes each agent is a profile with one job. For this website:

• a dev agent implements the task and opens the pull request,
• a tester agent reviews it and either approves or sends it back,
• a gate agent waits until I have merged the previous change, then releases the next task.

They hand work to each other as cards on a Kanban board. Review rounds are capped: past the limit, the task is blocked and lands on my desk instead of looping forever. Before any of this ran unattended, the first task went through as a supervised dry run.

My own job shrinks to two things: planning the backlog, and reviewing and merging the pull requests. That is deliberate. Merging is where responsibility sits, so it stays with a human.

4. On the bench: useful, and not always right

Agents are strongest where the evidence is text: build flags, a linker map, readelf output, a trace log. Given those, an agent can explain a fault before main() faster than I can read the map myself, and the explanation is often right.

Often, not always. A second symptom on the same board can have a completely different root cause, and the agent will happily fit it into the first explanation. Only the bench tells the two apart.

5. Turn every proven fix into a lesson

The part I value most is what happens after the merge. When something is proven, meaning a merged change, a bench-confirmed measurement, a root cause, or a decision backed by numbers, it becomes one lesson page in a knowledge base (an Obsidian vault in git). Routine changes are skipped.

Each lesson page has a fixed shape: the mechanism, the pitfalls, the evidence, and a private section for project specifics. The public part is written generically from the start, so it can become a blog post later without leaking anything. Several posts on this site started exactly that way.

A nightly run scans the day’s merges and drafts lessons for the non-routine ones. The evidence rule is strict: if a page has no bench measurement, it says so in plain words rather than implying one.

6. Guardrails against leaks

Agents write fast and do not get tired, which is exactly why the checks have to be automatic. Every write to the knowledge base goes through one script that refuses to commit when it finds:

• secrets and tokens (API keys, private keys, password patterns),
• C/C++ code blocks longer than 20 lines (a pattern is fine, a copied function is not),
• any name on a per-machine deny list of customer names, which itself is never committed,
• prices in work notes.

The script never force-pushes. When it rejects a note, the note gets rewritten; the check is never bypassed. I tested that it really blocks each of those cases before letting any agent write unattended.

Summary

1. What works: agents implement and review in small, verifiable steps; I plan and merge; every proven result becomes a lesson.
2. What it does not do: replace the bench. Every hardware claim still needs a measurement, and the agent’s first diagnosis is a hypothesis.
3. What makes it safe: written rules in every repo, capped review rounds, automatic confidentiality checks, and a human who owns every merge.

💬 Questions, corrections, or your own war story? Leave a comment below.