AGENTS.md
Every project is agent-ready
New projects get AGENTS.md, CLAUDE.md, GEMINI.md
and .mcp.json: how to work there, and the icore MCP tools.
Agents design the system.
ICore verifies it and deploys it.
A coding agent builds and edits the model in the project you have open. The simulation, the check of the generated code and the export to your hardware are done by the platform - the agent reads the verdict, it does not write it.
Claude Code
Codex
Gemini CLI
Cursor
Any agent with a shell or MCP
Design · Verify · Deploy
The agent writes the model.
The agent writes the model.
The platform checks it.
Three stages, and only the first belongs to the agent. Everything that decides whether the model works, and whether its code matches it, is ICore's own code running on your machine.
01 · DesignAgent
Build the system
The agent writes blocks, links, parameters and solver settings into the project file, then reloads. The change appears in your window; every line that did not apply comes back with its reason.
$ icore reload
02 · VerifyICore
Run it, then check the code
ICore simulates the model with the project's solver, then builds the generated code with a real toolchain and compares it with the simulation, sample by sample, against a tolerance.
$ icore simulate
03 · DeployICore
Ship it to the target
The verified core is written into the folder your firmware build reads - C, HDL, Structured Text or any of the ten targets. The agent fires it, a pipeline fires it, or you do.
$ icore fire controller
A refused line, a signal that went NaN or a failed check goes back to the agent with
the reason - it corrects the model and goes round again. The verdict is always the
platform's.
01 · Agents design systems
The model is text, so an agent can build it.
The project file is plain recipe text - the same statements the application uses everywhere. An agent edits it in place, like any other source file, in the project you already have open. It never starts a copy.
- Whole modelsControllers, plants, filters,
estimators - drawn from the 806-block library, which the agent can search
with
icore blocksand read withicore describe. - One subsystem
icore push --level Home/Controllerreplaces a single subsystem and keeps its ports, so the wiring above it stays. - Round trip
icore pullhands back the live diagram as text, including what you changed by hand, so the agent reads what is really there before it edits. - Self-correctingA failed line exits with status 1 and names what the level holds, so the agent fixes it without guessing.
$ cat model.icore
blockA = block(Gain, Home) // new block s = subsystem(Home) // new subsystem connect(blockA<1>, blockB<0>) // out 1 -> in 0 blockA.move(120, 40) // +y is up blockA.rename(Gain2) blockA.rotate(90) blockA.commentOut // skip in run
ICore Script - the diagram as text. The interpreter
reads these statements before the console's maths grammar, so their syntax is never
mistaken for arithmetic.
$ a real session, from the manual
$ icore push model.icore model replaced (Undo reverts it): 4 block(s), 3 link(s) $ icore eval 'getBlock(Home/Gain1)' getBlock(): no block 'Gain1' in ICore Blocks/Home -- it holds: Kp, Out, Step, Transfer Function
The push is one Undo step. The failed lookup exits with status 1
and lists what is there - the agent's next line is right.
02 · The platform runs the verification
The agent doesn't grade its own work.
An agent can say a model works. ICore measures it. Both checks below are the platform's code, and the agent only ever sees their result.
- Simulate
icore simulateruns the model from start to stop with the project's solver and summarises every sink - first, last, lowest, highest, mean - flagging any signal that went NaN or infinite and every error the run logged. - Verify the codeOn export, the generated code is built with a real toolchain, driven with a seeded random stimulus and compared with the simulation sample by sample. The residual is reported as a percentage.
- Stop on failureIf the check fails, nothing is
written. The export stops, prints why, and
icoreexits 1.
$ icore simulate
simulated 0 to 10 s, 101 steps; 1 signal(s): Home/Scope:in0 first 0 last 0.999879 min 0 max 0.999879 mean 0.798693
The model run headlessly with the project's own solver settings.
--csv writes every sample to a file as well.$ Verification level, per target
| Level | Compared with the simulation |
|---|---|
| None | nothing - export only |
| Output Gates Only | the model's outputs |
| Gates and Sink Blocks | outputs and every sink block |
| Strict | every signal in the model |
Software targets pass at 0.1 % and measure about
1e-11 %. The three HDL targets carry every signal in Q16.16, so they pass at
1 % and measure about 1e-3 %.
03 · Automated deploys
From a prompt to the folder your firmware builds.
A Deploy to Hardware target names a language, a source subsystem, a verification level and a destination folder. Targets are saved with the project, so once one exists, deploying is a single command - for an agent, a script or a build server.
- MicrocontrollerC or C++, fixed-size, nothing allocated at run time.
- FPGAVHDL, Verilog or SystemVerilog, in Q16.16.
- PLCStructured Text.
- Test rigPython, MATLAB, Java or Rust.
One model can feed all of them at once. A multi-rate model deploys as one target per rate, each from its own subsystem - see multi-target, multi-rate deploy.
$ cat scripts/deploy_controller.icore
t = target(C) t.setConfig(Name, controller) t.setConfig(Source, Home/Controller) t.setConfig(Folder, firmware/controller) t.setConfig(Verification, Strict - All Signals) t.fire()
A target the agent wrote: the controller as a C core for the
board, checked on every signal before a file is written.
$ on a build machine - no window
ICoreBlocks --console "agentServe 0 --project $PWD" & until icore status >/dev/null 2>&1; do sleep 1; done icore simulate icore fire controller icore shutdown
agentServe opens the project headless and serves the
same commands. icore exits 0 when done, 1 when a check or a
line failed, 2 when nothing was reachable - so a failed verification fails
the build.
Working alongside it
In your window, not behind your back.
The agent works on the project you have open, and you watch it happen.
Terminal
A shell inside the app
Code Engine → Terminal starts in the project folder with icore
on its path. Type claude or codex and go.
agent >
You see every command
Each command an agent runs appears in your Command Window, labelled
agent >, with its output underneath.
before-reload
Your edits are kept
Autosave pauses while an edit on disk waits to load, and the model on screen is saved
to .icore/before-reload.iproj before every reload.
The icore client
One Python 3 file the application writes at every start, so it always matches the version
you run. icore mcp serves the model operations as MCP tools.
| Command | What it does |
|---|---|
| icore status | Which application and project are open, and whether an edit on disk is waiting to load |
| icore reload | Re-reads the project from its folder and reports every line that did not apply |
| icore pull / push / apply | The live diagram as recipe text; replace the model or one subsystem; add to a level - each one Undo step |
| icore simulate | Runs the model and summarises every sink, flagging NaN and infinite signals |
| icore targets / fire | Lists the Deploy to Hardware targets; exports one now, verified at its level |
| icore eval / run | Runs console lines, or a saved script from the project's scripts/ |
| icore blocks / describe | Searches the block library; a block's ports and parameters |
Scripts, recipes and templates
The ICore Script IDE (Code Engine → Scripting) keeps the project's
scripts/*.icore in tabs, with breakpoints, stepping and watches. Import as ICore
Recipe… replays a recipe into the level on screen, and Export as ICore Recipe… writes
any level back out. Drop a .icore into the templates folder and it appears in every
template list, without a restart.
The copilot inside the app
Connect an Anthropic or OpenAI key and the copilot panel sees your live diagram in the same language, alongside the block catalog, and answers in it. Its access to the model is read-only - it describes and drafts; applying a script is your action. Your key is held in the system credential store.
See also: One model, every rate, every target · Code export · Verification · Coding agents in the manual
Get started
See it run on your own model.
Download the application from the customer portal, or read the documentation first - the manual, a page for every block, and the full command reference are public.