OVERKILL

Inspiration

"What's for lunch?" "Anything" "How about chicken rice downstairs?" "Nah not today" "Okay how about ramen" "Hmm dont want" "THEN WHAT DO YOU WANT???"

Choices are hard, even for the basic things in life like food. OVERKILL helps with your decision paralysis by converting your possible choices into gladiator agents that fight it out in the arena until one remains.

What it does

OVERKILL converts choices into agents, and the choice agents are paired into conversational duels.

In a duel, choice agents get to come up with a short response which is judged by judge agents that are meant to represent different personalities and point of views. This continues until one agent wins the pairing.

The winner then damages the loser, RPG-style, until one wins. The loser takes some damage and will be eliminated once they run out of HP.

The pairings continues until one remains, and that choice is presented for the user as the best one.

How we built it

In terms of architecture, we decided to use a TypeScript frontend with a Python backend, which were separated for easier testing and parallel development.

Afterwards, we designed prompts to facilitate the creation of the judge and choice agents. This included standardising response sizes, setting personalities, and engaging with the opponent's responses.

We used a battle engine to orchestrate how the duels went. This engine helped to progress the simulation by deciding when to pair the choices, when to request for responses, when to send the responses to judges, and how to reduce the HP of agents when they lost.

Challenges we ran into / Accomplishments that we're proud of

LLM latency was a big issue for us due to their slow responses especially given substantial context. We optimised on the model's speed, benchmarking until we found the quickest responding model (Claude Haiku 4.5). We also optimised on our prompts to reduce context as much as possible, by requesting for only short, 20-word responses from choice agents and reducing the initial personality description size of each judge agent.

Additionally, we parallelised rounds by allowing for multiple pairings to occur at the same time when 4 or more choice agents exist. To make things even quicker, we also used a websocket between the frontend and backend to facilitate the heavy data exchange between them.