Demonstration
It wrote the game. Then it played it, the way a person would.
The hardest thing to drive through this interface is not a business application. It is anything that will not wait for you. So we built one on purpose, put it on the public internet, and drove it on a machine that had nothing installed and no route back to us.
What actually happened
Authorship, publication and play, with nothing installed at either end.
The agent wrote a Space Invaders clone from scratch: one HTML file, a canvas, no dependencies, no engine. It published that file to a public address. A laptop on an isolated segment then opened the page in its ordinary browser, exactly as any anonymous visitor on the internet would, and the agent played the game it had just written.
Between the agent and that laptop there were two wires. Video out of the display port, and a USB device the machine believes is a keyboard. No agent software on the target, no credentials, no network path from the target back to us, and no access of any kind to the program's own state. It read the same pixels a person reads and pressed the same keys a person presses.
The target did not even need the game beforehand. It fetched it cold, over the open internet, at the moment of play. The only software the machine ran that it did not already have was a web page.
The whole apparatus
Our own bench, 24 August 2026. A demonstration, not a customer deployment.
Frames as the agent saw them, off the capture device on the target's display output, cropped to the game.
Why a game and not a spreadsheet
A dialog box waits. An invader does not.
Almost every real target is patient. A BIOS screen holds still while the loop thinks, an installer waits at its prompt for as long as you like, and a slow decision costs nothing but time. That patience hides a great deal, and it is exactly what a demonstration should remove.
A real-time game removes it completely. The screen changes whether or not the loop is ready, a decision made on a stale frame is simply wrong, and there is no prompt to wait at. Everything the interface does badly shows up in seconds instead of hiding behind a patient application.
That is the part that transfers. The engagement is not about games, and your machines will be far more forgiving than this one. A loop that can hold a closed loop against something that will not wait can certainly hold one against a firmware menu.
What the numbers were
| How it was driven | Score |
|---|---|
| Sweeping blind, no vision in the loop | 350 |
| Reading the screen and aiming | 1020 |
Same interface, same hardware, same game. The only difference is whether the loop looked before it acted.
Roughly three times the score for adding sight, which is the whole argument for a closed loop in one line. It is also nowhere near what a competent person would score, and we say so below.
Where it stopped, and why that is the useful part
The loop is fast at volume and slow at reflexes.
A blind sweep clears most of a formation in about a minute, because volume is what an untiring loop is good at. What it cannot do is pin a single fast-moving target or dodge something already falling. Both need a correction inside the time it takes to look, decide and act, and that budget is set by the slowest link rather than by the reasoning.
We tried the obvious remedy and it did not work: shortening the interval between looks made the play slightly worse, not better, because a decision taken on less evidence is not an improvement. This is a ceiling in the loop, not a setting, and it is the honest limit of driving a machine through the same channel a person uses.
What this does not claim
It is a demonstration on our own bench, with a game we wrote, which means we controlled both ends and no customer workload was involved. It does not show that the interface is quick enough for anything with a human safety or timing requirement, and nothing here should be read as a benchmark against a person: a competent player would beat these scores comfortably. What it establishes is narrower and worth more: a loop that reads only the screen, acts only through a keyboard, recovers from its own mistakes, and keeps going long enough to finish something.