Melissa Hernandez, Sr Dev Advocate for Temporal, setting the time to beat on the 8-foot WhiteClouds USB-C keyboard at the Temporal booth
Two weeks before AI Engineer World's Fair, Monifa Contaste, from the Temporal field team, reached out to me with a problem that sounded technically fun and logistically deranged.
Our giant 8-foot USB-C keyboard with an army of Ziggys keeping an eye on things
Temporal had an 8-foot-long USB-C keyboard made for Replay to run a typing contest with the awesome folks from Braintrust. It was built by WhiteClouds, required a pallet to move between events, and was exactly the kind of object that makes a conference booth feel like either a game show or a loading dock, depending on how your morning is going. We’d been invited to bring it along with us to AI Engineer World's Fair for a second Temporal booth with minimal notice and needed to figure out something to do with it.
Attendee playing durable wordle next to holographic fans
I also had a pair of holographic fans from that same Replay that Temporal had used as part of the 404 Speakeasy. Fun side note: Replay, where I originally got those fans, was at Moscone West. I flew them home to New York, then flew them back to use them for the first time at Moscone South, a few blocks away from where I had picked them up. This is a normal and efficient way to move hardware if your goal is to make Delta feel under-appreciated.
Kristin Hillary, Temporal's Social Media Manager, had come up with the giant keyboard concept in the first place, and she decided I should be the person to take on the holographic fans. Mason Egger, Temporal Senior Solutions Architect, had already built the original version of Durable Wordle: a Wordle clone where each game session is a Temporal Workflow. I found out about his project at Datadog DASH, which turned out to be the only reason this idea was even remotely possible, because I also had a week of PTO scheduled in the middle of the build window.
Kathy Chen, Staff Growth Marketing Designer, rebranded the game and gave me a Figma file of recommendations before the conference, which moved the whole thing from “technically functional” toward “something people might actually want to walk up and play.” I implemented that polish before the show opened. My live changes came after that, once real people started touching the 8-foot keyboard.
So the plan became:
What if people could walk up to a giant keyboard, play Wordle, and watch the Temporal Workflow history unfold live on a holographic fan?
This was a bad idea in several ways.
It was also exactly the right idea.
The original trick#
The part Mason had already gotten right was the part I did not want to mess with: the Workflow was the game.
Not “the Workflow kicked off a game.”
Not “the Workflow coordinated some backend calls while a web app held state somewhere else.”
The Workflow was the game state.
Each session starts a UserSessionWorkflow. The target word is selected by an Activity. Each guess arrives as a Workflow Update. The Workflow validates the guess, calculates Wordle feedback, appends the result to its in-memory state, and eventually completes when the player wins, loses, or times out.
The web UI is just a skin. You can play the game from the browser, but you can also play it from the Temporal CLI:
temporal workflow start \
--type UserSessionWorkflow \
--task-queue wordle-tasks \
--workflow-id wordle-cli-game \
--input '{"session_id": "cli-test"}'
temporal workflow update \
--workflow-id wordle-cli-game \
--name make_guess \
--input '{"guess": "CRANE"}'
temporal workflow query \
--workflow-id wordle-cli-game \
--name get_game_stateThat boundary did a lot of work. The durable part of the system was not the HTMX form, the keyboard event handler, the leaderboard, or the display. The durable part was the Workflow. Everything else could be improved, swapped, restarted, or made ridiculous around it.
At a normal desk, that is a nice architecture lesson. Maybe a little abstract, but nice.
At a conference booth, standing behind an 8-foot keyboard plugged directly into your laptop, it becomes survival equipment.
The keyboard was the computer#
The giant keyboard was not a prop. It was a USB-C keyboard plugged into my laptop.
That meant when people were playing, I could not use my computer.
This sounds funny because it is funny. It is also the kind of constraint that makes every tiny UI bug become extremely real. A player pressing Enter twice is no longer an edge case. Backspace not working is no longer polish. Focus landing in the wrong input is no longer a frontend nuisance. It is a person standing in front of a palletized keyboard while a line forms behind them.
The repo now has scars from this. They read like boring implementation details until you imagine a person waiting at the booth while I am trying to figure out why Enter feels haunted:
- browser tests for starting the game with both click and keyboard input
- tests around guess submission so Enter does not silently return a 422
- logic to keep keyboard reveal animation synchronized with the Wordle tile flip
- start-over flows that work after HTMX swaps instead of requiring a refresh
- a share screen that waits for the final animation before taking over
None of those sound glamorous. They are exactly the difference between “demo” and “people can actually use this without me apologizing every three minutes.”
The funny thing about conference demos is that users do not behave like your happy-path test. They press buttons too quickly. They walk away mid-game. They press Enter because it feels right. They use the physical thing in front of them, not the mental model you had while writing JavaScript at 1 a.m. They also do not politely finish the game faster than the timer you set while testing, especially when that timer does not return a UI element explaining that they timed out.
The giant keyboard made the game better because it made every interaction bug impossible to ignore.
Making Temporal visible#
The other half of the booth was the holographic fan display.
Attendee playing the game
Temporal is incredibly visual once you know what you are looking at: Workflows, Activities, Updates, Retries, Event History. But to someone walking down an expo aisle, “Durable Execution” can sound abstract.
Wordle gives you a familiar shape. The fan gave me a way to show the invisible machinery.
During a game, the second display tracked the active Workflow and showed the live Temporal timeline. When no one was playing, it went into an attract mode with the Temporal logo, leaderboard, and ambient booth animations. When someone won, it celebrated. When someone lost or timed out, it revealed the word.
The first version of the display was, frankly, a local-only hack in the best possible way.
The app reverse-proxied the Temporal Web UI under the same origin, stripped the frame-busting headers, loaded the Workflow timeline page in a hidden iframe, found the largest SVG in the page, cloned it, inlined enough styles to keep it legible, and fit it into the circular fan display.
I know. This is not a general product architecture. It is not a cloud deployment pattern. It is barely a thing I would want to explain to a security team without coffee. It worked because the whole booth was running locally, and because the job was to make the Temporal event history visible on a weird piece of hardware for four days.
Sometimes “this only works here” is a perfectly valid engineering constraint, as long as you know that is what you are doing.
The fan also forced a lot of practical work. Circular displays are not rectangular screens wearing a costume. Content outside the circle is gone. The calibration UI needed crosshairs and rings. The timeline had to stay inside safe bounds. I needed to create explanations of what the Temporal UI was doing as I started losing my voice. Text needed to be big enough to read while spinning. Loading states looked bad, so I cached the first timeline SVG and reused it as a placeholder. The leaderboard had to scroll through all 25 names quickly without snapping back to the top like nothing had happened. I had to build the calibration UI live while the event was running.
It was absurd. It was also useful: people could see that every guess was not just changing UI state. It was creating Workflow history.
Four days of live mutation#
I deployed it live at AI Engineer World's Fair in San Francisco. The event ran June 29 through July 2, and the commit history for this repo looks exactly like what happened: a dense burst of booth-specific improvements starting the day the show opened.
The first version was enough to get people playing. Then reality arrived.
Over the next four days, I kept making feature updates while the conference was live. Some of them were real features. Some of them were me admitting that the first version had met the public.
- the madlib start screen and leaderboard became more useful for the booth
- the display learned to track the active game and return to idle
- stale games got an inactivity timeout so they stopped pinning the fan display
- the fan got calibration controls, circular safe bounds, particles, win celebrations, and loss reveals
- the keyboard interactions got hardened
- Playwright e2e tests were added for the flows that had already hurt the booth
- the booth launcher moved from “please arrange windows yourself” toward Chrome kiosk windows with fixed display positions
- Chrome's background networking logs got silenced because even the terminal noise was starting to matter
My favorite operational change was the least glamorous one: the deploy process.
At first, changing code meant risking the live booth. That was bad because real users were playing, and also because the laptop running the app was physically occupied by the giant keyboard. So the process changed: Codex worked in isolated worktrees with offset ports and a separate preview lane. I could review a change, wait for a safe moment, and then swap the running booth to the fixed version.
This is not the kind of thing I would have designed in advance. It emerged because the booth was alive and the laptop was, in a very literal sense, busy.
The important part is that the core game state stayed in Temporal. The UI could change. The display could change. The kiosk launcher could change. The leaderboard could get cleaned up. But the mental model stayed steady: the Workflow owns the game.
That was the thing that made the live iteration feel less reckless.
Why Temporal fit this so well#
The obvious version of this article is “Mason built Wordle with Temporal and I added some nifty features to make it work better at a booth.”
That is true, but not quite the point.
The part I keep coming back to is that Temporal gave the demo one boringly reliable place to put the state.
In a normal web app, it would have been tempting to keep the game board in a server-side session, or in a database row, or in the browser. Then the booth features would start accreting around that: display state, leaderboard state, timeout state, winner state, current-game state. Eventually the demo would become a pile of related-but-not-quite-aligned state machines, which is exactly the kind of thing that behaves fine until the booth opens.
In Durable Wordle, the Workflow state is the source of truth:
- a player starts a Workflow
- the Workflow selects a word
- each guess is an Update
- validation and feedback are Activities
- the current board is a Query
- the Workflow completes when the game is done
The rest of the system reads from that.
The SQLite database exists, but only for leaderboard scores and prize outreach. It is not the game. The fan display polls for active Workflows and reads completed Workflow state when it needs to reveal a lost word. The browser can be refreshed. The Worker can replay history. The game still makes sense.
That is the Temporal idea in miniature: long-running application state belongs somewhere that can survive the weird parts.
And the weird parts will come.
Sometimes they look like retries and service failures.
Sometimes they look like an 8-foot keyboard on a pallet.
What I would keep#
If you clone the repo, I would start with the simple version:
uv sync
just devOpen the app, play a game, then open the Temporal UI and inspect the Workflow history. Better yet, play through the CLI once so it clicks that the browser is not the thing holding the game together.
I also tried to keep the repo useful as a teaching resource after the booth nonsense settled down. If you run just dev, you get the version meant for learning and local exploration: Durable Wordle as a Temporal application, without needing to care about my palletized keyboard, lead capture, display calibration, or whatever was happening to the fans. The booth code is still there, because the booth was real and useful and weird, but it is intentionally something you go looking for rather than the first thing standing between you and the Workflow.
Then look at the booth pieces as extensions of the same idea:
/displayturns Workflow history into a second-screen experiencejust boothlaunches the local stack and kiosk windows- the Workflow timeout keeps abandoned games from lingering forever
- the tests cover the interaction paths real players broke first
The thing I would take from this is not “every demo needs a holographic fan.”
Please do not make that your takeaway. My apartment cannot handle the logistics.
It is simpler than that: model the durable part first.
Once the durable part is real, you can be surprisingly playful with everything around it. You can build a polished browser UI. You can run a leaderboard. You can make a giant keyboard the input device. You can put the Workflow timeline on a circular fan display. You can patch the experience live for four days at one of the biggest AI engineering conferences in the world.
And if someone walks away mid-game, the Workflow can handle that too.