Rayhan Patel

MS in Applied Machine Learning, University of Maryland. For the Startup Shell reviewers: the short version first, then what I'm working on with our two-minute YC pitch, then each build with what went wrong.

What I'm working on · updated Sep 9, 2026

HVAC Copilot, continued. Two minutes: our live pitch at Y Combinator, April 2026.

What exists: the assistant runs on a laptop with no internet, the phone or glasses connect to it, it is hands free, it has a small library of about twenty equipment manuals, and it picked the right action in seven of eight test cases. The glasses version is still too slow, about twenty seconds an answer. Used by us at the hackathon; no technician has used it on a real job yet. It has sat since April while I was at my internship; I am picking it back up now.

What we learned before building it: technicians already ask Gemini on their phones; the help disappears exactly where they need it, because there is no signal underground; and the manufacturers' service documentation is locked, so the buyer is the service company, not the technician.

What's next: one technician using the phone version on real jobs for a week; two or three HVAC service companies asked about a small pilot; the documentation question settled, a license for a pilot or a knowledge base built from the company's own manuals; and latency cut, which mostly waits on faster hardware support for the on-device model.

What's hard: the documentation lock, the latency on glasses, and getting a company to let a prototype onto a job site. Who I need: someone who can sell to field-service companies or already knows people in HVAC, and a product person. I will drive this one and build the core, with whoever from the hackathon team wants to continue, and I want partners who own product and the customer side as equals. What the technicians tell us decides what we build next.

What I built, and what went wrong

HVAC Copilot — Y Combinator × Google DeepMind × Cactus hackathon, San Francisco, April 2026

team of four · top 10 of 200+ builders · runs on our own hardware, nothing in the cloud

Before the event we talked to HVAC technicians. They already asked Gemini on their phones what to do next, but in basements and underground there is no signal, exactly where they need it, and their hands are busy. The manufacturers' service documentation is locked up, so this could only ever be sold to companies, not to technicians. So we built a voice and camera assistant that runs on a laptop with no internet, with the phone or glasses connecting to it, hands free; I built the assistant runtime and the tool calling. What went wrong: the AR glasses path took about twenty seconds per answer, too slow for someone on a ladder, and we said so in the write-up instead of hiding it. What I learned: a demo that needs wifi is worthless to the person it's for.

EvoRank — research, RecSys 2026 workshop paper

co-authored with Shabaz Patel · GenAI for E-commerce workshop · presenting Sep 28, 2026, Minneapolis

An LLM-guided loop that evolves whole search-ranking pipelines for e-commerce, tested on a public Expedia dataset with three competing goals. What went wrong: the first campaign looked like it worked and was not; its gains existed only on the small data it used to pick winners, and re-scored on sixty thousand held-out queries they were noise. We built a gate that predicts, before spending anything on the model, whether a search space has enough real signal to be worth it. The second campaign beat a tuned baseline on every objective, held up on held-out data, and landed in the top six percent of the original competition. What I learned: do not believe a loop that grades its own homework.

FunctionGemma router — Google DeepMind × Cactus Global Hackathon at UMD, February 2026

solo · 2nd place · hosted by AI Tinkerers at UMD

Decides whether a small on-device model or the cloud should handle a request. What went wrong: the small model reported high confidence on every answer, right or wrong, so "fall back to the cloud when unsure" was impossible; the routing had to happen before the model ran. What I learned: that lesson went straight into PathGuard the same weekend.

PathGuard — built at Startup Shell, Ironsite hackathon, February 2026

team of three, I led · needs no internet

A trip hazard alarm for construction workers. What went wrong: the footage had no labels, so the model we planned to train was impossible; then the first versions flagged everything in the frame, a cable on the wall, a bucket ten feet away, and a worker would switch that off in a minute. We went zero-shot and looked only at the walking path in front of the person. Six pivots in two days. What I learned: find the one constraint that decides everything, here the network, and build around removing it.

Auto-Eval3D — BigThink AI × World Labs hackathon, UMD, March 2026

solo · Best Scientific & Engineering Application

Checks whether AI-generated 3D worlds are geometrically consistent by walking a camera through them and grading what it sees. What went wrong: after the win I kept auditing the results and found the demo's worst score came from my camera rig photographing the scene from outside the room instead of inside it; the evaluator had been grading my bug, not the world. Rewrote the capture two days later. What I learned: winning does not make the number right.

MedBill — Anthropic hackathon at UMD, April 2026

solo · extended in June · personal information removed on your own laptop before anything touches the cloud

The tool I wish my family had had in 2020. Upload a hospital bill; it finds overcharges, drafts the dispute letter, and checks charity-care eligibility from a pay stub, showing the exact rule that applied. What went wrong: the model would confidently say a billing law was violated when it was not, so I moved every decision that matters out of the model into plain rules it cannot override. What I learned: nobody will upload a medical bill unless they are sure it never leaves the machine. Privacy was the product. Used by no one but me so far.

3E — AI engineering intern, summer 2026

Bethesda, MD · AI platform team · asked to continue part-time this fall

The company was deciding how its AI agents should remember things. I benchmarked three open-source memory systems on two public benchmarks under a locked protocol, then noticed the judge model grading every answer had never itself been checked, so I calibrated it against blinded human graders. The surprise: humans accepted vague answers more often than the judge did, and the scoring rubric, not the judge model, was what mattered. Wrote the architecture proposal for the team's memory layer and helped build the service on AWS. What I learned: if the protocol is not locked, the numbers are opinions.

AI Resume Chatbot — live at chat.rayhanpatel.com

solo · in production, five automatic judges score every answer

A chatbot recruiters use to ask questions about me. What went wrong: I once pushed a change that silently hung every request, no errors, no logs; I built ten temporary diagnostic endpoints to search the system in production and found a one-line locking bug. What I learned: keeping something alive is a different job from shipping it.

Euler AI — Chennai, 2023 to 2025

the company my brother and I set up to build things

An e-commerce shopping agent and a tool that turns medical records into billing codes; finalists at the Pear VC + OpenAI hackathon in San Francisco with the shopping agent; memory features contributed to the open-source agent libraries Mem0 and EmbedChain. What we never did: sell anything. It was research and development with no customer. What I learned: building is not the same as making something people pay for, and I had the order backwards. It is why I now want the users first.

One I did not finish

A research project on self-improving search, paused in March after two of five phases because I was spread across too many things. Still paused. I'd rather say that than hide it.

How I check whether things work

I spent this summer testing AI systems for a living, and the main lesson was that most impressive numbers don't survive a fair test. I now run my own projects through the same kind of check before I believe them. The RecSys paper above is the same argument about search: don't trust the loop until you re-score on data it never saw.

Building with people

Everything I build alone ends up engineer heavy. I'm looking for a design or product person to build with as partners, not helpers, on something I start and keep moving: I bring the engineering, they own their side, and what users say settles arguments. rayhanbasheerpatel@gmail.com · GitHub