-
-
Chat (synthetic demo, UI in Chinese): jobs under the user's constraints, hard requirements checked
-
Follow-up card: detected changes ranked by urgency, and a situation report
-
Competitiveness: hard requirements, skill coverage and gaps a recruiter will ask about
-
Applications funnel with rejection feedback that later gap analysis uses
-
Polaris: a job-search agent where every claim opens to its source
Inspiration
Searching for an LLM or Agent internship in China means reading job posts on career sites and interview write-ups on forums, then comparing each one with constraints that rarely match: how many days a week you can come in, how many months you can stay, whether a paper is required. General chat models answer these questions confidently and often invent the job, the requirement or the interview question. I built Polaris for my own search, with one rule: every claim must open to the text it came from.
What it does
- Finds jobs under your constraints and marks each hard conflict (education, papers, attendance, length). A constraint the posting does not state is shown as "to confirm", never as a match.
- Pulls real interview questions from real posts, with source and date. If you ask for real questions and none were searched, orchestration sends the agent back to search before it may answer. Any id the answer cites that no tool returned is marked unverified.
- Follow-up cards watch one goal over weeks: a focus job removed or changed, new jobs in scope, new interview posts, outcomes of people like you. Changes are ranked urgent / digest / quiet, and a daily situation report is written from facts computed by rules first.
- An HR-view review: which hard requirements block you, which common skills your card lacks, and what an interviewer will ask about; compared with peers' public self-descriptions, saying so when the sample is small.
- An application funnel and follow-up drafts that are never sent automatically; rejection reasons feed later gap analysis.
- Bi-temporal memory of your constraints and experience that you can read, correct and delete.
How it fits Personal AI
- Persistent: a daemon collects and checks follow-up cards on a schedule; long tasks survive page reloads through a persisted task queue.
- Private and user-owned: collected text, chats and memory live in the user's own PostgreSQL; logged-in platforms are read only on the user's machine, with their own account, at a low rate.
- Durable memory: bi-temporal facts (true when / learned when); corrections are confirmed before they overwrite.
- Reusable skills: 18 typed tools; the read-only ones are also exposed over MCP for other agents.
How we built it
Python 3.12, FastAPI and LangGraph 1.2 / LangChain 1.4, with middleware for approval of side-effecting tools, call limits, retries and evidence gates. Retrieval runs inside PostgreSQL 17: pgvector plus ParadeDB pg_search (BM25 with Chinese tokenization), with an optional Neo4j graph, fused by weighted RRF and reranked. Next.js 16 and React 19 for the web app. Every model call is recorded with tokens, latency and cost. CI runs ruff, 794 backend tests against a real Postgres, type checks, lint, unit tests and a production build on every pull request.
Challenges we ran into
Running the whole task for real exposed problems no offline test caught:
- Post-filtering lost almost all recall; filtering first took candidates from 1 to 32.
- A 6,000-character tool budget made the model page through results; together with the next two fixes, the full task went from 265 s to 77 s.
- A local network tunnel stalled model requests; a narrow direct route took job search from 103 s to 2 s.
- The model claimed an interview question it never searched for; a prompt rule did not stop it, an orchestration gate did.
Accomplishments that we're proud of
The agent says "not found" instead of inventing, and the page marks any citation that no tool result backs. The synthetic demo is fully separate from personal data, with its own database, API and web app and a daily model-call cap. Development happens in the open: issues, pull requests, CI and releases.
What we learned
Module tests passing is not the product working. The useful failures only appeared when the whole loop ran on real data, and the durable fixes were in orchestration and data flow, not in longer prompts.
What's next
Reading a resume to build the evidence chain, moving public-site collection and alerts to a small server so they run while the laptop is off, and email and calendar connectors that propose application updates for approval.
Honest note on the requirements
Polaris runs on Qwen through Alibaba Cloud Bailian. This entry does not use Nebius Token Factory or an NVIDIA model: activating Nebius billing needs a bank card and a first payment, which I could not set up as a student in China. The model layer speaks the OpenAI-compatible API, so switching providers is a configuration change, but that path has not been run. The hosted demo is not deployed yet; the video shows the full flow, and the synthetic demo runs locally from the repository (docs/DEMO.md).
Built With
- docker
- fastapi
- langchain
- langgraph
- mcp
- neo4j
- next.js
- pgvector
- playwright
- postgresql
- python
- qwen
- react
- typescript
Log in or sign up for Devpost to join the conversation.