# DeepSeek Harness (DSH) EXPLAINED | Everything Is a Plugin

**Published:** November 9, 2026
**Author:** Hugging Face
**Source:** YouTube — Hugging Face
**Language:** en-US
**HTML:** https://aiqazaqstan.com/en/articles/deepseek-harness-dsh-explained-everything-is-a-plugin

Good morning everyone. How's it going today? Today we're going to be taking a look at the Deepsea harness. We're going to be doing quite a lot of things actually today, cuz this is quite a long topic. But the idea behind this video is that by the end you're going to be able to…

Good morning everyone. How's it going today? Today we're going to be taking a look at the Deepsea harness. We're going to be doing quite a lot of things actually today, cuz this is quite a long topic. But the idea behind this video is that by the end you're going to be able to understand the architecture of the Deepsea harness, what a score is, which is the plugin system that powers this very innovative architecture and system design of this new harness. And we're also going to be creating our own plugins later on in the video actually. Take a look at the chapters if you want to take a look at that. And if you want to jump straight into that. And I'm going to show you how the plugins look like in code and how they are loaded into the harness itself. And we're going to be showing that in real time right here with you. Before that, we're going to be doing some architecture overview and and a very quick tour of the desktop application as well. So let's get right into it. Okay, so first things first, let's take a look at the application itself. Just going to keep you a very quick tour so you know what we're talking about. We're going to be talking about the Deepsea harness application as you can see right here. And most of the time I'm going to be using the desktop application, which is the electron based application that was released just a few days ago. And it is actually a wrapper around the previous version of the application that they initially released, which was a web based application that you had to run yourself on localhost as you can see right here. [snorts] But both work essentially the same way. You have your nice little chat window right here. You have your sessions history right here. And you can, I mean notably one of the most interesting parts of the Deepsea harness is that you have these different modes which allow you to load different things, different plugins into your application. The standard mode for example just starts off the regular coding agent mode. The PTC mode is actually interesting mode. It allows you to It's essentially just the same thing as simple regular standard mode, but this one right here is What it does is that whenever it calls tools, it does not call the tools procedurally, like it does not just call the tool and then expect the result, but it actually writes a nice little script with the tools. So the tools are run within a script which allows them to parallelize the different tools that it wants to call or call multiple tools within the same tool call. It's a really nice thing and nice little trivia right here. This is how the small agents agents worked originally. So really really nice thing to see right here. We have the minimal mode which just adds as little context as possible and the creator mode which is also essentially the same thing as the standard mode, but with added skills and context about how to update itself, right? Because remember one of the nicest things about the Deep Seek harness is that everything is a plugin. And what that means is that you can just ask it to modify itself and update itself and it will be able to do that kind of like Pi, but at a much deeper level. Because everything is a plugin really means that everything is a plugin including the agent loop, including the LLM providers, the tools, the context that is injected, every single thing. And we're going to be seeing a little bit more of that in just a moment. But as a part of the tour, I would like you to first of all go into creator mode right here and ask it to create a plugin for yourself. Let's ask it something like, please create a plugin that will register a new tool for the Deep Seek harness and this tool will be just a Hello World tool that greets someone by their name. And we can just send that and it's going to start working on that. Now something interesting while this is working, let me show you that right here I am actually running GLM 5.3 Flash. Now how am I doing that? Very nice, very straightforward. So all you have to do is go to settings right here, go to models, and here you can just add a new model provider. In my case, I'm running this through Hugging Face, but of course, you can use DeepSeek, which is my favorite model anyways, but just wanted to show you that you can run additional models if you want just by adding right here. You can add it by third-party model provider or by custom model API. Just add your own provider ID, the display name, and the base URL, or if it's preconfigured like the Hugging Face 1S or Moonshot or Mistral, etc. In my case, what I did is I just went right here and I looked for Hugging Face. Well, I don't see it because I have already added it, but just click on Hugging Face and add your token and you should be good to go and you should be able to select your models that you want to use. And then once that is done, let's take a look at this. Well, it says that it is done. Let's take a look. I created a directory called Hello World Greeter plugin with the following structure. We have the package that JSON and my index.js, which is the actual plugin as we're going to see later in this video. The plugins are just TypeScript or JavaScript files that implement a specific feature and tell Cordis or the plugin system which are the dependencies that it needs to use. We have the tool name and the test output which worked correctly. Now let me just open a new task right here and ask it, use the greet user tool to greet Alex. Let's take a look at it and here we're going to see tool call greet and it greeted Alex. Hello Alex. And there we go. So it seems to be working correctly. It created a tool. It created it registered the tool itself. Now in this video, we're going to be seeing how this works actually behind the scenes, how the architecture is built, and we're going to be seeing the code itself of the plugin by the end of the video. If you want to take a look at that directly, take a look at the chapters. So yeah, let's get right into it. Okay, to start off with the architecture overview of the DeepSeek harness, I would like to start first of all with a very quick definition so that we all know what we're talking about. First of all, the DeepSec harness is as we saw before, an agent harness, which even though it was primarily made for coding agents, it is actually an agent general agent harness that you can use for any other agentic applications, which means that it comes with its own loop, its own tools, and your own way to connect your own tools as well to it. It comes with its own system prompts that you can also modify. It comes with its own session files and its own user interface, which in this case, the main interface that you have to interact with it, it's the Electron application that I just showed you, which works great, but it is a little bit of a different main interface to what you would see in for example Pi or other CLI-based coding agents. Although you can create your own CLI-based application for it, but it that is beyond the current implementation. Maybe later we'll see a CLI tool for this. The motto of this coding agent is everything is a plugin. And the reason for this is that this harness is built on top of a plugin system called Cordis. Now we're going to be going a little bit more in detail into what actually Cordis is, although we're still going to be keeping it a bit high level. If you want a specific video dedicated to Cordis, please do let me know in the comments. We can also cover that later. But for now, all you have to remember is that Cordis is the plugin system that allows everything in the application to be a plugin, including the agent loop, the tools, the system prompt, everything, the tool execution layer, everything itself plugs to the same plugin surface. And that is probably the most innovative part of the DeepSec harness. We're going to be seeing that in in more detail in a bit. But also before going to the next part, let's mention that it ships actually in multiple ways, so it ships as the web application that we saw before. It also ships as the desktop app, which is the basically the Electron wrap around the web application. It ships as SDKs in both TypeScript and Python and in ACP. Okay? In this case, we're going to be talking about the core of this, but do you do know that those are there are multiple ways, multiple interfaces to interact with this harness. Let's go to the next part right now. All right, so let's actually talk about Cordis itself and we're going to be doing this again as I told you before at a very high level, but first of all, let me just give you a quick history behind Cordis because I've heard a lot of different claims about it. So first thing that you have to know is that Cordis itself is not exactly the same thing as a DeepSeek and it was not necessarily developed by DeepSeek, although the history of Cordis and DeepSeek is very tight linked tightly together. So here we have the DeepSeek harness repository and as you can see, it lists Cordis as its main architecture. And when we go to the Cordis repository right here, you can see that it does not belong to DeepSeek. However, it does link DeepSeek as the official page of the project, the DeepSeek harness website. And if you take a look actually at the paper, you will see that it was also published by DeepSeek itself. That said, the first commit of the Cordis plugin system predates the existence of DeepSeek as a company even. So by one year, as far as I understand, the creator of Cordis later on joined DeepSeek and started working on the DeepSeek harness and integrating Cordis as a groundwork that would then power DeepSeek. But as you can see, for example right here, also the top contributor of the project is an employee from DeepSeek. So very tightly linked together, not necessarily the same thing. And Cordis is not only a plugin system that is made only for coding agents. It can actually power any kind of application, although it is the most useful for coding agents because of the composability. In case you're interested in a more detailed overview of Coordis, I do recommend that you read at least the first few pages of the official paper. In case you're not familiar with DeepSeek papers, they are insanely well written, so you will have no problem reading in the first few pages. After a little bit, it does become a little bit more complex and you have to like really focus to to follow along, but the first few pages should be more than enough if you just want to get an idea of what this is trying to solve. Let's now take a look at the architecture of Coordis and what it actually means to to have this this system where everything is a plugin. All right. So now let's take a look at the Coordis architecture itself. And for this, I actually created a very quick set of slides right here for you. And as you can see, when they say that everything is a plugin, they really mean that everything is a plugin, including, and this is pretty surprising, the agent loop itself, which means that in theory, you can swap up the agent loop of DSH with your own agent loop and have your agent do something completely different. For example, I mean, you would usually not want this, but for example, let's suppose that you want to replace the existing agent loop of DSH with another agent loop as a plugin as well, which never calls the language model and never calls any tools. It just every single time returns an echo of the user query. And then all you have to do is create that plugin and plug it directly where this plugin would be. And then your agent will just always return an echo of the user query. Actually, this is the example that we're going to be building a little bit later at the end of the video, but yeah, just keep that in mind. Like everything, including the agent loop, is a plugin itself. Same thing with for example, the tool registry and every single tool. So for example, the tool functionality or the capability of your agent to calling for calling tools is a plugin itself. And the bash tool is a plugin itself, the file system, the MCP client, they're also plugins themselves. The system prompt is a plugin. The execution layer for the tools themselves is also a plugin, which means that you can swap up the execution layer of your tools without like breaking anything. So, for example, right out of the box it comes with a bash sandbox, a file system sandbox, and a DSH sub process plugins for executing the tools, which means that the tools would be executed on this different sandboxes. And you can in theory just create your own plugin that will execute the tools, for example, in a remote location in a remote machine. For example, if you want to add added security and then just plug it into the execution layer listeners and it will just work just like these other ones do. Same thing with the model providers. The integrations with the general language models is a plugin itself. The integration with the deep seek language models is also a plugin itself. Same thing for skills, the session log and storage. And the user interface interestingly also is a plugin. Sorry, and the the graphical user interface that you see like the electron application is itself its own application by the way. So, you have actually two applications in the deep seek harness. You have the back end, which is basically what we're exploring right now. And you have the front end, which is also a application which communicates with that back end. And both are created in using And to give you an idea of how all of these plugins work together, think of it as common context that exposes for the entire application. And the context is defined as CTX. And everything you plug into it has access to the same things around the entire application, right? So, for example, the DSH session plugin is a provider, so it provides some tools to the context. Same thing with the tools, the tool bash plugin or the model provider. And there are some plugins which their main functionality would be to listen to the events in the context as well. So for example, the compaction plugin, the hooks plug There are different hooks that can plug into the context. The headless user interface also is able to listen to all the events in the context. This I mean, we can go a little bit deeper into this a little bit later on in the video, but just for you to keep an idea that everything is connected to the same context and everything has access to what the context exposes. And actually, I have a nice little code example right here. Let's actually take a look at it and see what the plugins themselves are able to do in the context. All right. So now let's take a look at the actual code example. It's not an actual implementation of the code of a plugin, but it just gives you an idea of how it works. But before that actually, I want to show you what a plugin can actually do, so you can actually see it in the code that I have right here. So the first thing that a plugin can do is to provide a service. And in order to do that, you have to first register or like create claim a name for your plugin. And in order to do that, you just have to do it like this. And you just give it a name. In this case, in this example, it would be creating the plugin called tools, which already exists, but let's suppose that you're recreating the plugin called tools that which gives tool calling capabilities to your agent. And that means that this name is associated to your plugin and to the services that you provide. So if you want other plugins to consume those services, they know where to get them. And that's where the injection comes comes in. So So the second thing that the plugin can do is inject other plugins into their their functionalities. This is basically just dependency injection. What happens is that for example, let's suppose that you want to create a new tool tool itself, and you want to create it, so you're you're to have to create a plugin that that implements that tool. But in order to create a tool plugin, you're going to have to have the tools plugin, which gives your agent the possibility of calling tools. So all you have to do is just mention it as a dependency so that the tools plugin is mounted before your specific tool. And that's how the entire ecosystem works by injecting dependencies and making sure that the other one is mounted before the one that you're just defining. Third thing that you can do is register into a service with the register method. We're going to see the example in just a moment. And you can also have a plugin listen to events, just like in other coding agents such as Pi. Events are at the core of the functionality of of a coding agent. And in this case, you get them directly from the context. So every single plugin can access the context of the events that are that are that come up into the context. And as you can see, it's very straightforward. You just listen to whatever event you want, and then you have your plugin do something with it. And actually, let me show you the actual kind of like a pseudo code implementation of a couple of plugins. Let's suppose that you want to create two plugins. One's going to be your greet tool, and the other one is going to be your tool logger, which will just log every single time that you call a tool. The greet tool, the first thing as I told you, you're going to have to name it. Then you're going to have to define which are the dependencies that it's going to use and that you're going to inject into it. Since we're creating a tool, we're going to need the plugin that allows your agent to call tools. So you're going to have to wait for the tools plugin to be mounted before the greet tool plugin is mounted. And then you just do like define what your plugin will do. And in this case, it will register a tool into the tools into the tools plugin, just like this. And in this case, we're just defining it with the name, just giving it a parameter, and then just giving what it will do. But as you can see, it's very straightforward. So define the the dependency injection, which is the the plugins that it requires, and then use them. And in this case, it's using them to register something within it, within the tools plugin. And then let's say that you want to create a second tool, which will be another plugin in itself. And it also requires the injection of the tools plugin. But this one right here will not register anything. It will just log every single time that you call a tool into the into the terminal. And as you can see, in this case, that's what it does. It listens to the tools result event and then just logs that into the console. That's essentially all that's going on. So, I mean, I hope that this is a this is of course a very high-level abstraction example of how plugins work. But I hope that it's getting a little bit more clear that plugins themselves interact with the same context and you can have different different plugins provide services for other plugins as long as you list them as dependencies, right? Most likely you will not be writing the plugins yourself by hand, but it's important to have this intuition of how this composability works. And of course, by the way, when you create a plugin this way, the core system remembers everything that you define right here, so it knows how to disable your plugin if you if you if you disable it. So how what what it has to clean up. So it will know that it has to clean up the in which order so that it does not remove a plugin that is being currently used by another one. It knows which features it has to unregister and which names it has to liberate. It is also possible, however, to create to add your own cleanup functionality, which is actually a good practice when you're creating your plugins for DSH, but we're going to see that in a moment. Just consider that these plugins these are the plugins and this is how they work. Okay, and let's take a very quick look at how plugins can emit different events. And I'm going to be explaining to you a little bit about the different ways to emit those events, although I do not expect you to learn this and to be coding this by hand and choosing yourself which mode to use whenever you're emitting your events when your plugins. This is most of the time going to be done by your agent, by your DeepSeek harness. So don't worry too much about the technicalities of it. I just want you to get a high-level abstraction or a high-level intuition of what's going on and how those events are fired. So I told you before that when a plugin is registered as a service, it can fire events for other plugins to consume those events or to listen to those events and do other things whenever those events are triggered. And there are four ways in which your plugin can emit an event. So you can do it just with a regular emit method, which just fires the events and forgets. And an example of this are tool results. So when your plugin that might be executing a tool, it finishes the tool execution and emits a tool result. So that's an event that does not depend on other events. It can be a waterfall emission and that's mostly useful to think about it in the terms of the examples. So the LLM stream generation is a waterfall generation because of course you can you get all the events one after another during the completion. Another example is the tool execution, the multiple tools that are executed during an agent turn. Also you can emit events in a serial way and that means that they are awaited one after another. So for example, an agent turn stopping might happen after the the agent has been created, right? And that means that this one right here has to wait for this one to actually exist. And you can also emit different events in parallel. Something important also is that your own plugin can declare new events so that other plugins can just listen to those newly created events. And this is a useful thing if you're creating your own plugins. And interesting example is the compaction plugin which creates its own event, compaction. And something else that I [clears throat] kind of forgot to mention is that those events are scoped under the context that they are emitted to. [snorts] And in order to understand that, you have to consider that plugins can also be kind of nested together. Here it is. So plugins can be nested together. So when you have one plugin, you can register new plugins under it, and that means that all of those plugins which will have access to the context of that father father plugin. And most of the time, the way that this is used is to create multiple bundles or multiple agents that can do multiple things. So multiple agents that have different plugins associated to them. And it's usually defined this way right here. So this this one right here will have a bunch of different plugins that are associated to this one. So when a plugin emits an event, it will be emitted into this context right here. Okay? So they all emit the events to the father context right above it. That is why you shouldn't just nest all of your plugins. All of Ideally, your plugins connect to the same context, and the dependencies are added through dependency injection as we mentioned before. And that is basically how events work. So in in a nutshell, they all go to the same table on the same context as within their scope so that other plugins within the same context, within the same scope, can access and listen to those events and apply their actions on top of those events. Your plugins can create new events, and there are multiple ways to emit them depending on the nature of the event that is going to be emitted. All right. [snorts] So let's take a look at how to create your own plugins. And in order to do this, I have actually created three demo plugins right here to look at. But before that, I just want to make sure that we understand that this is not how you would usually create your plugins. Like you would not usually write them by hand in the code. What you would do is go right here to the Dipsy harness. In this case, I'm running the application, but you could also run it in the localhost on the web profile. And you're going to go right here to modes and you're going to select creator mode. That automatically loads the plugins that give your agent knowledge about Deep Seek harness itself and its extensibility and its plugin architecture so that it can create its own plugins itself, right? That's all that creator mode does. It just gives it the skills and the context that it needs to create its own plugins and this is what you would usually use to create your own plugins. That being said, I do want to show you what the actual code looks like so that when you ask your Deep Seek harness to create a new plugin, you know more or less what to expect at what it is actually building. So here I have actually cloned the the repository from the Deep Seek harness. As you can see, it's really just the same thing just to clone from GitHub and right here I have added a new directory called scratch plugin because why not? And we have added three different plugins right here. The first one is just this one right here, a my plugin. Remember I told you before that when you create a plugin, the most the only requisite that it has to have is that it has to have this apply function exported, right? And that's essentially all that you need to create a plugin. In this case, I'm using this function, but all I'm doing is just console logging Hello World right here. Just straightforward not nothing nothing more. And this apply function as we mentioned before always takes as a argument this context from Deep Seek from Cortis, okay? And that's all that is going on right here. Very straightforward. If you want a little bit more of a more complicated plugin that does a little bit more, let's take a look at this one which is the greet tool. This is the example that actually showed you in the slides moment ago. So just like before, remember the most important thing and the requisite for a plugin is to have your apply function right here that is exported and this one right here actually requires another dependency or another yeah an injection of another plugin. And in this case, since we're going to be dealing with tools, we're to be creating a tool, we're going to need to have the tools plugin already loaded for when this plugin loads. So, we're exporting a name. Also, this is going to be discovered by Cordis. We're giving it the inject array, which is the the list of dependencies that need to load before this plugin loads. And then we have this apply function that I told you before. And here we're tapping into the tools service and registering a new tool right here using the define tool method that we're also importing from that same package. And just straightforward, just added the tool. And once we have added this plugin to our DSH agent, we will be able to just run this tool as I'm going to be showing you in just a moment. And lastly, we have this other example of a plugin. This one is also very straightforward. Same thing, we export a name and an inject. We also need the tools plugin to be loaded for this one to load. And what this one does is it listens to a few to a couple of events, right? So, first it listens to tool result and it just logs that. That's essentially all that is it it is doing on this particular event. But it also listens and intercepts another event, which is the tools pre-execute. And this one right here, what it's going to do is that if we are if the model calls the bash tool and the bash tool includes an RM RF command, then we're going to deny that and ask the model to ask the user themselves to run that. And that's essentially what's going on right here. If the command includes RM RF, then we're going to log the Dallas blocked and we're going to return to the model that it cannot run it and it should ask the user to run it by themselves. And remember I told you that some events are called via a waterfall mode and this one right here is one of those. And when you have a waterfall event, you have to return next for it to continue its regular flow. And if you're going to be interrupting it, then you return this deny, for example, object. And that's essentially the three examples or the three plugins that we're going to be working with. And when you ask DeepSeek on the create remote to create a new plugin, this is what you're going to be creating behind the scenes. Now, now that you have this plugins right here, how does DeepSeek harness actually load them? Like cuz we have them right here in the code, but how are they loaded when you start the application? Let's take a look at that. Okay, so we have already seen how what the code looks like of a plugin. Now, let's take a look at how it is loaded into Cordis. And remember I told you that the plugins in Cordis are configuration, not code. At least that is how they are loaded. And that means that in order to load your plugins, you're going to have to create a YAML file, a configuration file that looks something like this. So you're going to have to add an insert property right here, and then you're going to have to give an ID and a name to your plugins that you have added. In this case, in this particular one, this ones right here are added as NPM packages. That's why they are named like this. But if you do not have an NPM package or you know just want to run directly the code like this as it is, you can also do it like this. Just give them an ID and add instead of the name of the package just the the absolute path to the actual file that contains your plugin. And then once you have this, this one right here, you're going to add it to your to your file. Let me show you. So you're going to run this in my in this example I'm going to show it to you in the localhost in the web profile, not in the Electron application. I'm going to show you the the Electron application just a moment. And then just run the path to my Cordis YAML configuration file, which is this one right here. [snorts] And that's essentially all that I have to do. But what does this actually do? What is going on is that this thing right here is telling that we're going to run the web profile and we're going to patch it to add these lines right here to the end of its existing Cordis configuration. And which is that Cordis configuration? Where does it live? Well, also very simple to find it. You go right here to the package and we're going to go same thing into packages right here. We're going to go into bundle and in here in bundle we can see the web application right here and here you can see that there is another cordis.patch.yaml and this one right here also lists all of the plugins that it that come preloaded with the web application, right? So all of this right here make up the entire cordis application and that's essentially how how this is loaded. So let me show you what happens when I run this. So I'm just going to do DSH web and I'm going to patch it with my patch right here and it opened right here in a different in a different different window. Let me open it and here we go. So here we go. Here we have my localhost application and let's actually call it. I'm going to test it asking it to do this right here. So I have three plugins loaded so I'm going to ask it first to use the greet tool to greet Ada then run this exact batch command RF and let's take a look at what happens. So as you can see it added some context injection and it called the tool Ada which is now in its tool in its tool catalog and it also tells me that RMRF was blocked by the guard plugin so it didn't run so you should verify it and run it yourself. Basically that's exactly what we wanted and this happened because we ran the the deep sick harness on web profile with our patch right here which adds our plugins on top of the the preconfigured plugins for the web profile, right? And as you can see right here we also have my hello plugin tool right here with hello plugin hello world plugin right here which also just console logs this loaded message as we saw before. So as you can see my plugins work. They are loaded but let's see how we can load them into the usual desktop application because you're most likely going to be working on this one not on the localhost and to do that you will need to turn your plugins into npm packages to add them like this. And then they will be added through the DeepSeek service that adds the plugins themselves. So you will not have to be running this dash dash patch. This is just really to show you what is going on behind the scenes, but when you create your own plugins like this, they will not you will not need to manually edit your Cordis files. Just to show you what this Cordis configuration file looks like. So this one right here is the one from the base bundle and this one right here is the one that I added, but you can there so this is a set of files that build on top of each other, right? And that patch or update or append new things to to your configuration. And the last layer is the user configuration which overrides all of the rest. And [snorts] this user configuration lives inside let me show you. This user configuration lives inside your Sage and inside your profiles. And here you have a different configuration for each profile that you may have. So as you can see for my desktop, which is the one that I use the most, I have right here let me just open it and let me just show you what's inside of here. I have my Cordis dot patch dot YAML file. So I'm just going to open it. Cordis dot patch dot YAML. And as you can see this is my real Cordis file on the user on my user Sage directory and this one updates and modifies the configuration of my existing desktop application. As you can see here are some settings that I have added. The config flags right here, the config properties are the ones that are passed into the plugins that are associated to this config property. So this will go into default model and this will go into the UI chat. And for example, I have added Hugging Face as my inference provider right here. So I have my favorite Hugging Face models that I'm running. So I'm running this with V4.1 Flash and Inklang and GLM 5.3 Flash. So basically this is what Cordis does and how it works. And I have already loaded these plugins as packages and added them using the desktop helper. In your case, DSH will do it by itself, but let me just show you that you can also do it right here. Just going to paste the exact same the exact same prompt asking it to greet data and then run this command right here. And as you can see right here, let's open the list of tasks. You can see it calls the tool because it has it available. And it it told me that it cannot run RMRF because the we have the guard plugin that blocked it. And essentially, now we know how plugins work. We can see them being loaded. And now when you go right here and create your new plugin with creator mode and ask it to do something, you will know what it is actually creating and how it is loading it. Okay? So I hope this was a nice introduction and a complete overview of how plugins work in Deep Seek. Do let me know if you have any questions and I will see you in the next one.

---

*From the original source: [YouTube — Hugging Face](https://www.youtube.com/watch?v=9F9x3MufdMQ). Open original.*

**Tags:** #Hugging Face #DeepSeek #Mistral AI #YouTube

---

*AI Qazaqstan — non-commercial informational portal about AI in Kazakhstan. Machine translations and summaries are AI-generated.*