Inspiration

Can an AI escape a room—not just explain how?

We built K2 Escape to explore how K2 handles observation, memory, reasoning, and recovery under time pressure. Instead of evaluating isolated answers, we put the model inside a playable environment where its decisions have consequences.

What it does

K2 Escape is a browser-based escape game controlled by a multi-agent team. Within three minutes, the AI must remember flashing lights, recall symbol sequences, choose corridors, collect a key, solve a calculus puzzle, and reach the exit.

Wrong corridors send the player back. An incorrect calculus answer releases a monster. Thinking time counts toward the deadline.

The interface shows agent reports, observed objects, planned routes, and execution progress so viewers can follow what the system sees, decides, and does.

How we built it

The frontend uses JavaScript, Phaser, and Vite for rendering, game state, collision detection, and pathfinding. A Python FastAPI backend connects the game to K2 and streams results through Server-Sent Events.

Our team uses four roles powered by the same K2 model:

Explorer: interprets visible objects and puzzle evidence.
Survival: assesses immediate danger.
Navigator: proposes the next action or puzzle answer.
Supervisor: checks the reports and selects the final decision.

The three specialists analyze observations concurrently before the Supervisor responds. The frontend then executes the chosen action.

To reduce latency, known navigation steps use an explicit rule-based router. Puzzle answers and corridor choices use the multi-agent workflow. Engine actions are labelled separately from model decisions.

K2 receives structured observations—not screenshots or hidden answer keys. Failed corridor choices and recent action failures are included in subsequent requests so it can adjust.

Challenges we faced

Latency was our biggest challenge. Calling every agent sequentially for every movement caused the character to spend too much time waiting.

We shortened prompts, ran specialists concurrently, and removed unnecessary model calls for routine navigation. We also handled interrupted streams, invalid actions, and retries while keeping the game state consistent.

Another challenge was making the workflow understandable. We added visible routes, observation overlays, agent progress, and clear labels separating model reasoning from engine execution.

Accomplishments we're proud of

In one end-to-end test using real K2 calls, the system escaped in approximately 123 seconds, including model waiting time. It chose a wrong corridor, used that failure to select another route, and continued to the exit.

This is an observed successful run, not a claim that every randomized session succeeds.

What we learned

A strong model still needs a well-designed execution loop. Observation quality, latency, action validation, and useful failure feedback all affect performance.

More agent calls do not automatically produce a better system. The key is using model reasoning where it matters and making each decision actionable.

What's next

We want to evaluate success rates across randomized runs, compare single-agent and multi-agent approaches, and measure the tradeoff between reasoning quality and latency.

Future work includes richer environments and persistent memory across attempts.