Dynamiq
A Python framework for orchestrating agents, LLM workflows, and RAG pipelines.
The files show explicit tool lists, loop limits, workflow dependencies, credential injection restricted to internal PRs or controlled labeled jobs, and a confidential vulnerability-reporting channel. This adequately supports ordinary data-flow, secret-handling, and dependency-governance expectations. Deductions apply because there is no framework-wide least-privilege or per-action authorization model, confirmation appears only in an illustrative email interaction, external calls and transmitted data lack a general disclosure or approval safeguard, and no rollback or compensating-action mechanism is documented. Repository metadata, documentation, licensing, and the corporate copyright notice provide attribution, but publisher identity is not independently verified, so attribution is not full-score. No red-line evidence is present.
The README, package metadata, CI, and test fixtures broadly agree on the Python framework, LLM, agent, RAG, and integration capabilities. Dependencies are usually range-bounded, Python 3.10–3.13 is declared, and containerized CI includes isolated and credentialed integration paths. Deductions reflect the exceptionally broad default dependency set and reliance on many external services, plus example inconsistencies such as the missing asyncio import and an email flow that reports sending without implementing delivery. Apart from maximum-loop behavior, failure categories, diagnostic messages, and recovery guidance are largely absent.
The evidence thoroughly covers translation, asynchronous ReAct, parallel and sequential agents, multi-agent delegation, RAG, conversational memory, and graph orchestration. Explicit tools, roles, dependencies, transformers, routers, inference modes, and loop limits provide useful capability and trigger controls. Deductions apply because there is no unified permission or capability-boundary model, LLM-directed delegation still depends on prompt conventions, and prerequisites for external credentials, system PDF/graphical libraries, resources, and deployment variants are incomplete.
The README has clear installation, documentation, examples, contribution, and licensing sections; package name, CLI, version 0.60.1, Python range, and project links are supported by metadata. The extensive readable examples justify full credit for examples despite the absence of a FAQ, and the complete Apache-2.0 text matches the declared license, justifying full license credit. Deductions apply because known limitations are only incidental, the release-page link is not a repository changelog, and maintenance is represented by team and security addresses rather than named responsibility; publisher identity also remains unverified.
Examples demonstrate consumable node output, agent content, node-keyed workflow results, and RAG indexing and retrieval paths. DAG composition, parallel execution, delegation, memory, and multiple backends provide substantial marginal value over a single LLM call. Deductions apply because output contracts, error results, and persistent side effects are not documented systematically. Although models, token limits, and loop limits are configurable, there is little guidance on monetary cost, latency, dependency weight, resource usage, or when the framework's overhead is unjustified.
Core identity, version, Python support, license, CI paths, and principal scenarios can be traced across the README, pyproject, workflows, and test fixtures, providing adequate static corroboration. Deductions apply because no execution evidence or independent validation is supplied, and the test excerpt consists mainly of shared fixtures rather than concrete behavioral assertions. Promotional or broad claims such as “all-in-one” and automatic parallelism are not clearly separated from demonstrated facts and inference; the email example can also imply a real send where only status text is printed.
- This is a static review of only the supplied revision files; no code, tests, or network integrations were executed.
- Agents can reach E2B, search providers, databases, vector stores, and cloud models. Deployers should add tool allowlists, least-privilege credentials, outbound-data disclosure, and confirmation for consequential actions.
- The README passes API-key placeholders directly while CI creates .env files containing real secrets. Verify log redaction, file cleanup, key rotation, and third-party retention policies.
- The default dependency surface is very large and includes many fast-moving service clients. Produce a lock inventory and SBOM, scan it for vulnerabilities, and consider feature-based optional dependency groups before adoption.
- The graph-orchestration email example does not send an email; it only prints a sent status. Do not treat it as evidence of external delivery, confirmation enforcement, or effect verification.
- No general rollback or compensation facility is shown. Add application-level idempotency, auditing, and recovery for workflows that write to vector stores, databases, or other stateful systems.
What does this agent do, and when should you use it?
Dynamiq is a Python orchestration framework for agent applications, LLM calls, and retrieval-augmented generation. Its documented building blocks include Workflow, Flow, Agent, LLM and tool nodes, Memory, and a GraphOrchestrator for conditional and iterative execution. Workflows connect node inputs and outputs through dependencies and InputTransformer mappings, running independent nodes in parallel where possible or enforcing sequential execution. The examples integrate OpenAI models, E2B code execution, ScaleSerp search, Pinecone vector storage, and a PDF conversion, embedding, and retrieval pipeline. It runs as a Python library and exposes structured node results; the supplied material does not document a hosted service, container deployment, or production operations layer.
Applications configure external services through connection objects such as OpenAIConnection, then execute OpenAI, Agent, and processing nodes. Workflow and Flow arrange nodes as a DAG; depends_on, NodeDependency, inputs, and InputTransformer define ordering and data transfer, while independent nodes can run in parallel. An Agent can invoke E2BInterpreterTool, ScaleSerpTool, or other Agent instances, enabling a manager agent to delegate research and writing. For indexing, PyPDFConverter reads PDFs, DocumentSplitter divides their contents, OpenAIDocumentEmbedder creates vectors, and PineconeDocumentWriter stores them; retrieval uses OpenAITextEmbedder, PineconeDocumentRetriever, and an OpenAI answer node. Memory with the InMemory backend retains conversation history, while GraphOrchestrator and GraphAgentManager use states, edges, and conditional routing to implement feedback loops. Synchronous calls return from run, asynchronous agents use await agent.run, and callers read generated content from result.output.
- Python developers assembling prompt templates, OpenAI model calls, and application logic into reusable LLM workflows.
- Research or content teams delegating search and writing to separate agents in parallel before a manager composes an executive brief.
- Knowledge-base teams converting local PDFs, splitting their contents, generating embeddings, and loading an existing Pinecone index.
- Application developers retrieving relevant Pinecone documents and passing that context to a model to answer user questions.
- Chatbot developers retaining per-user and per-session conversation history with Memory and the InMemory backend.
- Teams requiring human review loops for drafts, using GraphOrchestrator to gather feedback and either revise, send, or cancel.
What are this agent's strengths and limitations?
- One node-and-workflow API covers direct LLM flows, sequential and parallel agents, RAG pipelines, and graph orchestration.
- Explicit dependencies, output mappings, and InputTransformer reduce the need to manually shuttle results between workflow steps.
- GraphOrchestrator supports states, regular and conditional edges, loops, and explicit termination for review-driven processes.
- The examples provide both sides of a RAG system: PDF-to-Pinecone indexing and query-to-retrieval-to-answer generation.
- Every documented model and embedding example uses OpenAI, with no supplied evidence for switching to another model provider.
- The showcased code execution, web search, and vector retrieval features depend on external E2B, ScaleSerp, and Pinecone services and credentials.
- The Pinecone workflow assumes that an index already exists; index creation is not included in the supplied setup instructions.
- The source does not document container deployment, hosted execution, persistent memory, monitoring, retries, or production recovery behavior.
How do you install or deploy this agent?
Dynamiq requires Python 3.10 or newer. Install the published package with:
pip install dynamiqAlternatively, clone the repository and synchronize its dependencies:
git clone https://github.com/dynamiq-ai/dynamiq.git
cd dynamiq
uv syncBefore running an example, supply the credentials it uses. The basic LLM examples require an OpenAI API key; the E2B, ScaleSerp, and Pinecone examples additionally require keys for those services.
How do you use this agent?
A minimal invocation creates a connection and model node, then calls run:
from dynamiq.nodes.llms.openai import OpenAI
from dynamiq.connections import OpenAI as OpenAIConnection
from dynamiq.prompts import Prompt, Messageprompt = 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)For multi-node applications, create a Workflow, add Agent or processing nodes to wf.flow, and connect them with depends_on, inputs, or InputTransformer before calling wf.run(input_data={...}). Asynchronous agents use await agent.run(...) and must be invoked inside a Python asynchronous event loop.