LLMs-in-Finance: A Notebook Collection for Agentic Finance Workflows

What the repository actually contains, and what it is not

The README describes LLMs-in-Finance as hands-on Jupyter notebooks applying generative AI tools to practical finance use cases. The top-level structure is four directories plus a fifth for other examples: Agents, RAG, Multimodal_llms, Papers, and a section the README calls Others, covering synthetic data. Everything is organised by framework or technique, not by financial function. There is no package to install, no importable module, and no CLI. The unit of delivery is the notebook.

That matters for how you evaluate it. A repository shaped this way is judged on whether its examples transfer, not on whether its API is stable. The README's own framing is explicit: the project is intended solely for educational and research purposes, is not designed for real trading or investment use, and provides no warranties. The creator states no responsibility for financial losses. Those lines are worth taking literally rather than as boilerplate, because several notebooks are named after trading tasks.

The intended reader is someone who already knows Python and wants a reference implementation of a pattern, not someone looking for a component to depend on.

Agents in Finance: five frameworks, one directory

The Agents directory is split by vendor and framework. OpenAI holds an autonomous strategy code review using LLM-as-a-judge, and a financial news bot built as an evaluator-optimizer multi-agent system. AutoGen holds two notebooks around a momentum trading strategy, one for configuring a financial agent to fetch and analyse data, one for collaborative task management to optimise that strategy. LlamaIndex holds a code interpreter agent using Anthropic, an introspective agent worker for financial tasks, and a multi-agent fundamental analysis workflow. CrewAI holds a collaboration example that produces an Apple trend analysis, news sentiment extraction, and proposed trading strategies. LangGraph sits under a directory named LangChain and covers taking a trading strategy from concept to execution and reflection. Anthropic has one notebook combining Anthropic, LlamaIndex and APIs into an agentic system.

The layout is the most useful thing here. If you have already chosen a framework, you can read the same class of problem solved six ways and compare how each one expresses tool use, handoff and evaluation. The evaluator-optimizer pattern in the OpenAI directory and the LLM-as-a-judge idea recur across the set, which suggests the author treats a critic loop as the default quality mechanism rather than an add-on. Whether that is the right default for financial text is arguable. A judge model scoring its own family's output on a trading rationale is a weak check, and the README does not claim otherwise.

RAG over financial reports, and the evaluation gap

The RAG directory is where the parsing problem gets addressed directly. The README names LlamaIndex, Anthropic, OpenAI and aisuite as the providers and libraries used to parse complex financial reports, and points to two specific notebooks: Financial Report Analysis with LlamaParse AutoMode under RAG/llamaindex, and Anthropic_Prompt_Caching.ipynb under RAG/Anthropic. There is also an evaluation folder using DeepEval and GiskarAI.

The choice of subject is sound. Annual reports and filings are hostile documents for retrieval: dense tables, footnotes that carry the actual number, and layout that changes between issuers. LlamaParse AutoMode is presented as the answer to the layout problem, and prompt caching is presented as the answer to the cost problem of resending a long filing on every turn. Those are two genuinely different concerns and the repository keeps them in separate notebooks rather than pretending one solves both.

The evaluation folder is the part I would open first. Retrieval quality on financial documents is easy to demonstrate and hard to measure, and the presence of a DeepEval and GiskarAI example suggests the author agrees. Note the limit: the README lists the evaluation example in a single sentence and does not state which metrics are computed or what thresholds are used. You will have to read the notebook to find out, and you should not assume the numbers generalise beyond the filings it was run on.

Multimodal chart reading and the papers index

The Multimodal_llms directory targets a narrower question: how well models read the charts embedded in financial reports. The README names Claude Sonnet 3.5, GPT-4o and the o1 reasoning model, and describes the goal as evaluating how effectively they interpret complex charts. This is the most falsifiable claim in the repository, and also the one most likely to age badly, because model identifiers in this space are superseded on a short cycle. A notebook written against a specific model name is a snapshot of that model's behaviour on that date, not a property of the class of models.

The Papers directory is a curated summary of research on generative AI in financial applications, and the README frames it as brief descriptions rather than reproductions. Treat it as a reading list. It is the only part of the repository that does not require an API key to be useful, which is a point in its favour if you are still deciding whether the agent patterns are worth the integration cost.

Across both directories the pattern is the same: the author picks a concrete artefact (a chart, a filing, a news article) rather than a toy string, which is the right instinct for a domain where the input format is the hard part.

Getting a notebook running: what the README does and does not tell you

