TestForge Blog
← All Posts
#ai #rag #agent #architecture #investment

RAG-Based AI Stock Investment Agent Part 1 — Requirements and Overall Architecture

A practical blueprint for a RAG-based AI stock investment Agent. Covers product goals, user scenarios, system boundaries, core components, and end-to-end architecture for a research and paper-trading workflow.

TestForge Team ·

Start With the Right Assumptions

This series is not financial advice. It is an engineering series about building a RAG-based investment analysis Agent.

The initial assumptions are:

  • Start with paper trading, not real automated trading
  • Prioritize research support and evidence-backed recommendations
  • Always provide sources and reasoning
  • Require human approval before any real execution

That boundary is important technically and operationally.

What Product Are We Actually Building?

The goal is not to output “buy this stock.”

The real product goal is to build a system that:

  • Collects price data, news, filings, and earnings transcripts
  • Retrieves relevant context for a stock or strategy question
  • Uses RAG to generate evidence-backed analysis
  • Applies risk rules before surfacing trade candidates
  • Supports backtesting and paper trading

In other words:

LLM + RAG + market data + risk engine + controlled execution

Representative User Scenarios

1. Single Stock Analysis

Question:

Is NVIDIA still a reasonable entry candidate this week?

The Agent should:

  1. Fetch recent news, filings, and earnings commentary
  2. Summarize recent price behavior and volatility
  3. Check sector context
  4. Review current portfolio exposure
  5. Return evidence-backed analysis and risk notes

2. Strategy-Driven Screening

Question:

Find large-cap US stocks where post-earnings momentum is still holding two weeks later

The Agent should:

  1. Parse strategy conditions
  2. Screen the stock universe
  3. Pull recent events and news
  4. Combine quantitative and qualitative signals
  5. Return ranked candidates with supporting reasons

3. Portfolio Review

Question:

Is my portfolio too concentrated in AI semiconductor names?

The Agent should:

  1. Classify holdings by sector and theme
  2. Measure concentration
  3. Evaluate downside scenarios
  4. Suggest rebalance ideas

Define System Boundaries Early

A stock investment Agent can become too large very quickly.

Include in the first version:

  • US equities
  • price, news, filing, and basic financial data
  • query-based analysis
  • strategy-based screening
  • portfolio proposal support
  • paper trading logs

Exclude at first:

  • fully automated real-money execution
  • options, futures, crypto all at once
  • high-frequency strategies
  • fully automated personal financial advice

Clear boundaries keep the project realistic.

[1] Data Ingestion
    - price data
    - news
    - filings
    - financial metrics

[2] Storage Layer
    - PostgreSQL
    - pgvector
    - Redis
    - object storage

[3] Research Layer
    - indicator computation
    - event normalization
    - chunking / embeddings

[4] RAG Retrieval Layer
    - news retrieval
    - filing retrieval
    - stock-specific context retrieval

[5] Agent Orchestration
    - planner
    - screener
    - analyst
    - risk evaluator

[6] Application Layer
    - FastAPI
    - admin tooling
    - user-facing analysis APIs

[7] Execution / Simulation Layer
    - backtesting
    - paper trading
    - approval queue

This split makes responsibilities easier to reason about.

Why RAG Is Valuable in Investing

Traditional quantitative systems can operate on prices and factors alone.

But investment decisions also depend on text-heavy events such as:

  • guidance changes
  • management tone shifts
  • regulatory risk
  • supply chain issues
  • earnings call commentary

That context often lives in news articles, transcripts, and filings. That is exactly where RAG helps.

A Practical Tech Stack

A realistic first implementation might use:

  • FastAPI for APIs
  • PostgreSQL for structured data
  • pgvector for embeddings
  • Redis for caching and short-lived state
  • Celery or a similar worker for async tasks
  • APScheduler or Airflow for scheduled jobs

You usually do not need Kafka or a complex streaming stack on day one.

Core Domain Entities

It helps to define the domain model early:

  • symbol
  • price_bar
  • company_profile
  • news_article
  • filing_document
  • earnings_transcript
  • embedding_chunk
  • analysis_run
  • portfolio
  • paper_order
  • risk_rule_result

These entities connect the data, the Agent, and the execution layer.

Example Request Flow

Question:

Analyze whether Tesla is too risky for a new position over the next 30 days

Flow:

  1. Router classifies the request as single-stock-analysis
  2. Screener summarizes recent trend and volatility
  3. Retrieval searches news, filings, and transcript chunks
  4. Analyst combines structured metrics and RAG context
  5. Risk engine checks concentration and event risk
  6. Response composer returns an evidence-based result

One model call should not do all of this alone.

The Highest-Risk Parts of the System

Technical and operational risks include:

  • stale news driving analysis
  • hallucinated justifications
  • ignored concentration risk
  • broken or delayed data feeds
  • accidental transition to automated execution

So the architecture should enforce:

  • no unsupported claims
  • a separate risk engine
  • human approval
  • per-strategy and per-symbol limits
  • paper trading first

Series Roadmap

This series continues as:

  1. Requirements and architecture
  2. RAG data pipeline for market events
  3. Agent workflow and tool design
  4. Portfolio, risk, and backtesting
  5. FastAPI implementation structure
  6. Paper trading and safe operations

Closing Thoughts

The most important architecture decision is not where to place the LLM. It is where to stop the system.

A strong first version focuses on analysis support, paper trading, source-backed reasoning, and explicit risk control.