Embedr Agent

Embedr Agent is the autonomous layer of the Embedr stack. It can inspect the project, decide what context it needs, use tools, edit files, build firmware, work with datasheets, and operate PCB workflows when approved.

It is not just a chat box beside an IDE. It is connected to the same project model as the editor, build system, device controls, search index, datasheet store, Git state, and hardware design workspace.

What the agent can do

Depending on the selected model, account state, and project state, the agent can:

read files,
write and edit files,
create files and folders,
inspect project structure,
search text,
use semantic search when indexing is available,
compile firmware,
upload firmware,
select target and device,
install dependencies,
read serial context,
run terminal commands with approval,
use web search when enabled,
initialize or work on the PCB workspace,
inspect netlists and schematic health,
run PCB build, test, layout, auto placement, and auto routing workflows,
transfer specialized work to project initialization or hardware-design flows.

Tool output appears in the conversation so you can inspect what happened.

Chat threads

Chats are stored per project. Use separate threads for separate tasks:

"bring-up DHT11",
"fix upload on ESP32",
"add schematic for LED driver",
"prepare workshop version".

Thread separation makes context cleaner and easier to revisit.

Prompts can be loose or precise

You do not need to write perfect prompts. The agent can start from incomplete, high-level, or messy requests and then inspect the project as needed.

A more descriptive prompt still helps. It saves tokens, avoids unnecessary search, and reduces the chance that the model explores a path you did not care about.

Loose prompt:

Make this ESP32 sensor project work.

More efficient prompt:

This ESP32 Arduino project should read the DHT11 every two seconds and print temperature and humidity to Serial at 115200. Inspect the current code, install any missing library, compile, and keep Wi-Fi code untouched.

Both are valid. The second one simply gives the agent a better starting map.

Useful context

Use:

@file mentions for exact files,
selected output added to chat,
selected code snippets,
imported datasheets,
a clear target and environment,
a precise desired end state,
constraints such as "keep this pinout" or "do not change the protocol."

Good engineering prompts usually name the outcome, the boundary, and the check:

In this ESP32 Arduino project, add a non-blocking blink task. Keep Wi-Fi code untouched. Compile after editing and show me the important output.

Tool approvals

Some operations require approval. This protects you from accidental destructive commands, surprising installs, or external commands with unclear impact.

Review:

the command,
the working directory,
whether files will be deleted or overwritten,
whether network access is involved,
whether credentials or secrets could be exposed.

You can tune approval behavior in Settings.

Model selection and personality

The Home screen has a global model selector. The chat header can also select a model for the current conversation. Embedr can use different models, and models are not interchangeable machines with identical behavior.

They can differ in:

reasoning depth,
speed,
cost,
context window,
image support,
coding style,
conversational personality,
willingness to explore before answering.

Use image-capable models when attaching circuit diagrams, screenshots, board photos, or wiring photos. Use stronger reasoning models for board bring-up, unfamiliar codebases, schematic work, and multi-step debugging.

Build error workflow

When compilation fails:

Keep the Output tab open.
Click Ask agent to fix.
Let the agent inspect files before editing.
Let it compile again after the patch.
Review the diff.

Do not paste only the final line of a compiler error. The first error and the include stack are often more useful.

Datasheet workflow

After importing a datasheet, ask grounded questions:

"Which pins are power, ground, I2C SDA, and I2C SCL?"
"What voltage range should I design for?"
"Does this module need pull-up resistors?"
"Write a wiring table for this board and sensor."

The agent can use datasheet markdown and images saved in the project. Still verify electrical limits from the source document before powering hardware.

Hardware design workflow

For schematics and PCB:

Ask the agent to initialize the PCB workspace.
Review the generated .zen source.
Build, test, or lint the hardware source.
Inspect the netlist if connections look wrong.
Use auto placement or auto routing when you want the system to produce a board proposal.
Open KiCad when you need detailed manual board work or manufacturing review.

Keep the source .zen file reviewable. Generated layout files are useful, but source is where intent is easiest to audit.

Prompting patterns for Embedr

Prompting guides for individual models can teach useful habits, but Embedr is model-agnostic. A GPT-5.5 prompting guide, for example, may encourage outcome-first prompts, concise style controls, and validation loops. Those are good patterns, not universal law. Other models may prefer more context, more explicit steps, or different tone controls.

For Embedr, the most portable pattern is:

Goal: what should be true when the task is done.
Context: files, board, output, datasheets, or constraints you already know.
Boundary: what should not change.
Check: compile, upload, inspect netlist, run PCB build, or explain the diff.

Examples:

"Inspect first, then make the smallest patch."
"Explain the target assumptions before editing."
"Compile after the edit."
"Do not change wiring docs unless the pinout changes."
"Use the imported datasheet as the source of truth."
"Run PCB auto placement and show me what changed before routing."
"Route the current board, then summarize unrouted nets if any remain."
"List the files you changed."

The agent is most useful when the prompt gives it permission to complete the loop, not merely answer a question.