Visible agent runtime
Dify carries the agent surface, workflow packaging, app templates, and operator-facing experience.
Dify + MCP Control Plane
Dify is the surface. MCP is the boundary. Policy OS is the operating rule.
The fastest path to serious Dify adoption is not another generic chatbot. It is a visible Dify app with scoped MCP tools, repo-owned manifests, eval gates, and an approval layer the operator can inspect.
Layer Map
Each layer has a job.
Tool and resource boundary
MCP server cards define what the agent can see, call, and describe without burying access in prompt text.
Approval and evidence layer
Policy OS decides what can run automatically, what needs approval, and what stops with a reason.
Build Order
Make the control plane inspectable before it becomes powerful.
A Dify app becomes production-worthy when the workflow, tool boundary, approval behavior, and evidence model are explicit enough for another operator to review.
- Inventory the source systems, workflow owner, and approval authority.
- Create or confirm the MCP server card and tool scope.
- Package the Dify agent or workflow with a repo-owned manifest and DSL snapshot.
- Add smoke checks and eval gates for expected tool use, forbidden tool use, and secret refusal.
- Publish only sanitized trust evidence and keep raw traces private.
Who It Serves
The same architecture supports three routes to Dify adoption.
Builder adoption
Use Dify to package the agent and MCP to expose the narrow tools needed for one useful workflow.
Operator governance
Use Policy OS to make approval states, blocked states, runbooks, and evidence visible before scale.
Agency packaging
Turn repeatable workflows into Dify templates or plugin candidates after sanitizing setup and proof.
Next Step
Book Mapping SessionMap one Dify workflow with the boundary attached.
Bring the workflow, systems, and approval owner. The first output is the Dify surface, MCP scope, eval gate, and policy state map.