Financial Agent: Multi‑Agentic System
Build a small but production‑minded multi‑agent system that produces a concise financial
analyst for any five US‑listed companies from its latest SEC 10‑K plus live market data. Your
system must use Agentic RAG (beyond naïve retrieval), make API calls for current metrics
(open/close, market cap, price, shares outstanding, etc.), and maintain both global and
per‑session memory.
Outcomes
Given a stock ticker (e.g., MSFT, AAPL), your system should:
1. Ingest & index the company’s last 5 years 10‑K.
Note: You may simply download PDFs and look to ingest. No separate pipeline
required for fetching it directly.
2. Retrieve the most relevant sections with an agentic strategy (planner, query
decomposition, iterative retrieval, hybrid search, re‑ranking, etc.).
3. Call a market data API to fetch current quote & fundamentals (open/close, last price,
market cap, shares outstanding; add others if available).
Suggestion: YFinance API
4. Synthesize a response with inline citations back to the 10‑K sections it used or any
other data source.
5. Return outputs:
○ Markdown (human‑readable brief).
6. Use memory:
○ Global memory: persisted across runs (e.g., user/company preferences,
previously analyzed tickers, rubric weights).
○ Session memory: ephemeral within a single run/session (e.g., follow‑up
questions, interim reasoning summaries).
Functional Requirements
Agents Collection (feel free to add more)
● Orchestrator/Planner: decomposes the user query into sub‑goals, selects tools/agents,
and plans retrieval steps.
● SEC Researcher (RAG): fetches filings; performs advanced retrieval against indexed
10‑Ks; returns evidence chunks with provenance (document URL, section, heading,
character offsets or page range).
● Market Data Agent (Yahoo Finance API): fetches live metrics (open/close, price,
market cap, shares outstanding, 52‑week range if available) with timestamps and the
market/timezone used.
● Financial Analyst: synthesizes the brief, runs sanity checks on numbers, highlights key
drivers and risks; writes clear, concise prose.
● Auditor/Fact‑Checker: verifies that each claim derived from filings has a citation and
that numeric figures match within tolerance.
● Memory Manager: updates and reads global/session memory according to the memory
spec below.
Agentic RAG (must be beyond naïve)
Design your own retrieval strategy suitable for long, structured 10‑Ks. The system must go
beyond a single‑pass embedding + top‑k lookup.
What we will check (without prescribing how to do it):
● You clearly describe your retrieval architecture and planning approach and justify why it
fits 10‑Ks.
● The agent must be able to access information and compare across documents for more
clarity.
Market Data API (real‑time)
● Provide: latest price, previous close, today’s open (or last open), market cap, shares
outstanding. Include timestamp and data source.
Memory Requirements
● Global memory (persistent)
○ Examples: preferred risk taxonomy, writing style (“bullet‑first, then narrative”), last
N tickers analyzed with summary vectors, user’s preferred KPIs.
○ Storage: key‑value store (e.g., SQLite/Redis) and a Vector database (choose any
and explain why it's a perfect fit for the production) for brief summaries/notes.
○ Include versioning and TTL controls where sensible.
● Session memory (ephemeral)
○ Conversation turns, intermediate plans, etc.
○ Persistence to be managed by the Memory Manager.
Non‑Functional Requirements
● Reproducibility: pin dependencies; seed any sampling; document model versions.
● Observability: structured logs for: plan steps, retrieval queries, chosen tools, API
responses (redact keys), and citations.
● Cost Awareness: if using paid APIs/LLMs, print a cost summary per run.
What To Deliver
1. Code repo with:
○ [Link] (how to run, env vars, design choices, limitations).
○ Architecture diagram and Design Doc (1–2 pages) explaining your agent roles,
memory schema, RAG pipeline, failure modes.
○ Automated tests:
■ Unit tests for memory, retriever, API client.
○ Seed data & scripts for indexing 10‑Ks.
○ Dockerfile + [Link].
2. Demo: clear instructions to run the demo.
Submission
● Share a Git repo (public or ZIP) with instructions.
● Include a short video (3-5 min) showing one run end‑to‑end.
End Goal & Evaluation Philosophy
End goal: Not merely to “make it work,” but to demonstrate sound design choices
and the reasoning behind them.
We will prioritize:
● Architecture clarity & boundaries how agents, tools, and stores fit together; why this is
an appropriate decomposition for PDFs + live data.
● Trade‑offs & constraints explicit choices (and rejections) with rationale: correctness vs
latency, cost vs capability, complexity vs maintainability.
● Memory & retrieval design quality clear scoping rules for global vs session memory
and a retrieval approach justified for long, structured filings (without prescribing
techniques).
● Failure modes & mitigations how your system detects weak evidence, stale/missing
data, and tool/API errors, and how it recovers or reports uncertainty.
● Observability & tests logs/traces that make the plan/retrieval/synthesis legible; unit and
golden tests that check citations and numeric sanity.