Presentation Studio.
An interview goes in; a projector-ready deck with live QR audience polls comes out. 'No human writes code in this repo' is written into the agent contract - and kept.
INTERNAL SYSTEM · REAL INTERFACE, PROTECTED DATA · WALKTHROUGH AVAILABLE ON REQUEST
Every talk was a fresh hand-built app. Deck two nearly destroyed deck one. A dropped tunnel killed a live audience poll mid-session. Decks are software - they needed an engine.
ONE DECK SPEC · FIVE DESIGN WORLDS · REAL RENDERS
A recorded interview goes in; a projector-ready deck with live QR audience polls comes out - built as versioned code, not slideware. 7 decks delivered to ~600 people across Shikho, LightCastle and NSU.
What changed: a talk is now an hour of conversation plus a build - and every deck since the incident carries a permanent poll QR.
SOURCE: His delivery record · Shikho internal, LightCastle, NSU
Pick a moment. This is what the system does with it - every step a deliberate call, none of it visible from the outside.
One prompt gets you a deck. It does not get you a deck engine that survives contact with a live audience.
- The first architecture was wrong - and only real use proved it. A React template engine shipped, grew ten themes, and hit its ceiling: every theme had to pour into the same 19 fixed components. The teardown - the fork below - is the product.
- The polling layer is scar tissue. One permanent QR, two-second polling, glide-updating bars: each choice traces to a live failure in a real room, including a network tunnel that silently ate the fancy solution mid-talk.
- Quality is measured, not vibed. The design tokens were proven by regenerating real published decks and pixel-diffing every slide and every reveal step against the originals - then a geometry harness hunted dead space and overlaps at three screen sizes.
- It runs at zero marginal cost, deliberately. After a five-dollar bill for two runs, the whole pipeline moved off the metered API and onto the subscription. That is an economics decision a prompt cannot make.
Late June. The engine is React with 19 fixed slide templates, and a tenth theme has just shipped as a "style kit". The decks all look... related. The model recommends deepening the kits - the templates themselves stay.
The architecture I'm going to use (my recommendation): a **theme becomes a "style kit"** [...] The theme can repaint and lightly reshape — **it can't change what the slide structurally *is*.** That ceiling is the architecture, not a tuning problem. The StyleKit was a valiant retrofit onto a fixed-template engine, and it can't reach the depth because **the templates dictate the grammar, the design system doesn't.**
It seems we might have built our current system in such a way that we are trying to retrofit and that isn't working - so if required, you can remove the entire current architecture and rethink the architecture so it can handle this. [...] Basically, I am giving you the freedom to not have any legacy code.
But I want a great product whos fundamental job is to create stunning wow slides - with animations, fades, reveals, all of that - something a powerpoint presentation would take months to do.
Thirteen hours later the React template engine was deleted. What replaced it is the 34-system library in the plate above - every deck authored fresh inside its design world, with only the hard-won polling core carried over. The five worlds up there are the same deck spec.
The model optimizes inside the architecture it has. Direction is noticing the architecture is the problem - and granting permission to demolish.