Prove your Dify 1.18 agent can route real work

You are deciding whether an agent can choose the branch that handles a real request. The answer should come from a repeatable test, not from a demo. Dify 1.18.0 lets agent nodes choose workflow branches and supports packaging an app in a single file. It also introduces agent-driven workflow routing, portable .ifpkg app bundles, drill-down visibility for nested workflow runs, and an opt-in Agent Knowledge Base paired with CLI tooling.

A router you can't audit can't be trusted

In Anthropic's routing pattern, an incoming request is categorized and then sent to a specialized follow-up task. When the classifier is an agent, the branch choice is the audit target. If the app can't show you which path it took, you're trusting a black box with your queue. Domino's supervisor routing pattern is strongest with distinct specializations and clear classification signals, and it can produce routing errors when requests span multiple domains. The test set needs one clean case, one edge case, and one request that spans two domains.

Run six checks before trusting the router

Run these in a staging workspace, in this order. The upgrade comes first because a broken migration hides every later check. Auth comes second because an open sandbox can mask a missing secret. Route choice, portability, nested visibility, and CLI control follow the same logic: each exposes a different failure mode. Each check should take about a minute in a healthy environment; a slow check is a clue, not a delay.

• Upgrade safety: Confirm the 1.17.1 to 1.18.0 path applies 22 schema/data migration revisions plus two migration-head merges, ending at b9d3f7a5c102. Installations still running Weaviate 1.27 must finish the 1.17.1 staged Weaviate upgrade before adopting Dify 1.18.0.
• Auth: Local Agent sandboxes in Dify 1.18.0 require a configured authentication secret, the token must be non-empty, and the sandbox uses a new Agent Backend run protocol. Confirm each sandbox has that secret; a missing token should fail the run, not silently fall back to an open sandbox.
• Route choice: Output Routes make the agent-selected workflow branch visible through a read-only switch output. Run a known input and confirm the switch output names the branch; a blank output is not auditable.
• Package portability: Dify 1.18.0 .ifpkg packages move Workflow and Chatflow apps together with inline Agents, Skills, and files, and the destination workspace recreates those resources with remapped references. Export a Workflow or Chatflow as an .ifpkg bundle, import it into a second workspace, and verify one inline reference remaps.
• Nested-run visibility: Dify 1.18.0 provides run-history access to a Workflow Tool invocation so users can inspect the individual steps of the child workflow. From run history, open the Workflow Tool call and step through the child workflow. Nested usage and step totals are not guaranteed to be exact after a pause or stop.
• CLI control: Use the CLI to reach the same app state from outside the UI. An unreachable state is an incomplete control surface.

Repeat the input until the branch is stable

One successful run is only a sample. Run the same input enough times to see whether the branch is stable. A router that flips between two branches on identical input is not ready for work that needs an audit trail. Keep the chosen branch next to the input that produced it. Record the branch, the timestamp, and the person who ran it, and store the input, package result, nested history, and control response where the next operator can rerun it.

The environment is where trust breaks

For source-based Dify 1.18.0 deployments, the API runtime must be Python 3.13, the frontend toolchain must use Node.js 24.22.1 or a newer 24.x release, and pnpm must be 12.10.1. A migration that applies cleanly in staging but not in production is a scheduling problem, not a feature. Pin the runtime versions in the test record. If the build environment drifts, stop and compare the versions before blaming the model.