THE LAST BLINK: SECOND SETTLEMENT — Building an AI-driven investigation across timelines

Yash Bansal — Wed, 04 Nov 2026 04:11:15 +0000

This is a submission for the MLH x DEV Writing Challenge

THE LAST BLINK: SECOND SETTLEMENT — Building an AI-driven investigation across timelines

What if the AI helping you solve a mystery was also the reason you couldn't trust the evidence?

What if a failed timeline wasn't a failure, but another piece of evidence?

That was the idea behind THE LAST BLINK: SECOND SETTLEMENT, the project I built with Yash Gupta at HackCBS 9.0.

We wanted to go beyond building another chatbot with a UI around it. We wanted to create a playable investigative thriller where AI, memory, persistent state, and player decisions actually affect how the investigation unfolds.

And building it taught me a lot about both engineering ambitious ideas and navigating hackathons.

What I Built

THE LAST BLINK: SECOND SETTLEMENT is a story-driven 2D investigative thriller set in Veyra, a city hiding the truth behind an incident at Relay 7.

You play as Aster, investigating conflicting accounts, collecting evidence, questioning NPCs, and trying to understand what really happened. But there is a catch: the investigation can be manipulated, and the truth isn't always obvious from a single timeline.

We built several connected systems around that idea:

MORROW — The adversarial intelligence: MORROW can interfere with parts of the investigation, including testimony and perception. Its interventions are traced so the player can investigate whether information was manipulated.
ECHO — The investigation auditor: ECHO lets players examine evidence provenance, compare timelines, trace contradictions, and test their own theories. It doesn't simply announce which account is true.
BLINK — Branching timelines: Players can fork a timeline at a critical point while retaining earlier branches. Failed attempts can become useful evidence in later investigations.
The Case Board: Players collect records, connect clues, form hypotheses, and challenge explanations instead of following only one predetermined sequence.
Interactive puzzles: Frequency tuning, timeline reconstruction, contradiction questioning, and relay disarming connect the investigation to actual gameplay.

The central design principle was simple: the player should have to investigate the truth, not just ask an AI to reveal it.

The technology behind it

Our stack includes React, Phaser, TypeScript, and Vite on the frontend, with a deterministic game engine and a backend responsible for persistence and AI integration.

The most important engineering decision was separating three things that are easy to mix up in AI applications:

What the game has recorded as a canonical fact.
What an AI agent remembers or believes.
What the player can prove using evidence.

That separation is what makes an unreliable witness interesting instead of letting an AI response arbitrarily rewrite the story.

Project: THE LAST BLINK

Demo video: [Add your demo video link here]

Source code: https://github.com/demonstrikkk/last_blink
The best demonstration is a complete investigation loop: collect evidence, connect clues on the Case Board, encounter a contradiction, use BLINK to create another timeline, and use ECHO to compare what changed.

I'd rather show one working investigation end to end than pretend every planned feature is equally polished.

Partner Technologies

This was one of the most interesting parts of the project for me because we weren't integrating technologies just to put their names on a slide. Each one had a specific responsibility.

1. YugabyteDB — Persistent game state across timelines

Why use YugabyteDB when PostgreSQL and many other relational databases already exist?

Because our data isn't just a collection of user profiles or chat messages. We need to preserve sessions, ordered investigation events, snapshots, branch history, and the relationship between evidence and decisions.

We used YSQL, YugabyteDB's PostgreSQL-compatible SQL interface, for our relational persistence layer.

The intended architecture separates:

Game sessions and their current version.
Ordered events representing actions in the investigation.
Snapshots used to retain branch state.
An outbox for pending Meko memory-delivery work.
Database migrations and indexes.

The game engine remains responsible for deterministic rules, while YugabyteDB persists the durable record.

We also tested the actual database integration rather than stopping at configuration: our reported smoke test connected to a real cluster, created a session, committed an event, and read back persisted session, event, and snapshot records.

For this project, the interesting part of YugabyteDB isn't simply that it stores data. It gives us a PostgreSQL-compatible starting point and a path toward distributed SQL as the application evolves. We still need workload and failure testing before making claims about production-scale performance or high availability.

2. Meko — Contextual memory for AI-driven interactions

One problem with multi-agent AI systems is that every interaction can start to feel disconnected. An NPC forgets relevant information, an agent loses useful context, or the same information has to be repeatedly included in prompts.

We integrated Meko as a contextual memory layer.

The idea is that AI-driven interactions can retrieve relevant memories rather than relying only on the current prompt. We use the game engine and YugabyteDB as the authority for canonical facts, while Meko supplies supporting context.

Our integration includes live memory write-and-recall testing and an outbox-based path for delivering memory updates.

One limitation we discovered is that a working memory integration doesn't automatically mean a populated knowledge base. Our latest tests showed that the Meko knowledge-base search returned no results until documents are seeded. In that case, ECHO labels its local fallback rather than pretending the result came from Meko.

That distinction matters: a system should be honest about where its information came from.

3. Gemini and Groq — AI through a centralized gateway

We integrated Gemini and Groq behind a Model Gateway instead of scattering provider-specific calls throughout the game.

