Dynamiq: a Python orchestration framework for LLM agents and RAG pipelines

What Dynamiq is for, and the problem it removes

Dynamiq describes itself as an orchestration framework for agentic AI and LLM applications, and the repository topics list agents, generative-ai, gpt, llm, llmops and rag. The problem it addresses is assembly. A working LLM feature usually needs a model call, a prompt template, a retrieval step, at least one tool, and some control over how those pieces run relative to each other. Written by hand, that glue is where most of the bugs live: retries, input mapping between steps, and the question of which step runs when.

Dynamiq answers that with named objects. A Prompt holds messages, an LLM node holds a connection and a model, a tool is a node, and an Agent composes an LLM with a list of tools. The README's first example is a translation call built from exactly these parts, which shows the intended unit of work: small, inspectable objects rather than a single opaque chain.

The audience is Python developers building agent or RAG features inside an existing application. It is not aimed at people who want to describe an agent in a web form. Everything in the README is code, and the repository ships an examples directory with subfolders for cli, components, human_in_the_loop, mocking and use_cases, which suggests the project expects users to read and modify source rather than configure a hosted product.

Nodes, connections and flows: how a Dynamiq pipeline is put together

The architecture visible in the README is a graph of nodes. Each node has an id, and the id is what you use to read results back out. Connections are separate objects that carry credentials, so the same OpenAI connection can back several LLM nodes. Prompts are their own type, built from Message objects with a role and a content string, and the content is a Jinja template: the README's example uses the placeholder {{ text }} and then passes input_data={"text": "Hola Mundo!"} to the run call.

Agents are nodes too. An Agent takes an llm, a tools list, a role string and a max_loops integer. That max_loops value is the loop budget for the reasoning cycle, so it is the main lever against an agent that keeps calling tools without converging.

Workflow is the container. The README shows wf.flow.add_nodes(first_agent) followed by wf.flow.add_nodes(second_agent), and notes that the Workflow class handles running the agents in parallel where possible. The same document gives an equivalent construction, Workflow(flow=Flow(nodes=[agent_first, agent_second])), so Flow is the underlying object and Workflow is the convenience wrapper. Sequential execution is expressed with InputTransformer and NodeDependency imported from dynamiq.nodes.node, which is how one node's output is mapped into the next node's input. That is the whole data flow model: nodes produce outputs, transformers move values between them, and the flow decides order.

Installing Dynamiq and running a first LLM node

The README gives two installation paths. The package path is a single pip command. The source path clones the repository and uses uv, which matches the Dockerfile, where uv is installed into an isolated virtual environment and uv sync --frozen --no-install-project is run against the committed uv.lock.

pip install dynamiq

For a source checkout instead:

git clone https://github.com/dynamiq-ai/dynamiq.git
cd dynamiq
uv sync

Python 3.10 or newer is required. The pyproject file narrows that to >=3.10,<3.14, so a 3.14 interpreter will not satisfy the constraint. The Dockerfile builds on python:3.13.10-slim, which is the version the project itself appears to target.

A first real use is the translation example from the README. It defines a prompt template, wraps it in a Prompt, builds an OpenAI node with a connection, a model name, a temperature and a token cap, then calls run with the template variable.

from dynamiq.nodes.llms.openai import OpenAI
from dynamiq.connections import OpenAI as OpenAIConnection
from dynamiq.prompts import Prompt, Message

prompt = Prompt(messages=[Message(content="Translate the following text into English: {{ text }}", role="user")])

llm = OpenAI(
    id="openai",
    connection=OpenAIConnection(api_key="OPENAI_API_KEY"),
    model="gpt-4o",
    temperature=0.3,
    max_tokens=1000,
    prompt=prompt,
)

result = llm.run(input_data={"text": "Hola Mundo!"})
print(result.output)

What you should see is the translated string printed to standard output. Note that the README passes the literal string "OPENAI_API_KEY" as the api_key argument in this snippet. In a real project you would read that from the environment; the repository ships a .env.example listing OPENAI_API_KEY alongside keys for Pinecone, Anthropic, Weaviate, Qdrant, Milvus, Gemini, Cohere, AWS and many others, which is the practical place to start when wiring credentials.

Agents, sandboxes and the tools Dynamiq ships with

The agent example in the README is a ReAct agent with asynchronous execution. It builds an E2BInterpreterTool from an E2B connection, attaches it to an Agent with a role of "Senior Data Scientist" and max_loops=10, and runs it with await agent.run(...). The prompt is arithmetic: add the first ten numbers and say whether the result is prime. The point of the example is that the model writes and executes code in a sandbox rather than doing the arithmetic in its head.

The same passage states that code sandboxes are also available through Daytona as DaytonaInterpreterTool and through AWS Bedrock AgentCore as BedrockAgentCoreInterpreterTool, the latter using the standard AWS connection. That is a meaningful design choice: sandbox execution is abstracted behind a tool interface, so the same agent definition can point at E2B, Daytona or Bedrock AgentCore depending on where your credentials and compliance requirements sit. The dependency list includes e2b-code-interpreter, which is the concrete package behind the E2B path.

