One engine, visual canvas or Python
In short
Agent Builder is Dynamiq's workflow engine: a drag-and-drop canvas for business teams and the open-source Python SDK for engineers, running on the same execution engine underneath. An agent is nodes on a graph, an LLM, tools, optional sub-agents and orchestration, wired between an Input and an Output node. Start from a blank canvas or from a prompt the generator turns into a first draft you refine.
What Agent Builder does
- One engine, two surfaces
- Build visually on the canvas or in the Python SDK; both produce the same workflow definition and deploy the same way.
- Generate from a prompt
- Describe the workflow in plain language and the generator drafts nodes and edges on the canvas for you to refine.
- Versions and rollback
- Every save is a new version. Deploy any saved version and roll back to an earlier one when you need to.
- Decision tables and rules
- Put eligibility checks, pricing grids and policy rules in tables and rule lists a domain expert can read and edit, with saved test cases that show what each rule covers.
- Judgment you can route on
- Ask yes or no, choice and score questions about a record and route on the answer, with an LLM, an agent or a calibrated judge service answering.
- Approvals on tool steps
- Pause a tool node for human sign-off before it runs, with fields a reviewer can edit and a message that shows exactly what will execute.
- Agentic memory
- Agents keep conversations by user and session, and long-term memory carries durable facts about each person into every new conversation.
- Agent tools
- Attach web search, databases, code execution, a knowledge base, MCP servers or sub-agents, and actions across 2,100+ app integrations, and the agent decides which to call.
One engine, two ways to build
Business teams build on the visual canvas: drag nodes from the palette, wire them with typed edges, and configure each one in an inspector panel. Engineers build the same graph in the open-source Python SDK, in git, with code review and their own CI. Both compile to the same workflow definition and the same execution engine, and a canvas workflow can be exported for engineers to run and extend with the SDK.
- Every workflow starts as Input and Output nodes; everything else goes between them
- Save creates a new version; only a saved version can be deployed or rolled back to
- The SDK's to_yaml_file and from_yaml_file read and write the workflow definition, and Export downloads a canvas workflow as a ZIP that runs anywhere the SDK runs
- Versioned prompt templates, tested in a playground, plug into LLM nodes and AI Coworker commands
- The dynamiq CLI manages projects, workflows, versions, apps and triggers from a terminal
Nodes
Logic
- Choice
- Rules
- Map
Agents
- Agent
- Graph Agent Orchestrator
Tools
- Action
- Web Search
- MCP Server
- Human Feedback
Validators
- PII Detector
- Prompt Injection Detector
Tools
Web Search
Jira, create issue
LLM
claude-sonnet-5
LLM
claude-sonnet-5
Role & Instructions
Classify each support ticket and file it in Jira with a priority.
A first draft from a prompt
Describe the workflow in plain language, such as review a loan package against credit policy and route exceptions to an underwriter, and the generator drafts the nodes, edges and prompts in a side panel. Accept the draft onto the canvas, then refine each node in the inspector: swap the model, attach tools and knowledge, add an approval step. Nothing is saved until you click Save, so a draft costs nothing to try.
- The generator drafts nodes, edges and prompts; you review each one before anything runs
- Each save becomes a new version you can deploy or roll back to
- Swap in your own Connections before testing, so the draft runs against your systems
- 1InputLoan package
- 2PII DetectorValidator
- 3Extract fieldsAgent
- 4Credit policyKnowledge Base Retriever
- 5ChoiceExceptions found?
- 6Underwriter reviewHuman Feedback
Decision nodes and approvals
A Choice node routes a workflow on deterministic conditions, no model involved: the first matching branch wins, and a built-in default branch catches everything else. For process steps that need real judgment, attach a Graph Orchestrator instead, so a manager agent routes only where you let it. Either pattern can feed an approval gate: enable execution approval on a tool node and the run pauses with a rendered message until a reviewer approves, optionally editing the exact fields that are about to be sent, or rejects with feedback the agent reads and acts on.
- Order Choice branches from most to least specific; the first true condition wins and skips the rest
- Approval requests arrive over the same WebSocket or Runs API stream your App already uses
- A rejected approval is not a dead end: its feedback flows back as an observation the agent can act on
- dti > 0.43Underwriter review
- flood_zone == nullRequest appraisal
- defaultApprove and file
Business rules your experts can read
Some decisions should never be left to a model. A Decision Table turns an eligibility check, a pricing grid or a scorecard into a step a credit or compliance lead can read and edit: typed inputs, a grid of rules, a hit policy for overlaps, and CSV import and export. A Rules node checks a record, such as a claim with its policy or an invoice with its purchase order and receipt, and reports one finding per rule with a severity and a message. Where a question needs judgment, the Judgement node answers yes or no, choice and score questions with a calibrated confidence the workflow routes on, and sends low-confidence cases to a person.
- Saved test cases re-run after every change and show which rules they cover
- Rules carry severities and effective dates, so a policy change has a start date
- A judge can be an LLM, an agent that looks things up first, or a calibrated judge service
Agentic memory
Turn on memory for an Agent node and it keeps each conversation, scoped by user and session, and replays the most recent messages, the most relevant ones, or both, at the start of the next run. Long-term memory goes further: the agent gets tools to remember and recall durable facts about a user across every session, and decides during its own loop when a fact is worth keeping. When it hears the same thing said differently, it updates the existing fact instead of storing a duplicate.
- Session memory scoped by user_id and session_id, with recent, relevant or both retrieval
- Long-term facts the agent saves, recalls and updates itself; in AI Coworker, people see and correct them on a Memory page
- Sub-agents keep their own history, so a delegate never reads another agent's memory
Hi, I wanted to ask about my home loan.
Welcome back. Your renewal is due in March; I can email you the options, since you prefer email.
Coming next
In development now and shipping over the coming weeks. Ask us for early access.
Durable waits and error paths
A Delay node that waits hours or days, runs that resume without repeating earlier steps, and error edges that route a failure to its own handler.
Where teams use it
- Document review and underwritingRead loan files, underwriting submissions and contracts, check them against your rules, and flag exceptions for a reviewer instead of a rubber stamp.
- KYC and customer onboardingRead onboarding documents, gather screening results, apply your risk rules and prepare the file, with an analyst approving every new account.
- Accounts payable and invoicesRead invoices, match them to purchase orders and receipts, route exceptions and prepare payments, with approval before anything posts or pays.
- Back-office and finance operationsReconcile accounts, clear payment exceptions, prepare dispute cases and draft reports across the systems you already run, with approval before anything commits.
Works with
- Apps and deploymentsDeploy a saved workflow version as an App with its own hostname. Call it over HTTP, embed a chat widget, or trigger it on a schedule or an event.
- IntegrationsConnect a workflow to 2,100+ app integrations, or point it at your own databases, warehouses and MCP servers.
- Guardrails and approvalsDetect PII and prompt injection before a model sees them, enforce content policies, and pause tool steps for a person to approve.
Questions and answers
What is the difference between the canvas and the Python SDK?
They are two surfaces over the same execution engine. The canvas is for building visually and iterating with non-engineers in the room; the open-source Python SDK is for defining workflows in code, in git, with your own review process. A workflow moves between them through the same YAML definition.
Can I start from a description instead of a blank canvas?
Yes. Describe the workflow in plain language and the generator drafts nodes, edges and prompts for you to review on the canvas. Nothing is saved until you choose to save it.
Can an agent call other agents?
Yes. Attaching one Agent to another as a tool creates a sub-agent, so a manager can delegate a task and either combine the result or return the sub-agent's answer directly. A factory-built sub-agent gets a fresh instance per call, so a coordinator can fan out several in parallel.
How do approvals fit into a workflow?
Turn on execution approval for any tool node and the run pauses before that node executes, showing a reviewer a rendered message and, optionally, editable fields. Approve and the node runs with whatever the reviewer confirmed; reject with feedback and the agent reads that feedback as its next observation.
Does a workflow need a data science team to build?
No. The canvas is built for a business team to design an agent by dragging and connecting nodes, with a prompt-to-workflow generator to draft the first version. Engineers extend the same workflows in Python when the logic needs custom code.
See an agent on your own workflow.
Bring a process and its documents. Our engineers will show you how Dynamiq runs it, in your environment or ours.