Eastern Mysticism Platform

Multi-agent consultation platform with SSE streaming and a custom Zi-Wei chart engine.

At a Glance

A production multi-agent platform for Eastern mysticism consultations (Zi Wei Dou Shu, I Ching, name analysis), built and shipped during a two-month internship. Instead of the usual fortune-telling site that spits out a wall of hard-to-read jargon, this platform pairs a custom chart engine with an LLM that talks the result through — so users actually understand what their chart means. I owned the backend agent design and led the frontend.

Why I Built This

Most fortune-telling sites online stop at something pretty bare-bones: a plain interface, little interactivity, and — worst of all — output that's just a dense block of terminology. Users read the result and still have no idea what it means for them. I wanted to build something different: a Web experience that's genuinely interactive, and where the computed chart isn't just dumped on the user but made understandable through conversation. The goal was for the reading itself to actually land — to be something the user could engage with and act on, not just stare at.

How It Works

The core idea is a personal chart that belongs to each account. When a user registers, they fill in their personal details and the system immediately computes their Zi-Wei chart and stores it in their profile. From then on, every conversation with the LLM is grounded in that specific user's chart — the model doesn't give generic, one-size-fits-all answers, it reasons from the individual's own result. The remaining feature modules are each designed around their own functional characteristics.

Technology Choices

Multi-layer AI agents built on LangChain / LangGraph, using function calling to connect the chart data with the conversation flow
SSE streaming responses, so users see the answer appear token-by-token instead of waiting on a blank screen
A self-built Zi-Wei chart engine (ziwei_calculator.py) doing real astronomical computation via pyswisseph, rather than relying on a black-box third-party API
Async micro-services with Quart + Redis Queue, and PostgreSQL + Pinecone hybrid storage for structured profile data and vector retrieval respectively
Next.js 15 / React 19 frontend with Three.js / GSAP for an immersive feel, and multi-language support via next-intl

Challenges Along the Way

Validating an open-ended model's output. The hardest problem was that an LLM's response is open-ended, and it didn't always conform to the fixed data format the frontend expected. At first I left the final format-handling to the frontend's TypeScript — but whenever the model's output drifted even slightly from the expected shape, the frontend would error out directly. The lesson stuck: the format has to be defined and validated on the backend before it's returned, not patched up on the frontend. Once the backend tightened the structure, the frontend could render reliably.

First time implementing SSE streaming. So that users weren't just staring at a spinner while the LLM thought, I implemented SSE streaming for the first time — letting responses surface token-by-token. It's a small thing technically, but it changes the waiting experience completely.

Reflections & What I Learned

The biggest growth from this internship wasn't any single piece of technology — it was learning how to break problems down. Every issue I hit, I had to decompose it, locate the real root cause, and either find a fix or bounce ideas off other engineers to get there. Shipping a product from zero to live in two months came down to running that loop over and over: hit a problem, take it apart, solve it. That problem-solving cycle is the most valuable thing I took away from the experience.