tablegpt-agent: a LangGraph agent wired to TableGPT2

A pre-built agent, not a model, and that distinction sets the scope

The README is short, and the key sentence is the first one. `tablegpt-agent` is a pre-built agent for TableGPT2, a series of LLMs for table-based question answering, and the agent is built on top of the LangGraph library and provides a user-friendly interface for interacting with TableGPT2.

The distinction between the agent and the model matters for what you can expect. TableGPT2 is a series of models on Hugging Face, and the model card is a separate document with its own details. What this repository provides is the scaffolding around those models: the state machine, the tool interface and the plumbing that turns a table question into something you can call.

The choice of LangGraph is the second piece of information, and it is more consequential than it first appears. LangGraph is the library for building agent graphs, where a controller node decides what happens next rather than a fixed chain of steps. That is the right shape for table question answering, where the agent may need to inspect the table, call a calculation, and then answer.

The dependency list in the packaging metadata makes the stack concrete. There is `langgraph>=0.0.68,<1.0.0` and `langchain-core>=0.3.0,<1.0.0` for the agent layer, `pandas>=2.2,<3.0.0` for the data, `chardet>=5.2.0,<6.0.0` for encoding detection, and `pppybox>=0.0.17`, which is the model serving side.

Note what is not in that list. There is no model download, no credential handling and no inference client, because those belong to the model distribution rather than the agent.

What lives in the repository, and what the realtabbench directory is for

The top level of the repository shows three things at once, and they are worth separating.

The agent itself is in `src/`, with the package built by hatchling from a `pyproject.toml` that declares the name `tablegpt-agent`, a dynamic version, and a `requires-python` of 3.9 or newer. The classifiers cover Python 3.9 through 3.12, both CPython and PyPy, and the development status is `4 - Beta`.

The `examples/` directory is where you would start, and it contains `quick_start.py`, a `data_analysis.py` script, an `__init__.py` and a `datasets/` folder. A quick start script and a data analysis script are exactly the two things a new user needs, and the datasets folder implies the examples run against data you can get without an account.

The `ipython/` directory is a separate interface surface. In a notebook, a stateful agent is awkward to drive through a function call, and an IPython integration is the usual answer to that.

The third thing is `realtabbench/`, and the README describes it as a collection of evaluation scripts for table-related benchmarks, with the scripts and datasets in that directory and details in the Evaluation README. This is the part of the repository that distinguishes it from a thin wrapper.

A model release that ships only an inference wrapper gives you no way to tell whether the agent helps or hurts. Shipping the evaluation harness alongside it means the claims about the agent can be checked against a table benchmark rather than taken on trust, and it gives you the scripts to run the same checks on your own data and your own prompts.

Building and testing go through hatch, not pip and pytest

The build tooling is hatch, and the Makefile is a thin wrapper over it, which is a small and pleasant thing to have in a repository.

The default target is help, and the individual targets map to hatch commands. The lint target runs `hatch fmt --check`, the format target runs `hatch fmt`, the test target runs `hatch test`, the wheel target runs `hatch build`, the doc target runs `hatch env run -e docs mkdocs build`, and clean runs `hatch clean`.

test:
	hatch test

The Makefile comment on the doc target explains a naming decision worth copying. The comment says that `make docs` is a make command, so `doc` is used instead of `docs` to avoid conflict. That is the kind of small friction that the wrapper exists to absorb.

For a contributor, the practical sequence is `make lint`, `make test` and `make wheel`, and the `doc` target builds the documentation site with mkdocs, which matches the `mkdocs.yml` at the repository root and the `docs/` directory. The documentation site is published at the GitHub Pages URL given in the packaging metadata, which points to the same project site the README links to.

The build backend is hatchling with `requires = ["hatchling"]`, and the version is dynamic rather than written in the manifest, so it is derived at build time. The package is published to PyPI as `tablegpt-agent`, with a PyPI version badge and a Python version badge in the README.

The local extra exists for the analysis path, not the agent path

The optional dependencies tell you something the core dependency list does not.

There is a `local` extra, and it is substantial: pandas, scipy, tabulate, scikit-learn, statsmodels, matplotlib, seaborn, mplfonts, numexpr, openpyxl, xlrd, odfpy, and `pppybox[local]`.

local = [
  "pandas >=2.2,<3.0.0",
  "scipy >=1.13.0,<2.0.0",
  "tabulate >=0.9.0,<1.0.0",
  "scikit-learn >=1.0.0,<2.0.0",
  "statsmodels >=0.10.0,<1.0.0",
  "matplotlib >=3.8.4,<4.0.0",
  "seaborn >=0.13.1,<1.0.0",
  "mplfonts >=0.0.8,<1.0.0",
  "numexpr >=2.8.4",
  "openpyxl >=3.1.2,<4.0.0",
  "xlrd >= 2.0.1",
  "odfpy",
  "pppybox[local]"
]

Two things are visible here. The file format support is broad, with openpyxl for xlsx, xlrd for the older xls format and odfpy for OpenDocument, so the local path can read spreadsheets in the formats people actually have. And the scientific stack is present, with scipy for numerics, scikit-learn and statsmodels for statistics, and the plotting pair for output.

The `mplfonts` dependency is the interesting one, since it is not a common requirement. It is there to provide fonts for matplotlib, which matters for a library that renders charts in a context where the default fonts may not be available or may not cover the characters needed.

The split between the core install and the local extra is a meaningful design decision rather than an accident. The core agent is small, and the analysis path is where the weight is, so a user who only wants the agent does not install a plotting stack.

What is missing from the documentation, and how the project is versioned

The README is honest about its own length, and the gaps are worth naming so you can plan around them.

There is no installation snippet. The README does not tell you the pip command, and it does not show a code example of the agent in use. The full documentation is said to be at the project site, and the packaging metadata points at the same site. So the repository README is a signpost rather than a manual, and the examples directory plus the hosted docs are where the real interface lives.

There is also no statement about model hosting, about which TableGPT2 checkpoint the agent expects, or about what a call actually looks like end to end. The TableGPT2 model card is the place to look for the model's own details, and the README points there too.

The version history is the other thing to note. The listed releases are v0.2.27 on 2025-03-05, v0.2.26 and v0.2.25 both on 2025-01-03, and the last push was on 2026-10-06. So the tagged releases are over a year older than the most recent commit, and the package version is dynamic, which means what is on PyPI and what is in the repository are not necessarily the same thing. The repository is not archived.

The project is Apache 2.0 licensed, and the README says it is distributed under the terms of the Apache 2.0 license with a link to the SPDX identifier. There is also a BibTeX citation block for the TableGPT2 paper, the arXiv identifier 2411.02059, and a request to cite the work if you find it helpful, which is the convention for a research artifact rather than a general library.

Editorial conclusion

Adopt tablegpt-agent when you want to run TableGPT2 as an agent rather than as a single completion, and you are comfortable with LangGraph as the orchestration layer and with pulling a model from Hugging Face. Do not adopt it for general dataframe analysis, since the package is a thin agent around one model family, and the local extra exists for that separate case. Verify first that the LangGraph version range in the packaging metadata, which is below 1.0.0, is compatible with the rest of your stack, since that pin is where breakage will happen first.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tablegpt/tablegpt-agent on GitHub