The gateway centralizes inference requests, while application-side validation helps keep AI outputs within the formats and rules the game expects.

The models can help power interactions, but they don't get unrestricted authority over the game's state. An AI-generated statement isn't automatically a verified fact, and an agent's suggestion isn't automatically an approved game action.

This also gives us a cleaner place to handle provider failures, fallbacks, and future changes to model selection.

4. MORROW and ECHO — Making AI behavior investigable

These aren't external services; they're core parts of our game design.

MORROW introduces controlled interference. ECHO helps the player inspect the resulting evidence and trace its provenance.

Together, they explore a question I find interesting: what happens when AI can influence the information a person receives, but the system preserves enough history for that influence to be investigated?

Instead of treating AI as an unquestionable narrator, we make its effects part of the mystery.

Hackathon Experience

Building this at HackCBS 9.0 with Yash was a challenging experience. We were trying to connect a playable game, multiple AI components, persistent database state, contextual memory, and branching investigation logic under hackathon time constraints.

One of my biggest takeaways was that having a technically ambitious idea is only part of the work. You also need to decide what to demonstrate, make the important interactions understandable, and communicate what is genuinely working versus what still needs improvement.

We didn't make the Top 10. Of course, we would have loved to, especially after putting so much thought into the architecture and the investigation mechanics. But I also came away with questions about the event itself.

A difficult question about hackathon rules and judging

One thing I struggled with was understanding how consistently the build-from-scratch expectations were being applied.

I saw a drone project that, from what I understood, had been started roughly two months before the event, and it placed second. I couldn't independently verify its full development history or what the organizers had approved, so I don't want to present that as proof of a rule violation. Still, it left me wondering how much pre-existing work was permitted and how that was assessed across teams.

I also found myself wondering how the Top 10 decisions were reached. Some selections left me uncertain about the relative weight given to originality, implementation, technical depth, and presentation. At moments, I even questioned whether some outcomes might have been influenced by factors beyond the projects themselves. I don't have evidence to claim that the results were fixed, and I wouldn't want to make that accusation without it.

What I would genuinely like is more transparency about the criteria, the treatment of pre-existing work, and the feedback behind the final selection.

If our project fell short in execution, clarity, technical depth, or demo quality, I'd rather know that specifically than assume the result tells the whole story.

I believe hackathons are most valuable when builders understand both what they did well and what they could have done better. Clear criteria and useful feedback help everyone improve, whether they place first or don't make the shortlist.

What I would do differently next time

Looking back, I would focus on three things:

A tighter vertical slice: Demonstrate one complete investigation with a meaningful contradiction across timelines rather than spreading attention across too many features.
A clearer technical proof: Show the real YugabyteDB persistence round-trip, the Meko memory retrieval flow, and how AI outputs are validated.
More time for presentation and testing: A complex architecture only matters to a judge if they can quickly understand why it matters and see it working.

These are improvements I can act on regardless of the judging outcome.

What I Learned

The biggest lesson was that building more features isn't the same as making a stronger project.

A system can have a database, multiple models, contextual memory, branching timelines, and an adversarial agent, but the audience still needs to experience one clear reason those pieces belong together.

I also learned to be more precise about technical claims. A successful connection test is evidence of integration, not proof of scalability. A memory write-and-recall test isn't proof of a fully populated knowledge base. An AI fallback is useful, but it should be visible rather than disguised.

And perhaps most importantly, I learned that a hackathon result shouldn't stop me from asking difficult questions about my own work—or about the process through which it was evaluated.

What's Next?

I want to keep improving THE LAST BLINK: SECOND SETTLEMENT, especially the cross-timeline investigation loop, the quality of NPC interactions, and the integration between persistent game history and contextual AI memory.

I also want to get feedback from people who care about game design, distributed systems, AI reliability, and fair hackathon evaluation.

If you have experience with YugabyteDB, Meko, multi-agent systems, investigative game mechanics, or hackathon judging, I'd genuinely appreciate your perspective.

What would you have wanted to see in our demo to make this project stand out?

And if you were at HackCBS 9.0, how did you interpret the build-from-scratch expectations and the judging process?

I'm sharing this because the project is still worth building, and because the most useful thing I can take from a difficult result is a clearer understanding of what to improve next.

mlhacks #devchallenge #HackCBS9 #YugabyteDB #Meko #Gemini #Groq #AI #GameDevelopment #DistributedSystems

DEV Community: Yash Bansal

THE LAST BLINK: SECOND SETTLEMENT — Building an AI-driven investigation across timelines

THE LAST BLINK: SECOND SETTLEMENT — Building an AI-driven investigation across timelines

What I Built

The technology behind it

Partner Technologies

1. YugabyteDB — Persistent game state across timelines

2. Meko — Contextual memory for AI-driven interactions

3. Gemini and Groq — AI through a centralized gateway

4. MORROW and ECHO — Making AI behavior investigable

Hackathon Experience

A difficult question about hackathon rules and judging

What I would do differently next time

What I Learned

What's Next?

mlhacks #devchallenge #HackCBS9 #YugabyteDB #Meko #Gemini #Groq #AI #GameDevelopment #DistributedSystems