Tool selection is where Dynamiq's breadth becomes a cost as well as a benefit. The pyproject dependencies include clients for Pinecone, Chroma, Weaviate, Qdrant, Milvus, pgvector, Elasticsearch, Snowflake and MySQL, alongside pdf2image, pypdf, python-pptx and pillow for document handling, and evaluation libraries such as sacrebleu and rouge-score. A plain pip install dynamiq pulls that set. If you only need one vector store, you are still resolving the rest.

Where Dynamiq is the wrong tool

The README is honest about being a framework and silent about being a product. There is no mention of deployment, hosting, a control plane, or rollback of a running agent. If your requirement is a managed runtime with a dashboard and audit trail, this repository does not describe one, and the documentation link points to a docs site rather than an operations guide.

The dependency surface is the second constraint. Pinning is aggressive throughout pyproject, with most entries using both a lower and an upper bound. That protects you from breaking changes but also means Dynamiq can hold back a shared dependency in a larger application. A team already pinned to a different major version of pydantic, redis or openai may find the resolver refuses to reconcile the two sets, and the fix is not documented in the README.

Third, the examples assume credentials for external services. The E2B tool needs an E2B key, the vector store examples need a hosted endpoint, and the .env.example is long. There is a mocking directory under examples, which suggests the project has thought about testing without live credentials, but the README does not explain it. For a quick local prototype with no third-party accounts, a thinner library will get you to a first result faster.

Finally, the README does not state a supported Python version policy beyond the pyproject range, nor an upgrade path between the frequent releases. Versions v0.61.0, v0.62.0 and v0.63.0 landed within roughly three weeks of each other, and the repository's pyproject version is 0.64.0. That cadence is worth knowing before you pin a version in a long-lived service.

Dynamiq compared with LangChain and LlamaIndex

The closest alternatives are LangChain and LlamaIndex, and the difference is in how much structure is imposed. LangChain's centre of gravity is the chain and a very large integration catalogue; you compose runnables and the framework supplies a broad set of adapters. LlamaIndex is built around indexing and querying documents, with retrieval as the primary abstraction and agents layered on top.

Dynamiq sits between them and leans toward explicit graph construction. Nodes have ids, connections are separate objects from the nodes that use them, and a Workflow is a container you add nodes to. The README's parallel-agent example makes this concrete: two Agent objects are added to one flow and the framework runs them in parallel where possible, with results keyed by node id in result.output. Sequential wiring is explicit too, through InputTransformer and NodeDependency. In LangChain you would express the same shapes with runnables and composition operators; in Dynamiq you name the nodes and map the inputs.

That is a real trade-off rather than a clear win. Explicit nodes are easier to reason about and to test in isolation, and the human_in_the_loop examples folder suggests the project treats interruption as a first-class concern. The cost is that Dynamiq's integration catalogue is narrower than LangChain's, and its retrieval-specific abstractions are less developed than LlamaIndex's. The pyproject dependency list shows the vector stores it supports directly, and if yours is not among them, you are writing an adapter.

Licence, maintenance and what an upgrade costs

Dynamiq is licensed under Apache-2.0, stated in both the README badge and the license field of pyproject.toml. That is a permissive licence with an explicit patent grant, and it does not impose copyleft obligations on your application. It also means the project carries no commercial support commitment in the repository itself. This is a description of the licence text, not legal advice; check the LICENSE file for the terms that apply to you.

The repository is not archived, and the last push was on 2026-09-09. Releases are frequent: v0.61.0 on 2026-08-18, v0.62.0 on 2026-08-25 and v0.63.0 on 2026-09-08. The pyproject version is 0.64.0, ahead of the most recent listed release tag, which is normal for a main branch between tags.

Upgrade cost is dominated by the dependency pins rather than by Dynamiq's own API. Because the project constrains upper bounds on pydantic, redis, openai, boto3 and the vector store clients, a Dynamiq upgrade can force a coordinated upgrade of those packages in your application. The repository includes a Makefile and a docker-compose file with services for tests, coverage runs and integration tests that require credentials, plus a local Neo4j 5 community service for knowledge-graph tests. That gives you a way to run the project's own suite before adopting a new version, though the README does not document a release or rollback procedure for downstream users.

Editorial conclusion

Adopt Dynamiq if your team writes Python and wants agents, tools and retrieval wired as explicit nodes rather than hidden behind a hosted UI. Do not adopt it if you need a no-code builder or a documented operational story: the README says nothing about deployment, rollback or version pinning beyond the release tags. Before committing, verify that the provider connections you need exist in dynamiq.connections, that the tool you plan to use is available as a node, and that the pinned dependency range in pyproject.toml resolves against your existing environment.

Frequently asked questions

Official sources

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