GitHub Repo
Dify 1.18.0 Adds Agent Branch Routing; Agent Runtime Protocol Upgrade Requires Synchronized Deployment
Released on October 23, Dify 1.18.0 lets Agents select workflow branches when completing tasks and expands nested workflow tracing. The release also changes the Agent runtime protocol, requiring the backend and runtime to be upgraded together; older versions cannot read session snapshots saved by the new version.

Dify released version 1.18.0 on October 23, bringing Agent decisions into workflow branch control. Developers can enable Output Routes on Agent v2 nodes and set selection conditions for different exits, allowing an Agent to decide what happens next after completing a task—for example, replying directly or handing the task to another specialized Agent. Release announcement
This feature combines task handling and branch selection in a single Agent call. According to the merged implementation notes, routing requires at least two branches. The system creates the required switch string output, uses fixed route IDs as the allowed values, and passes the selected exit to the workflow engine. switch is a read-only system output, and route conditions are preserved when workflows are published, copied, or serialized to DSL. This lets downstream nodes run based on an explicit exit, reducing the need to parse natural-language responses separately. Routing implementation notes
Routing has compatibility limitations: when enabled, a node can stop on an error or follow a failure branch, but it cannot be combined with node-level default-value error handling. Standard text output from Agent v2 nodes now supports streaming; structured results, routing results, and nodes that use default-value error handling still use buffered output. The official documentation also notes that the new Agent node is still in Beta and that each node has its own sandbox. File and tool installation state is not automatically passed between nodes, so results must be handed off through declared outputs. Agent documentation
Deployment teams should pay particular attention to the runtime protocol change. The new /runs endpoint accepts composition v2 and rejects v1. Existing session snapshots are converted when read, and after they are saved again, older runtimes can no longer read them. Therefore, the API, worker, Agent Backend, and runtime image must be upgraded together. Programs that connect directly to the backend must also update their request format. The local sandbox now requires a non-empty authentication token. Upgrade guide
For operations teams, validation should cover branch selection, failure exits, and recovery of existing sessions. Although the new version lets users inspect nested workflows in greater detail in the interface, the official documentation cautions that nested usage and step counts after a pause or stop may only be approximate. Cost assessments and trace completeness should therefore be checked against actual workloads.