FinRobot: a multi-agent equity research platform where the numbers come from code, not the model

The problem FinRobot targets: research that cannot be traced back to a number

Ask a general-purpose LLM for a discounted cash flow and you get a plausible paragraph with invented inputs. FinRobot exists to close that gap. The README frames the project as an AI agent platform for financial applications that "surpasses FinGPT's single-model approach" by unifying LLMs, reinforcement learning and quantitative analytics for investment research automation, algorithmic trading strategies and risk assessment.

The intended user is not a retail investor asking for a stock tip. The repository is organised around equity research workflows: company research, DCF, comps, LBO, DDM, earnings and investment committee memo generation. The desktop release notes describe analysts moving "from market data and company filings to valuation, debate, synthesis, and investment committee-style reports in one traceable workflow." That is the audience: someone producing a research artefact that another person will read and challenge, where a wrong WACC is a real error rather than a stylistic one.

Deterministic compute, LLM narration: the architectural bet

The README states the design principle directly: "Numbers are code-calculated. Narratives are LLM-assisted. Every output is provenance-tracked." Valuation outputs such as DCF, DDM, LBO, WACC, comparable-company analysis and Monte Carlo simulations are produced by pure-Python compute operators, not by the language model. The model is reserved for reasoning, synthesis, explanation and report writing.

The codebase snapshot in the README lists 30 pure-Python operators and 7 coordinators for valuation, WACC, Monte Carlo and financial modelling, plus 7 research pipelines. Orchestration sits above that: one Lead Agent routes work through five role-based sub-agents (data, analysis, modelling, synthesis, report), and three debate agents (bull, bear, judge) argue the case before a judge-style agent closes it. The README's diagram puts the debate stage after the synthesis and report stage, which means the adversarial pass runs on an already-formed position rather than gating it.

This separation is the most defensible thing about the project. It means a wrong number is a bug in readable Python, not a sampling artefact. It also means the LLM cannot rescue a pipeline whose data provider returned nothing, which is a limitation rather than a feature.

Installing FinRobot from PyPI and running a first pipeline

The package is published on PyPI as finrobot, and setup.py pins python_requires to ">=3.10, <3.12". Note the mismatch: the README badge points at Python 3.8 and the classifiers list 3.6 through 3.11, but the packaging metadata is the stricter and more current statement. Plan for Python 3.10 or 3.11.

Install the library and its dependencies from the repository's requirements file:

pip install finrobot
pip install -r requirements.txt

requirements.txt pulls in pyautogen, finnhub-python, yfinance, backtrader, sec_api, pandas, langchain and a pinned set that includes pandas==2.0.3, numpy==1.26.4 and langchain==0.1.20. Those pins are tight enough that you should install into a fresh virtual environment rather than a shared one.

The desktop track is separate. The release notes say FinRobot Desktop v0.1.0 ships for macOS Apple Silicon only, as FinRobot_0.1.0_aarch64.dmg, which you drag into Applications. The app is not Apple-notarized, so the README gives this one-time fix:

xattr -cr /Applications/FinRobot.app

Run that in Terminal, then open the app normally. If you prefer the server route, the repository's Dockerfile builds the equity web app and exposes port 8001:

EXPOSE 8001
CMD ["uvicorn", "finrobot_equity.web_app.main:app", "--host", "0.0.0.0", "--port", "8001"]

That image installs requirements-equity.txt, not requirements.txt, so the two install paths do not share a dependency set. The README does not document a rollback procedure for either.

Where FinRobot breaks: provider keys, macOS-only builds and the missing rollback story

The data layer is the weakest link. The README lists seven providers with failover: FMP, Finnhub, yfinance, SEC EDGAR, Adanos, NewsAggregator and FX. Failover helps when a provider rate-limits you. It does not help when a ticker is simply absent from the cheaper sources, and the README does not describe how conflicts between providers are resolved or which source wins when two disagree on the same figure.

