About

Conductor is a natural-language interface to the L-functions and Modular Forms Database (LMFDB), a comprehensive repository of mathematical objects arising in number theory and arithmetic geometry.

While the web interface of the LMFDB is excellent for looking up individual objects, querying and analysing data across the entire database often requires a nontrivial amount of familiarity with its extensive underlying schema, and of programming in general.

Conductor is a research-grade tool which aims to lower this barrier through its natural-language interface. It is capable of retrieving data across the LMFDB and analysing it through plots or statistical methods, all from plain English queries. For mathematicians with coding knowledge, it also automatically attaches all of the code it generates, allowing for full transparency and rigor in verifying its outputs. We expect that this software will not only aid mathematicians without technical backgrounds, but will help to accelerate active research in the growing field of AI-assisted mathematics.

Limitations

• Conductor connects to devmirror.lmfdb.xyz, a PostgreSQL mirror of the LMFDB which may not have complete coverage of all tables. Moreover, the LMFDB itself is not exhaustive — some queries may return no results due to a genuine lack of data.
• Because SQL generation is not infallible, the model may produce inaccurate results. It is good practice to double-check the underlying code produced by the model if you intend to rely on its output for research purposes.
• Conductor is under active development. If you encounter an error or unexpected behaviour, please open an issue on GitHub.

Acknowledgements

Conductor was built by Ritik Jain. You can learn more about its architecture here.

This work would not be possible without the LMFDB itself, which is the product of an enormous collective effort. A list of contributors is available here.

Miscellany

• The name "Conductor" has a double meaning: it refers to both the notion of a conductor in number theory, and a conductor as a conduit of knowledge.
• The pixelated background which appears on the home page and during thinking phases evolves according to the Game of Life, a cellular automaton invented by John Conway in 1970.

Architecture

The backend of Conductor consists of a seven-stage FastAPI pipeline with error handling. We utilize Claude Haiku 4.5 for classification; otherwise we use Claude Sonnet 4.6, which handles user interactions and more complex tasks.

0. An intent classifier determines whether the incoming message is a mathematical query or a conversational message. Conversational messages receive a natural response and skip all subsequent stages.
1. An LLM-as-judge assesses whether a query needs clarification. If it is ambiguous, the model asks a followup question, else it returns a refined restatement passed to all subsequent stages.
2. A lightweight object resolution stage scans the query for mathematical objects to match to the database.
3. The model maps the query to a list of relevant LMFDB table names using a two-layer hierarchical schema index (16 domains, 86 tables).
4. The model produces a validated SQL query using the tables identified in the previous step, enforcing correctness by using our schema as a ground truth.
5. The SQL query is executed against the LMFDB database, returning a table of results.
6. (Optional) A follow-up natural language instruction is translated into Python. Plots and subsequent data analysis are captured in-memory and returned alongside the generated code.

Roadmap

As of now, Conductor operates via a layered pipeline of LLM calls which handle various tasks, including user interactions, SQL generation, data analysis, and more. While this pipeline is functional and works well, its reasoning capabilities are limited by the fact that each stage is executed independently with a small context window.

A more robust and modern architecture would replace the current layered approach with a single agentic LLM equipped with tools designed for it to execute each aspect of the pipeline. Here, rather than passing through a fixed pipeline with a different LLM at each stage, the model would plan its own approach, iterating and correcting errors until it has an optimal final response.

A natural next step is to integrate this pipeline with an agentic framework via a Model Context Protocol (MCP) server. Building on the recent LMFDB MCP developed by Andrew Sutherland, this server would add a semantic layer, allowing users to ask and receive responses in plain English, and would also add a richer contextual toolset for the backend. As agentic systems grow increasingly capable, we believe that such substrates will provide exciting opportunities for mathematical discovery.