How Trade Tracker works

Under the hood, the assistant runs as a LangGraph ReAct agent: an LLM node decides what to do next, and a tools node carries it out, looping until the model has enough information to give you a real answer. Read tools — stats lookups, semantic search over your notes, generated insights — execute immediately, so the agent can pull your actual win rate or a specific losing streak instead of guessing at it.

Responses stream back over Server-Sent Events, token by token, so you see the answer forming rather than staring at a spinner. Conversation state is checkpointed to Postgres on every turn, which matters more than it sounds — the app runs on serverless functions that get recycled between requests, so a long-running conversation has to survive the process that started it disappearing.

The agent can read your account freely, but it never writes to it silently. Write tools — tagging a trade, editing a note — don’t execute when the model calls them. Instead they raise an interrupt: the graph pauses, and the exact change is proposed to you as a structured, typed diff, not a paragraph of prose describing what it “plans” to do.

Nothing happens until you explicitly confirm or cancel. Because that pause is a real checkpoint in Postgres rather than in-memory state, it survives however long you take to respond — seconds or hours later, the run resumes from exactly where it left off and performs the write only if you approved it. This is the same interrupt-and-resume mechanism shown in the agent loop above; write safety isn’t a prompt instruction that the model could ignore, it’s a hard boundary enforced by the graph itself.

When the assistant needs context beyond hard numbers — what you wrote in a trade note, or what a generated period review said — it searches for it rather than inventing it. Notes, notebook entries, and reviews are chunked and embedded into a vector index, and every query runs two retrieval strategies in parallel: vector similarity search for semantic meaning, and Postgres full-text search for exact keyword matches. The two ranked lists are merged with Reciprocal Rank Fusion, so a result that scores well on either signal — or both — surfaces near the top.

Retrieval only ever answers the “what did I write” half of a question. The numbers half is handled separately: a deterministic rule engine computes hold time, drawdown, and streak insights directly from structured trade data, with no LLM in the loop. That keeps figures exact and reproducible instead of a model’s best guess at arithmetic, while retrieval supplies the narrative context alongside it.

An LLM-powered feature is only as trustworthy as the checks around it. Every change to the agent runs against a fixed evaluation dataset in CI, scored by an LLM-as-judge on three fronts: did it pick the right tool, did it ever attempt a write without proposing it for confirmation, and is the answer actually grounded in retrieved or tool data rather than invented. A regression on any of those three blocks the change.

In production, every agent run is traced end-to-end — the full sequence of reasoning steps, tool calls, and tool results — for debugging and for reviewing eval failures after the fact. Errors, including ones that occur mid-stream while a response is being generated, are captured across both the web app and the background sync worker rather than failing silently.