DynaSaur: a Python-writing LLM agent that builds its own action library

What DynaSaur solves, and for whom

Most LLM agent frameworks hand the model a fixed menu: a set of tools, each with a schema, and the model picks one per step. When the menu is missing the right tool, or a tool fails on an edge case the schema did not anticipate, the run stalls. DynaSaur takes a different position. The README describes it as a framework that "uses a programming language as a universal representation of its actions", and states that at each step the agent generates a Python snippet that either calls on existing actions or creates new ones when the current action set is insufficient. New actions can be written from scratch or composed from actions already in the library, so the library grows across tasks.

The intended audience is narrow and readable from the repository itself: this is a research codebase accompanying a COLM 2025 paper, with a single top-level entry point (dynasaur.py) and modules named actions.py, agents.py, env.py, prompts.py and utils.py. It is not packaged as a library, and nothing in the README describes an importable API. If you want an agent you can pip install and embed in a product, this is not that. If you want to reproduce or extend a published method where action creation is part of the loop, the code is laid out for exactly that.

How the action library actually grows

The mechanism is best understood as a loop over three moving parts, all visible in the file names. prompts.py holds the instructions that ask the model for a Python snippet. actions.py holds the action set and the retrieval that decides which existing actions are shown to the model. agents.py and env.py run the snippet and carry state between steps. The README adds that action retrieval uses embeddings, which is why the .env template requires a separate set of embedding credentials rather than reusing the main model keys.

The consequence of this design is that every solved task is a potential contribution to the next one. A failure on an unforeseen edge case is not necessarily terminal, because the agent can define a new action instead of retrying the same call. The README states that DynaSaur "exhibits remarkable versatility, recovering automatically when no relevant actions are available or when existing actions fail". That is the claim to test, not to assume. The cost is that the action library is also the attack surface and the debugging surface: a snippet the model wrote three tasks ago is now part of the environment for every later task, and the README does not describe any review, sandboxing or pruning step for it. Treat the growing library as state you own.

Installing DynaSaur and running the agent once

The README gives three numbered installation steps, and they are all required before the entry point will do anything useful. First, create a .env file in the project root. The template below is copied from the README; the main keys and the embedding keys are both marked required, and the user-defined action keys are optional.

# Required: Main keys for the agent
AZURE_API_KEY=""
AZURE_ENDPOINT=""
AZURE_API_VERSION=""

# Required: Keys for embeddings used in action retrieval
EMBED_MODEL_TYPE="AzureOpenAI"
AZURE_EMBED_MODEL_NAME=""
AZURE_EMBED_API_KEY=""
AZURE_EMBED_ENDPOINT=""
AZURE_EMBED_API_VERSION=""

Note that EMBED_MODEL_TYPE is set to AzureOpenAI in the template, and that the optional block covers SERPAPI_API_KEY plus the AZURE_GPT4V_* variables used by user-defined actions. If you leave the optional block empty, those actions are simply unavailable.

Second, the agent needs the GAIA files. The README asks for a Hugging Face access token with write permissions before cloning the dataset repository, then gives these commands:

huggingface-cli login
mkdir data
git clone https://huggingface.co/datasets/gaia-benchmark/GAIA
mv GAIA/2023 data/gaia/
rm -rf GAIA

The move places the 2023 split at data/gaia/, which is the path the rest of the code expects. Third, create the environment and install pinned dependencies:

conda create -n dynasaur python==3.12
conda activate dynasaur
pip install -r requirements.txt

The requirements.txt pins Python packages exactly, including langchain==0.2.6, openai==1.40.0 and chromadb==0.5.23, so the install is reproducible but brittle against newer releases of those packages. With the environment active and the keys in place, the README's only run command is:

python dynasaur.py

The README does not document what arguments dynasaur.py accepts, what it prints, or where it writes results, so read the script before assuming a CLI. There are no releases to pin against; the repository is cloned at whatever main currently is.

Where DynaSaur is the wrong tool

The most concrete limitation is stated by the project itself: the TODO list contains an unchecked item, "Add support for the OpenAI API". As shipped, the agent path is Azure-based, and the embedding path in the template is AzureOpenAI. If your access is an OpenAI key rather than an Azure deployment, the documented configuration does not cover you.

Three more constraints follow from the repository layout rather than from any stated policy. There is no packaging metadata at the top level (no pyproject.toml or setup.py among the entries), so there is no supported way to depend on DynaSaur from another project. There is no test directory, so the only correctness signal is running the agent on GAIA and reading the output. And the licence file exists as LICENSE.md, but the repository metadata reports NOASSERTION, meaning no standard licence identifier was detected; if you need to know whether your use is permitted, that is a question for your own counsel, not something the README answers.

A subtler failure mode is evaluation drift. The README states that as of its writing DynaSaur "holds the top position on the GAIA benchmark" and is the leading non-ensemble method. That statement describes a moment, not a property of the code you clone today, and the README does not describe a reproduction script that would let you confirm the number on your own hardware and keys.

How it differs from a fixed-tool agent framework

The obvious comparison is with tool-calling agent frameworks such as LangChain agents, which DynaSaur already depends on at pinned versions. In a conventional LangChain agent you register a list of tools with schemas, and the model's job is selection and argument filling. DynaSaur keeps the selection idea but adds synthesis: the model's output is a Python snippet, and that snippet can define a function that did not exist before, which then becomes retrievable for later steps. The difference in practice is where failure lands. In a fixed-tool agent, a missing capability is a dead end you fix in code. In DynaSaur, it is a prompt for the model to write the capability, which is more flexible and considerably harder to audit.

A second contrast is with code-generation agents that write and execute programs in a scratch workspace. Those typically treat generated code as disposable. DynaSaur's README is explicit that new actions expand "a reusable library for future tasks", so generated code persists as environment. That persistence is the whole point of the method and also the reason a research setup and a production setup diverge: nothing in the README describes how a bad action is removed.

Maintenance, dependencies and licence

The repository is not archived, and the last push was on 2026-08-05. No releases were retrieved, so there is no version to upgrade to or roll back to; upgrading means pulling main and re-reading the diff. The dependency pins are the real upgrade cost. langchain, langchain-core, langchain-community and langchain-openai are all pinned to 0.2.x and 0.1.x lines, openai is pinned to 1.40.0, and chromadb to 0.5.23. Moving any one of them means moving the set, and the README gives no compatibility matrix. A conda environment at python==3.12 is the documented baseline.

The licence situation deserves a plain statement: LICENSE.md is present in the repository, but the project metadata does not declare a recognised licence identifier. The README's citation block asks that you cite the arXiv paper and the COLM 2025 proceedings entry if you find the work useful, which is a request about attribution, not a grant of rights. Do not read the citation block as a licence.

Editorial conclusion

Adopt DynaSaur if you are evaluating research agents on GAIA-style tasks and you already have Azure OpenAI access, since the repository's .env template and dynasaur.py entry point assume it. Do not adopt it if you need a supported product with versioned releases, an OpenAI-only setup, or a documented rollback story: the README lists adding OpenAI API support as an open TODO, no releases were retrieved, and the licence file is present but the licence identifier is not declared. Verify first that your Azure endpoint, API version and embedding deployment work with the required keys, that you have a Hugging Face token with write permissions for the GAIA clone, and that you are comfortable running a research script whose only documented command is python dynasaur.py.

Frequently asked questions

Official sources

1. adobe-research/dynasaur on GitHub
2. Issues
3. README