Platform support is narrow on the desktop side. "FinRobot Desktop currently supports Apple Silicon Macs, M1, M2, M3, or later. Intel Mac builds are not available in this release." There is no Windows or Linux desktop build in the release notes. Linux users get the Docker route and the web app instead, which is a different product surface.

Notarization is absent, and the README's own workaround is to strip the quarantine attribute with xattr. That is a reasonable instruction from a project you trust, and a bad habit to build if you routinely apply it to unsigned binaries from elsewhere.

Finally, the licence metadata is inconsistent. The repository metadata says Apache-2.0 and ships a LICENSE and NOTICE file plus a TRADEMARK_POLICY.md. setup.py declares license="MIT" and a "License :: OSI Approved :: MIT License" classifier. Both cannot describe the same distribution. Anyone embedding FinRobot in a commercial product should read the LICENSE and NOTICE files rather than the packaging metadata, and should treat the trademark policy as a separate constraint on naming.

FinRobot versus FinGPT: a platform against a fine-tuning approach

The README positions FinRobot explicitly against FinGPT, describing it as surpassing "FinGPT's single-model approach." The difference is architectural, not cosmetic. FinGPT is a fine-tuning effort: you adapt a model to financial text. FinRobot is an orchestration effort: you keep a general model and surround it with agents, deterministic compute operators and data providers.

That changes what you debug. With a fine-tuned model, quality problems show up as degraded generation and are addressed with data and training runs. With FinRobot, a wrong answer usually traces to a pipeline stage, a provider response or a compute operator, all of which are inspectable. The trade-off runs the other way too: FinRobot inherits the latency, cost and failure modes of every API call in the chain, and its output quality is bounded by the data providers you can afford to key in. A single fine-tuned model has no provider dependency at inference time.

If your problem is extracting structured information from filings, the fine-tuning route is a better fit. If your problem is producing a multi-section research document with auditable valuation figures, the agent pipeline is the more honest structure.

Maintenance, upgrade cost and what the release history implies

The repository is not archived, and the last push was on 2026-09-07. Two releases are listed: v1.0.0 (FinRobot Equity Research) on 2026-03-20 and desktop-v0.1.0 on 2026-07-07. The desktop line is at 0.1.0, which tells you the native app is early relative to the Python library, whose setup.py reports version 0.1.5.

Upgrade cost is driven by the pinned dependency set. requirements.txt holds pandas==2.0.3, numpy==1.26.4, aiohttp==3.8.5, langchain==0.1.20 and typing_extensions==4.9.0, while the Dockerfile builds on python:3.13-slim and notes that build-essential is "needed to compile numpy<2 from source on Python 3.13." Those two facts sit awkwardly together: the library pins an old numpy, and the container compensates by compiling it. Moving to a newer pandas or numpy will require touching those pins and re-testing the compute operators.

The Dockerfile also installs requirements-equity.txt rather than requirements.txt, so a dependency bump has to be applied in two places. There is no migration guide in the README for either path. On licensing, Apache-2.0 as stated in the repository metadata permits commercial use with attribution and includes a patent grant; the MIT declaration in setup.py would be more permissive, but the discrepancy means you should resolve which text governs before shipping. This is a description of the files, not legal advice.

Editorial conclusion

Adopt FinRobot if you want an auditable equity research pipeline in which DCF, WACC, comps and Monte Carlo outputs come from Python operators and the language model is confined to narration, and you are comfortable running a Python 3.10 or 3.11 environment with your own LLM and market-data keys. Do not adopt it if you need Intel Mac support, a notarized desktop app, or a valuation methodology you cannot read and verify in the compute operators yourself. Before committing, check that requirements-equity.txt resolves in your environment, confirm which providers your FMP, Finnhub and SEC EDGAR keys unlock, and read the Apache-2.0 LICENSE and NOTICE files, since setup.py in the repository declares MIT while the repository metadata says Apache-2.0.

Frequently asked questions

Official sources

1. AI4Finance-Foundation/FinRobot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases