Tue, Sep 01, 2026 • Article
DeerFlow skills, on the route external skills already take
We are adding support for skills packaged the way ByteDance's DeerFlow packages them. Coming to every edition, through the path external skills already use — and with the trust boundary that path already has.
DeerFlow is ByteDance’s open-source agent harness, MIT-licensed and built on LangGraph. It runs a lead agent that spawns sub-agents, keeps memory and sandboxes, talks to MCP servers, and reaches people through half a dozen messaging channels. Its extensibility mechanism is a skill: a Markdown file with a declared name, a described workflow, and references to the resources it needs, loaded only when the task calls for it.
That last part is the part we are adding support for. Skills packaged the DeerFlow way will install in AGENTEXA, in every edition, coming soon.
Why skills and not the rest of it
AGENTEXA already has a route for skills that come from outside. An author asks for one in conversation, and if their role permits it, the agent installs it. Installation records where the skill came from, which version, and its checksum. The right to install belongs to the person, decided by their role — it is not a property of the agent’s level, and an agent cannot grant it to itself.
DeerFlow’s skills fit that route almost exactly, because they are the same shape: a written procedure the model reads when it needs it, not a binary that has to be trusted to run. Supporting them means teaching our installer one more package layout — not adopting somebody else’s runtime.
What this does not mean
This is worth being specific about, because “supports DeerFlow” could reasonably be read three ways, and only one of them is what we are doing.
We are not running DeerFlow beside your platform. No lead-agent graph, no LangGraph runtime, no second web interface, no second set of messaging channels. Your agents stay your agents.
We are not adopting its sandboxes. DeerFlow can execute code in Docker containers or Kubernetes pods it provisions. Ours is a different execution model, and mixing the two would mean two answers to the question of where your data is allowed to go.
Its skills do not enter the trusted zone. A skill that came from outside is not an authored instruction. It carries the trust label of where it came from, and it cannot change instructions, capability grants, tool lists, effect classification, approval policy or delivery addresses. The rules that constrain untrusted content constrain it too. MCP servers and integrations are unaffected by any of this: they still come only from the catalogue an administrator maintains.
Installing one is a decision with reach. If an agent carrying an external skill is opened to a group, the skill works for that whole group. That is true of every external skill today, and it will be true of these. It is named here rather than discovered later.
Why every edition, and not the expensive one
Because the mechanism it rides on is base delivery. Installing an external skill by role is part of every installation, and putting a package format behind an edition boundary would be an arbitrary line drawn through something that is already there. Editions differ by what is delivered — industry packs, evaluation, audit evidence, directory masking — not by which file layouts the installer can read.
What is still open
We are not putting a date on this. The remaining work is in the installer and in how a DeerFlow skill’s declared tool policy maps onto our capability grants, and that mapping is the part that has to be right rather than fast. When it ships, it ships in a release note, not in a countdown.