Beta Testers

Climbing routes are meant for the average build, what is the meaning of average? A 5'0 climber can't do the same holds and routes as a climber who is 6'2. As a fellow climber, when first starting out on new routes, it was hard asking for help on how to tackle a certain climb because everyone is different, so what works for someone may not work for anyone else. So we set out to find a way for someone to find their personalized route.

Upload a photo of a climbing wall, pick a route color, and enter your height, wingspan and climbing level. A team of AI agents finds the holds, plans the best route for your reach, reviews it for risky moves, rates its difficulty, and writes move-by-move instructions. Every move is checked against your real reach, so the same wall gives different routes to different climbers. You can watch the agents “talk” to each other live as they work.

How we built it

Beta Testers turns a photo of a bouldering wall into a personalized route. A vision agent detects the holds (position, type, color) and estimates scale, or the user can add the scale if they know the height of the wall. A planner agent models the wall as a graph and runs Dijkstra to find the best route for the climber’s body, using reach, move count and hold difficulty as costs. A critic agent reviews the route like a climbing coach would and sends back constraints if a move looks risky. A coach agent then writes move-by-move steps on how to complete the climb. An orchestrator coordinates everything, and the agents talk to each other over HTTP using shared pydantic schemas (FastAPI backend). Python does all the geometry, and Claude handles judgment and language through structured tool use.

Challenges we ran into

Keeping the LLM honest. We never let Claude calculate distances. The planner owns the math and the agents only use its numbers.
Making agents disagree usefully. The planner can push back with numeric evidence when the critic’s constraints make a route much harder.
Staying demo-proof. Every agent has a fallback (deterministic planner, rule-based critic and coach), so a missing API key or network failure never breaks the flow. Real world distances from photo. We struggled to estimate distances between holds or the overall height of the wall, so we adjusted, allowing our users to input in an estimated height so our model can use ipp (inches per pixel) to give the user a more accurate idea of what they need to accomplish to complete the climb

Accomplishments that we're proud of

A real multi-agent system where each agent does what it’s best at: math for the planner, judgment for the critic, language and memory for the coach, and allowing the agents to talk to each other through fastapi
A coach that decides for itself which tools to call, and tailors its beta to a climber’s past results (like repeated slips off slopers) without inventing history.
A pipeline that still produces a route when pieces of it fail, so we have some kind of fallback plan in case api keys get lost of fail, or if our agent doesn't do its job correctly (ie claude doesn't work for some reason)

What we learned

We learned how to split code between code and AI. In the beginning we thought AI could handle the math, but was unreliable with numbers. Once we gave the all the geometry to plain python to compute and kept claude to make the judgement and explanation, the results became more accurate and easier to understand. We learned a lot about how to make a multi service system as a team under pressure.

What's next for Beta Testers

Our next steps would be we want to correct for photos taken at an angle, so steep and overhanging walls are measured accurately. We also want to detect footholds and wall angle, since real moves depend on more than hand-to-hand distance. Classifying hold types automatically would remove the manual tagging step. We plan to connect the “Sent it / Fell” feedback so the Coach learns from every attempt. Finally, we want to test our difficulty estimates against real gym grades with climbers of different heights.