Demonstration
It wrote the game. Then it played it, the way a person would.
The hardest thing to drive through AMI is not a business application. It is anything that will not wait. So we built one on purpose, put it on the public internet, and drove it on a machine with 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, as any anonymous visitor would, and the agent played the game it had just written.
Between the agent and that laptop there were two wires: one carrying what was on screen, and one carrying what a keyboard would carry. 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 need the game beforehand. It fetched it cold, over the open internet, at the moment of play. The only new software the machine ran 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 indefinitely, 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 AMI 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 production machines are far more forgiving than this one. A loop that holds against something that will not wait can hold 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 AMI, 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 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, 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 channel a person uses.
What this does not claim
It is a demonstration on our own bench, with a game we wrote, so we controlled both ends and no customer workload was involved. It does not show that AMI is quick enough for anything with a human safety or timing requirement, and nothing here is 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.