Building an Agentic AI System for Real-Time Stock Intelligence: Why We Chose a Multi-Agent Architecture Over a Single LLM Pipeline
Lessons from designing a production-grade agentic AI system for NSE stock analysis, event-driven prediction, and portfolio intelligence.
Background
Retail and semi-professional investors tracking the Indian stock market (NSE) face a familiar problem: the signal is scattered. News sentiment lives in one place, technical charts in another, fundamentals in a filing PDF, and the “why did this stock suddenly move” question is usually answered days later, after the opportunity has passed.
A single-prompt LLM wrapper can summarize a stock on request, but it can’t reliably do what serious analysis actually requires: pull real financial ratios instead of hallucinating them, flag when a trade idea is too risky before recommending it, or explain why it disagrees with itself when different signals point in different directions.
The goal was to build a system that could:
- Ingest live news, fundamentals, technical data, and social sentiment continuously
- Produce a single, explainable forecast per stock — not just a sentiment score
- Refuse to hide disagreement between signals, or override risk warnings, just because the LLM’s fluent output made everything sound confident
- Detect market-moving events (elections, policy announcements, RBI decisions) in real time and flag which stocks historically react the same way
- Never place a trade autonomously — this is a decision-support system, not an execution system
Solution Architecture
Data Flow
Live News (multi-source RSS) ─┤
Social Sentiment (StockTwits) ─┼──► LangGraph Multi-Agent Orchestration ──► FastAPI ──► Web UI (Streamlit / Node.js)
Neo4j Graph (stocks, sectors, similarity) ─┘ ──► Postgres / SQLite (backtest ledger, time series)
Why This Architecture?
LangGraph for agent orchestration, not a single prompt chain. Rather than one LLM call trying to do everything, the system is built as a graph of specialist agents, each with one job:
Classifies headlines by event type and scores sentiment, but also computes novelty (is this actually new information, or a stale headline resurfacing?) and decay (how much should a 3-day-old story still count today?). Skipping this is a common failure mode: without it, an agent can “react” to old news as if it were breaking.
Pulls real financial ratios (P/E, ROE, debt/equity, free cash flow) from a live data source, never from LLM generation. Deliberately low-frequency: fundamentals don’t change intraday, so this agent reads from a quarterly-refreshed cache instead of re-querying every cycle.
Intentionally the lowest-weighted signal in the ensemble. Its real value isn’t predicting direction; it’s flagging unusual chatter-volume spikes and coordinated pump-and-dump patterns.
Computes volatility (EWMA, a lightweight GARCH-style proxy), historical Value-at-Risk, and position correlation against an existing portfolio. Structurally different from the others: its veto is a hard gate, not one more weighted vote. A bullish signal from every other agent cannot override a genuine tail-risk warning.
Runs last, after the other four, specifically to catch the case where every stock-specific signal looks bullish but the whole sector or market is about to get dragged down in a broader selloff.
Aggregates everything with a dynamically weighted ensemble. Weights shift based on each agent’s own rolling backtest accuracy, stored and queried from a real database table. Every prediction ships with an explicit dissent log — which agents disagreed, and why — rather than smoothing disagreement into one confident-sounding number.
Event Radar: pattern-matching against real market history
A second subsystem watches live news continuously and classifies it against a playbook of recurring event categories — election results, EV policy announcements, RBI rate actions, budget allocations, commodity shocks — each mapped to the sectors and stocks that have historically reacted, with the actual historical example attached. This keeps every “opportunity” the system surfaces explainable and auditable: the person can see exactly which historical analog the system is pattern-matching against, rather than trusting a black-box score.
Neo4j for relationship-shaped data
Stock similarity, sector membership, and peer comparisons are inherently graph-shaped queries (“find stocks like this one,” “what’s the sector breadth right now”). Modeling this in Neo4j made those queries natural instead of forcing multi-join SQL for relationship data that isn’t relational by nature.
Dual-backend Postgres/SQLite for the backtest ledger
Every agent’s directional call is logged and later resolved against the real outcome, so the ensemble weighting is data-driven rather than a one-time design guess. This ledger runs on SQLite for local development and the same codebase points at Postgres in production with a single environment variable.
Pluggable LLM layer: Ollama locally, Groq in the cloud
The LLM is only ever used to narrate an already-computed structured result — direction, confidence, magnitude band, dissent — never to invent the numbers themselves. This keeps the output auditable, and means the LLM provider itself is swappable without touching any agent logic.
Two frontends, one backend
The FastAPI backend is the single source of truth; Streamlit and a lightweight Node.js/Express UI are both just thin clients calling the same REST API. Neither frontend duplicates any analysis logic — a change to an agent is instantly reflected in both UIs.
Why Not a Single-Agent Chatbot?
A single LLM agent with tool access can answer “what’s happening with this stock” in a general sense. It cannot, by construction:
- Guarantee a risk warning isn’t silently smoothed over by a fluent, confident-sounding answer
- Show why it disagrees with itself, because there’s only one pass of reasoning to inspect
- Separate “this needs to be recomputed every cycle” from “this barely changes” — a single agent re-does everything on every call, which is slow and unnecessary
- Make its own confidence level track a real, measurable track record instead of the model’s general-purpose fluency
This doesn’t make single-agent designs wrong in general — for simple lookup-and-summarize tasks they’re often the right, cheapest choice. For a system making probabilistic claims about financial outcomes, the extra structure of separable, individually-auditable agents with a hard risk gate is what makes the output trustworthy enough to act on.
What the System Delivers
KEY TAKEAWAYS
- Design for the failure mode, not just the happy path — a risk agent that’s “one more vote” is a design flaw the moment a strong bullish signal needs to be overridden.
- Separate what changes fast from what doesn’t. Re-querying fundamentals every cycle is pure cost with zero new information.
- Make disagreement visible. A system that resolves every internal conflict into one smooth answer is hiding the most useful information it has.
- Let the LLM narrate, not decide. Keeping computed numbers separate from the language model’s output keeps the whole system auditable.
- Backtest the parts, not just the whole. Each agent’s own accuracy should be tracked and used to reweight it.
Final Thoughts
There is no universal “best” way to build an agentic AI system. The right architecture depends on whether the system’s job is to summarize or to decide.
For summarization, a single well-tooled agent is often the simplest, cheapest, correct choice. For a system making probabilistic claims that a person might act on financially, the extra discipline of separable specialist agents, a non-negotiable risk gate, an explicit dissent log, and a strict separation between computed numbers and LLM narration is what turns “an AI that sounds confident” into “an AI whose confidence means something.”