Agora Garden

Inspiration

"I want to be a Software Engineer" is easy to say and surprisingly hard to act on. Three problems kept coming up when we talked to classmates and looked at the data:

Job requirements are inconsistent. Similar roles list very different skills, so it's hard to know what actually matters.
Career centers can't scale. The median U.S. college career center runs on about 7 full-time staff (NACE 2024–2025), with hours limited to office time, and advice tends to be generic (resume tips, interview basics) rather than role-specific.
Companies have the same gap. Employers invest heavily in learning platforms, yet only 29% of employees say their L&D function helps them learn effectively, and about 90% of HR leaders say career paths are unclear (Gartner).

Everyone can find a list of skills. Almost no one gets a plan for what to learn, in what order, and by when, based on where they are today. That's what we set out to build.

What it does

Agora Garden turns a vague career goal into a personalized, time-based learning roadmap.

The user uploads a resume (PDF, DOCX, or TXT) and enters a target position (required). Industry and company are optional.
The system searches the web for current job descriptions for that role and identifies the top 5 skills employers ask for.
It compares those skills against the user's background and rates their current proficiency in each.
It generates a roadmap covering three areas: university coursework, external resources (Coursera, certifications, competitions), and side projects.

The output is shown in two ways:

Skills analysis: for each of the top 5 skills, how many analyzed job postings mention it, and the user's estimated proficiency.
Timeline and table views: a Gantt-style timeline plus a Learning Details table with four columns: category, skill, importance, and start/end dates. It also includes a written summary explaining why each course, resource, and project was recommended.

The same engine works for employees who want to plan an upskilling path toward a new role, which opens a B2B use case alongside universities.

How we built it

Model: IFM's K2 Horizon 375B-A23B performs skill extraction, proficiency assessment, and roadmap generation.
Backend (Python, FastAPI): parses the resume, searches for real job postings, runs the analysis pipeline, and stores results in SQLite (skills, job sources, and roadmap items).
Frontend: a web app that consumes the backend's structured JSON and renders the skills view, timeline, and table.

A design choice we care about: the model does not make up the statistics. It only proposes candidate skills and their spelling variants. Our code then counts, for each posting, whether the skill appears, so the importance of a skill is computed from data:

$$ \text{importance}(s) = \frac{n_s}{N} $$

where $n_s$ is the number of analyzed postings mentioning skill $s$ and $N$ is the total number of postings analyzed. The user's proficiency, in contrast, is a model judgment grounded in evidence from the resume.

The roadmap is also validated after generation: dates are clamped to the planning window, and prerequisites are enforced in code. If Machine Learning depends on Linear Algebra, the plan can't schedule it before Linear Algebra ends.

Challenges we ran into

Getting real job descriptions. Many job boards sit behind login walls or block scraping, so we fall back to search snippets and flag low-confidence results with a warning instead of overstating our sample size.
Hallucinated courses and links. Language models like to invent course names and URLs. We constrained the prompt to use only sources from search results or well-known official sites, and we leave the link empty when unsure.
Reliable structured output from a reasoning model. The model emits its reasoning before the answer, so we strip that trace, extract the JSON, retry on malformed output, and normalize every field before it reaches the frontend.
Scheduling with dependencies. Skills aren't independent, and a plan that teaches a topic before its prerequisite is useless. This pushed us to add a deterministic dependency check rather than trusting the model's timing.
Latency. A large reasoning model plus web research takes a while, so the backend runs jobs asynchronously and reports progress to the UI.
Splitting backend and frontend work meant agreeing early on a clean JSON contract; we iterated on it several times as the product evolved.

What we learned

Splitting the work between an LLM (judgment, language) and plain code (counting, validation, scheduling) produced far more trustworthy results than asking the model to do everything.
Being transparent about data limits (how many postings we actually analyzed) makes the product more credible, not less.
The valuable part isn't listing skills. It's sequencing them into a plan a person can follow.

What's next

Integrate real university course catalogs so recommendations map to actual classes and prerequisites.
Expand the job-posting corpus for more statistically robust skill rankings.
Add an HR dashboard for companies to see team-wide skill gaps and align upskilling with internal career paths.
Deeper progress tracking, so the roadmap updates as users complete items or their goals change.