What Happened When My Research Prototype Couldn't Survive Outside My Laptop

In my first year of graduate research, I built an RL-based tutoring agent that achieved impressive results in simulation. The agent could adapt its teaching strategy based on student performance — at least in theory. In practice, the code was a monolithic Jupyter notebook with hardcoded paths, no error handling, and a single-threaded training loop that took 12 hours.

When my advisor asked if we could deploy this for a pilot study, I had to say no. The model worked, but the system around it was not ready. That moment stayed with me.

The Gap I Hadn't Seen

Looking back, the problem was not the model itself — it was that I had never thought beyond the notebook. There was no way to reproduce my results outside my machine, no way to handle multiple users, no way to log what went wrong. I had focused entirely on the research question and assumed the rest would take care of itself.

It did not.

Trying to Bridge It

Building Maestro later forced me to confront those same gaps. The RL policy that worked in a Python simulation had to be rethought for a mobile app. The LLM agent needed queuing, timeouts, error recovery — things I had never considered during research. Engineering constraints pushed me to revisit assumptions I had made too quickly.

I am still learning how to navigate this. Each project teaches me a little more about the distance between an idea and something that works outside my laptop.

Something I Keep Coming Back To

That initial failure to deploy taught me something I don't think I could have learned in a course. It was not a failure of the algorithm — it was a failure of the system around it. I keep revisiting that lesson every time I start something new.