The README documents no installation procedure, no requirements file, no environment setup and no API key configuration. It links to directories and file paths, and that is the extent of the operational guidance. So the runbook is implied by the layout rather than stated: clone the repository, create a Python environment, install the libraries the notebook you picked imports, export the provider credentials it needs, and open the file with Jupyter.

The libraries named across the README are the ones you will be installing: the OpenAI Agents SDK, Anthropic's Claude client, AutoGen, LlamaIndex, CrewAI, LangGraph, LlamaParse, aisuite, DeepEval and GiskarAI. Several of these are fast-moving projects with breaking changes between minor versions, and because the repository carries no releases and no lockfiles, nothing pins them to a known-good combination. The practical consequence is that a notebook written months ago may fail on import before it fails on logic.

If you want to run something without credentials, the Papers directory is the only place to start. If you want to run an agent notebook, budget time for dependency archaeology, and read the imports cell before anything else.

Where this is the wrong tool

The clearest limitation is stated by the author, not inferred: the project is not designed for real trading or investment use and provides no warranties. That is not modesty. An agent that fetches market data, reasons about a momentum strategy and proposes trades is a demonstration of orchestration, and nothing in the README describes backtesting discipline, transaction cost modelling, survivorship handling or point-in-time data. The notebooks show the plumbing; they do not show that the strategy survives contact with a market.

The second limitation is structural. Notebooks are not testable artefacts in the way libraries are. There is no test suite described, no CI configuration mentioned, and no releases. A pattern you lift from a notebook into a service inherits none of the notebook's context, and you will be reimplementing the error handling yourself.

The third is the evaluation claim. Several notebooks score outputs with a model, and the README does not discuss judge reliability or how the judge itself was validated. For financial text, where a plausible-sounding rationale can be confidently wrong, an unvalidated judge is a weak signal. If your use case needs an auditable decision, this repository gives you a starting point and not an answer.

Alternatives, and how the approach differs

The obvious alternative is the official documentation and example repositories for each framework the project covers. AutoGen, CrewAI, LlamaIndex and LangGraph all publish their own quickstarts and sample applications. The difference is domain: those examples use generic tasks, while this repository uses earnings reports, news sentiment and strategy code. If you want to learn the framework, go to the source. If you want to see the framework pointed at a filing, this repository saves you the translation step.

A second alternative is a RAG framework used directly for document question answering, such as building on LlamaIndex or a similar retrieval library without the agent layer. That path produces a system that answers questions about a document and stops there. This repository goes further by adding planning, tool use and critic loops, which buys you multi-step analysis and costs you predictability. For a compliance-adjacent workflow where every step must be explainable, the plain retrieval pipeline is the safer design, and the agent notebooks here are the wrong starting point.

A third comparison is against the research literature the Papers directory summarises. Papers describe methods with reported results on defined datasets. This repository describes implementations with no reported results. Use the papers to decide what is worth building, and the notebooks to see one way of building it.

Maintenance, licence and upgrade exposure

The repository is not archived and the last push was on 2026-09-12, the day before this review, so the code is current. It carries no releases, which means there is no version to pin and no changelog to read when something breaks. Upgrades therefore arrive through the dependencies rather than through the project: when the OpenAI Agents SDK, AutoGen, LlamaIndex or LangGraph changes an interface, the affected notebook stops working until the author updates it or you do. There is no stated support commitment and no deprecation policy in the README.

The licence is MIT. In practical terms that permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. It also means the software is provided without warranty, which aligns with the README's own disclaimer that the project is for educational and research purposes and that the creator bears no responsibility for financial losses. If you copy a notebook into a commercial pipeline, you carry the correctness burden entirely. None of this is legal advice; read the MIT text and your own counsel's view before shipping anything derived from it.

One more cost worth naming: because the material is organised by framework, keeping it current means tracking six ecosystems, not one. That is the maintenance burden this layout accepts in exchange for the comparison it enables.

Editorial conclusion

Adopt this if you are an engineer or analyst who wants a working reference for wiring OpenAI Agents SDK, AutoGen, CrewAI, LlamaIndex or LangGraph into a financial task and you intend to read the notebook before running it. Do not adopt it as a dependency, as a production trading component, or as a source of validated numbers: the README states the project is for educational and research purposes only and is not designed for real trading or investment use. Before you build on any notebook, open it and check which model identifiers and framework versions it pins, because the repository has no releases and no documented upgrade path, and the APIs it calls change on their own schedules.

Official sources

1. hananedupouy/LLMs-in-Finance on GitHub
2. Issues
3. License: MIT
4. README