Inside the dual-surface co-pilot: from one sentence to a page it drives
By DigiEntropy Engineering · 2026-04-05 · 10 min read
One plain-English request becomes a driven page plus a conversation of interactive cards. Here is every step of how — the inputs, the outputs, and the strategy behind each, with the alternatives we turned down.
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.
You drive DigiEntropy in plain English. You type one sentence — "size this cold room, then pick three compressors" — and a moment later the page in front of you is filled in, a load number sits on it, and a panel on the right holds a ranked comparison you can sort and open. No menu-hunting, no tab-switching.
This post is the engineering tour of what happens in between. Every step, what goes in and what comes out, the strategy we chose, and the alternative we turned down. It is deliberately deep — but the pictures carry the load, so you can follow it without reading a line of code.
A note on the screenshots: the co-pilot is an internal preview, gated to admin and internal users while we harden it. A few product shots are reused from two companion posts, where the exact numbers are verified. The diagrams here are schematic, drawn to explain the flow.
1 turn - one answer from the model - two streams out of it
The thing to notice is the split in the middle: one answer from the model, two streams out of it — one that changes the real page, one that fills the conversation.
2 streams - page commands and cards - one changes the page, one fills the conversation
It returns a single typed object: the commands that change the page, and the cards that fill the conversation.
442 - rows in one catalogue dropdown - kept out of the prompt
A prompt carrying every one of the platform's pages' actions, every option-list, and big catalogues like a 442-row dropdown is slow, expensive, and — worse — it makes the model confident about values it only half-remembers.
0 - bugs from invented tab names - after surfacing the real enum values
Surfacing the real enum values that exist on the page cut the "it picked a tab name that doesn't exist" class of bug to zero.
5 - design forks - each with its reason
Every part of this was a choice with a road not taken. Drive the page: typed actions over pixels. Show results: cards over text. Where data lives: the page, not the chat. Model calls: one turn, not two. The window: movable and branded, not a fixed panel.
The whole loop, in one picture
…