Product

One toolchain.
Three vendors. Modern software practices.

Koyl is an AI-native PLC development platform built on three pillars: an AI dev loop that works on production industrial code, a deterministic simulator that makes unit testing possible, and lossless round-trip across the three vendors Western industry actually runs.

Each pillar below is a module you can import, run, and test today through the design partner program. The status pill on each section reflects what the code actually does.

01

Ships today

AI dev loop

Chat that reads, edits, and tests your project.

Describe a change in plain English. The agent reads your existing project, applies the edit across files, runs the simulator, and shows you the diff. Refactor inherited logic, generate characterization tests, ingest CSV IO maps, and observe scan-cycle behavior, all from one chat.

  • ● Explain inherited code in plain English
  • ● Multi-file refactors with simulator-verified diffs
  • ● Generate characterization tests for legacy logic
  • ● Ingest CSV IO maps and tag tables
Read more on ai dev loop →

02

Ships today

Testing & simulation

Unit tests on PLC code.

A deterministic scan-cycle simulator that walks the IR. Pin existing behavior with characterization tests, then verify changes before they go near hardware. Use pytest, CI, coverage tools. The entire Python testing ecosystem applies because the source is Python.

  • ● Deterministic scan-cycle execution
  • ● pytest, coverage, CI: out of the box
  • ● Characterization tests pin existing behavior
  • ● AI-generated tests via the chat agent
Read more on testing & simulation →

03

Ships today

Multi-vendor round-trip

AB, Siemens, Beckhoff. Diff-clean.

Open a working L5X, SimaticML, or TcPOU. Edit in Python. Export back. The diff is clean and the structure your team depends on stays intact. The compiler ingests vendor files losslessly and re-emits them so a technician can open the result in Studio 5000, TIA Portal, or TwinCAT 3 without knowing Koyl exists.

  • ● Allen Bradley · ControlLogix / CompactLogix (L5X)
  • ● Siemens · S7-1200 / S7-1500 (SimaticML)
  • ● Beckhoff · TwinCAT 3 (TcPOU, tsproj)
  • ● Lossless parse, raise, lower, export
Read more on multi-vendor round-trip →

End to end

How a typical change moves through Koyl.

A reintegration scenario. Inherited code, mode-gated workarounds, a hard deadline. Five steps from the project as it stands to a verified deploy.

  1. Step 01

    What you inherited

    A TwinCAT project you didn't write. FB_LinearTransfer carries a `mode` flag (loop or reverse) and most of FB_StationSM's transitions check that flag before they fire. Eighteen months ago someone reversed the conveyor segment at station C so it could run as a manual workstation; the gating has been there ever since. The engineer who added it left for another company eight months ago. A `// TODO: remove after C returns to loop` comment sits at the top of FB_LinearTransfer. C is rejoining the loop on Monday.

    Still · to film TwinCAT · PalletLine_v1.tsproj, mode-gated FB ladder
  2. Step 02

    Drop it in. Ask what it does.

    Drop the .tsproj onto Koyl. The project becomes Python: same FB names, same variables, same I/O. Open the chat panel and ask why FB_LinearTransfer has those mode-gated branches. The agent reads the whole project and explains the workaround in plain English: which routines exist only because of the reversal, which gates fire only when `mode = reverse`, which counters never increment in loop mode.

    Still · to film Koyl chat · agent explaining workaround branches
  3. Step 03

    Pin it before you touch it

    Ask the agent to generate characterization tests against the current logic. It writes them: pallet flow A→B→loop, manual handshake at C, LTU extend/retract timing, per-station counters, jam detection, E-stop. Run the open-loop simulator. All green. Whatever you change next, you will know the moment it breaks something else.

    Still · to film Koyl simulate · chat-generated characterization tests, all green
  4. Step 04

    Apply the change

    Tell the agent: C is rejoining the loop, use this IO map. Drop in the panel shop's three-column CSV. Three diffs flash through the editor. FB_LinearTransfer shrinks back to one mode, FB_StationSM's gated transitions collapse, IO addresses re-bind to the new map, and station C gets instantiated. The diff is mostly red. Most of the complexity only existed because of the workaround.

    Still · to film Multi-file diff · refactor with dominant deletions
  5. Step 05

    Verify and deploy

    Re-run the tests. Twenty-five green, one red. C's per-station counter never initializes because the workaround used to set it incidentally. One line. All green. Re-export to TwinCAT. Open the project in the vendor IDE. Activate. The pallet visits all three stations and returns to the loop on the first run.

    Still · to film Factory I/O · pallet completing A→B→C loop

● Stills will be replaced with the demo video as it lands. Same scenario, same steps.

Underneath

The three pillars share one engine.

Underneath the pillars is a single architecture: standard Python parsed with a strict AST allowlist, lowered to a vendor-agnostic Universal IR, then raised back into native vendor files. The IR is a structured Pydantic model: diffable, analyzable, and programmable. AI agents, static analyzers, and migration tools all work against the same surface.

Read how it works →

Design partner cohort open

Bring your existing project. Ship the change without fear.

Ten controls teams and system integrators get hands-on access to the full toolchain (AI chat, simulator, round-trip) with a direct line to the engineers building it.

Apply for design partner program →