Central Asia AI Association

The landing page.
An answer with its sources. It's a saved answer, labeled on screen, and the sources are checked through Triggerware.
Triggerware running: Alex flips to left, the trigger fires and the handoff report prints.
Decision Graph, built only from the answer's sources.
Memory Map: the repo's public history since 2011, with the threads behind this answer in red.

Inspiration

Every engineer has asked "why is this built this way?" and heard "no idea, the person who wrote it left." New hires end up asking supervisors who have only been there a few months. Code search shows what the code does, but the reason behind it is buried in old pull requests and threads, or it left with the person who knew it.

What it does

Ask a question and get the reason, who wrote it, where it was discussed and who owns it now, with links to the proof.

Inside the Brain shows how an answer was reached: a replay of the run, a decision graph built only from the answer's sources, and a memory map of the repo's public history, 278 threads and 242 people since 2011, with the threads behind the answer lit up.

When someone leaves, a Triggerware trigger prints a handoff report: the services they owned, the open issues on those services and a suggested new owner from the roster.

How we built it

We work in four parts: agent, data, frontend and pitch. We pull a real open-source repo, pallets/itsdangerous, through the GitHub API and index it for retrieval using sentence-transformers, ChromaDB and Onyx. A Python and FastAPI agent takes each question, retrieves the relevant pieces and uses a model through OpenRouter to write an answer with its sources.

The frontend is built with Next.js, TypeScript, Tailwind and GSAP, using Claude Code. Each source becomes a card that links to the original pull request or issue. If the agent fails during a demo, a saved answer appears, clearly labeled as saved.

We use Triggerware in two places. It checks each source in an answer against public GitHub, and it runs the handoff trigger: the team roster and the open issues are Triggerware tables, and a trigger watches for any status changing to left.

Challenges we ran into

We started with a made-up company, then switched to a real repo mid-event so that every answer could be checked.
The real reason often spans years. Why itsdangerous still defaults to SHA-1 runs through PR #80, issue #111 and PR #113.
Answers take 5 to 10 seconds, so the wait had to feel alive and be honest about the time.
Search results can repeat the same document, so the frontend shows one card per link.
We didn't get the live agent connected to the frontend in time, so the demo video shows saved answers built from the real history, labeled on screen.
Triggerware's Python runtime crashed on Windows, so we patched it locally to get it running.

Accomplishments that we're proud of

Every answer in the demo traces back to a pull request or issue you can open.
Nothing in the replay is invented. A step only appears if it ran.
One status change on the roster produces a full handoff report within seconds.

What we learned

The most valuable knowledge in a codebase isn't in the code. One pull request called a major change "mostly a change for aesthetics," and it later led to a release being pulled. Code search would never surface that. We also learned that sources matter as much as the answer: people trust an answer they can click through and check.