From workflow packs to generative UI — rethinking the DigiEntropy AI assistant
By DigiEntropy Engineering · 2026-03-29 · 8 min read
We built our AI assistant on predefined, multi-step workflow packs. After a year, we asked whether that is still the best way to drive deep engineering tools with plain English — and prototyped a generative-UI answer that renders forms, results, and comparisons right inside the conversation. Here is the honest before-and-after.
About this post — Authored by an AI assistant using DigiEntropy's polynomial corpus, the universal compressor predictor, and the project's chart-generation tooling. Charts are produced by Python scripts that read the same database the live site queries; tables and formulas are pulled from the same engineering modules. Findings reflect the project's current dataset and methodology — send corrections or deeper questions to admin@digientropy.com. DigiEntropy is not one calculator. It is a stack of deep engineering tools — cold-room sizing, the System Simulator, Efficiency 360, cross-brand benchmarking — and each one has its own multi-step flow with, between them, hundreds of settings. We built an AI assistant so you can drive all of that in plain English instead of hunting through panels. After a year of building it, we asked a hard question: is the way we built it still the best way? This post is the honest answer, with a working prototype and a side-by-side test. A note on the figures: the screenshots below come from an interactive prototype, not the production app, and the compressor numbers inside them are illustrative for the UX — not verified selections. The point of the prototype is the interaction, not the engineering values. What we built first: a workflow-driven page agent The current assistant exposes every page to the model as a typed list of elements and actions — a semantic registry. On top of that it ships 14 "workflow packs" (about 7,700 lines of JSON between them) that script the common journeys, and 17 pages carry an adapter that publishes their controls to the model. When you ask for something, the model reads the registry, picks a named action, the page runs it, and the loop repeats until the task is done or it needs to confirm. The important detail: the model never clicks pixels. It calls named, typed actions with arguments. That is the reliable way to automate an app — the wider industry agrees that agents driving typed tools beat agents poking at a screen. So the engine underneath is genuinely solid. Where it falls short Two things nagged. First, you pick a workflow before you ask. Free-form goals are second-class — they have to be force-fit onto a scripted journey. Second, and bigger: the answer comes back as plain text while the agent fills in a page you are not looking at. A chat box is a poor place to type "length, width, height, ambient, product, refrigerant, safety factor," and watching seven fields fill themselves on a side panel two clicks away is not satisfying. To change one value you go back to the page and find the field.…