Inspiration
A lot of student researchers, especially at HBCUs and small universities, have real research questions and a laptop, but no lab server and nobody to check their code. A 2025 study of HBCU researchers in Frontiers in Education named the problem directly: under-resourced research infrastructure.
At the same time, AI can now write research code in seconds. That's exciting, but it raises a hard question: can you trust it, and can anyone run it again? The research says that's a real gap. In a large study of Jupyter notebooks on GitHub (Pimentel et al., 2019), only 24% ran without errors, and only 4% reproduced the same results. In another study (Kabir et al., CHI 2024), 52% of ChatGPT's answers to programming questions had incorrect information.
We wanted AI help for student researchers without giving up control or trust.
What it does
Kairo turns a research question into an experiment you can review, run safely, and rerun.
- Question: you type a research question in plain words.
- Plan: Kairo proposes a hypothesis, method, assumptions, limitations, parameters, and the actual code. Plans can come from an open-weight model or be written by hand.
- Review: nothing runs until a person reads the plan and code. Every edit is saved as a new version.
- Run: only a person can press Run. The code runs in a locked Docker container with no internet, a read-only disk, and limits on memory, CPU, processes, and time.
- Evidence: Kairo shows the computed chart, findings, and limitations side by side. Any AI interpretation is labeled separately.
- Reproduce: every run leaves an evidence bundle (code, inputs, results, report, a SHA-256 fingerprint for every file, and
REPRODUCE.md) so anyone can rerun it.
Our demo follows Maya, a composite public health student (not a real person), who asks how much a campus flu shot drive could shrink an outbreak. Kairo runs an SIR outbreak model on a model campus of 5,000 students at four vaccination levels. The model's herd immunity threshold is $1 - \frac{1}{R_0}$, which is 60% for $R_0 = 2.5$. All numbers are illustrative model inputs, not real health data.
How we built it
- Frontend: React 19 and Vite
- Backend: a Go API that saves experiments, versions plans, validates them, and queues runs
- Database: PostgreSQL on Neon
- Worker: a Docker container with Python, NumPy, and SciPy, locked down with no network, a read-only file system, an unprivileged user, and resource limits
- AI planning: connects to Ollama or any OpenAI-compatible server for open-weight models
- Voice: an optional "Talk to Kairo" companion built on ElevenLabs. It can suggest a research question, but it never saves or runs anything on its own.
Challenges we ran into
- Open-weight AI planning. We connected Gemma 4, but its responses were slow, and its plans didn't pass our plan validation yet. So today's demo uses a hand-written plan, and AI planning is still in progress.
- Setup across machines. Getting the shared database config, Docker, and the backend running on different laptops took real time. Small things like
python3vs.pythonon Windows tripped up our tests. - Growing the team mid-day. We went from two people to four during the hackathon and had to split the work fast without stepping on each other.
- Being honest in the pitch. It's tempting to overclaim with AI. We worked to label what's real (our runs) and what isn't (a made-up persona and model inputs).
Accomplishments that we're proud of
- A full experiment ran end to end on our Neon database in the isolated Docker worker, finished in about 19 seconds, and produced 13 evidence files with SHA-256 fingerprints.
- All 67 frontend tests pass.
- A clear safety model: the AI proposes, a person approves, the container runs.
- A fair comparison with other tools. Claude Research is great for reading sources, Codex is great for writing and running code, and Kairo does the reviewed, reproducible experiment step in between.
What we learned
- Reproducibility is the hard part, not code generation. Getting code to run once is easy. Getting it to run again, for someone else, is where tools fall short.
- The review step matters most. Showing the plan and code before anything runs changes how much you can trust the result.
- Execution checks are not scientific validation. Researchers still need their own checks, like known answers, sensitivity tests, and a second person rerunning the work.
What's next for Kairo
- Get open-weight AI planning fully working, so plans come from Gemma 4 and still go through human review.
- Support more languages beyond Python. Philip has already started adding these.
- Test Kairo with real student researchers and their mentors, and learn what they need.
Built With
- docker
- gemma
- go
- javascript
- neon
- numpy
- ollama
- postgresql
- python
- react
- scipy
- vite
Log in or sign up for Devpost to join the conversation.