DeepSeek Super Agent, explained: plugins and configuration, not a fork

The source, passage by passage

1. u1 0:00 Intro
2. u2 0:00 Okay, so this past weekend, DeepSeek released something that a lot of people out there are calling the answer to Claude Code. It's an agent that sits on a GitHub repo. It watches the issues and pull requests, and when someone on your team asks it to do something, It then goes off into its own session, does the work, and comes back with a PR Now, while that's cool in itself, that's not really the

   

3. u3 0:23 part that I want to talk about here. The part that I find really interesting is how they built it. The whole thing is just a set of plugins dropped into their agent harness. And to understand why that matters, we need to go back and actually look at the harness itself So when the DeepSeek Carnis came out back in
4. u4 0:39 DeepSeek Harness recap
5. u5 0:41 August, I didn't actually cover it. And honestly, the reason for that was I just got so busy playing with it and trying out new ideas with it all the time, I kept putting off making the video because I felt like there were so many things that I wanted to show. For me, the whole plugin architecture of that harness is really cool and it just allows you to do a whole bunch of things like this new super agent enables

   

6. u6 1:03 Now, obviously in the meantime, a lot of people ended up covering it. It's turned out to be one of the most starred projects on GitHub this year So in this video I'm gonna do a sort of catch up on that and look at some of the new stuff that they've actually built on top of this all right, so the new thing that DeepSeek

   

7. u7 1:15 What Super Agent is
8. u8 1:17 has launched is called Super Agent. and along with the repo that they launched, they've basically written an article on X called Exploring Super Agent Design: Towards a More Autonomous Agent System And in that article in the repo, they're very upfront about that this is a research prototype.
9. u9 1:34 It's not an official DeepSeek product And they even mentioned that it grew out of their own day-to-day development work and that a lot of the ideas and the engineering here were actually written by coding agents themselves. So the basic idea is this, instead of you opening a session and talking to an agent, The agent listens to where your team already works and the example that they've

   

10. u10 1:56 launched now, that happens to be GitHub, and also happens to be an app called Feishu, which is ByteDance's sort of Slack equivalent now when someone who's allowed to asks it for something, it opens up a work item, it spins up its own session in its own directory, does all of the work, replies back to the original conversation
11. u11 2:18 And then usually in that reply, it's going to have a pull request in there And in many ways, you can kind of think of this as building on the whole ideas of software factories, of automated software generation and stuff that we've seen a lot of people being talking about over the past couple of months Now DeepSeek themselves say that they've been running an internal

    

12. u12 2:37 version of this continuously. It's been reproducing and fixing bug issues, responding to code review comments And it's actually been making improvements to the DeepSeek harness itself so before
13. u13 2:49 Model or harness: what matters more?
14. u14 2:49 I go into showing you the how of how it actually all works, I wanna show you why the harness layer matters so much Recently on the VentureBeat podcast, Beyond the Pilot, which I co-host, we've interviewed a number of interesting people, including the CTO of Instacart and the CTO of Box. Now, both of those episodes are coming up over the next couple of weeks or so.
15. u15 3:10 But one of the questions that I put to both of them was basically what's more important now? the model or the harness? both of them came back on the side of the harness. And I'll leave it for you to watch the full interviews because it was fascinating conversations but clearly now a lot of the innovation has moved away from just the model itself to the actual harnesses.
16. u16 3:31 And maybe it will swing back in the future as we get better models, but currently you need to be focused on where the harnesses are going All right, so one of the things that my team and I are trying to do right now is increase the coverage and the number of videos that we're doing. It would really help if you just support the channel by clicking that subscribe button.
17. u17 3:49 we know that most of you are watching a lot of the videos and still not subscribed Anyway, back to why the harness is so important.
18. u18 3:53 Frontier Harness benchmark
19. u19 3:56 so this is the Frontier Harness chart and result table. So these aren't my numbers. This comes from a benchmark called Frontier Harness Eval, and what they did was take one model, the Kimi K3, and run it through nine different coding agent harnesses, 12 configurations in total. Codex, Claude Code, Pi, OpenCode, DeepSeek Harness, et cetera
20. u20 4:20 They then gave it the same 30 tasks, same model, same runtime. The only thing that changed here was the harness Now, you could make the argument that it's not a totally fair comparison, that Claude Code is optimized for its models, that Codex is optimized for the models, but it's really interesting to see the results that they got here.
21. u21 4:38 Codex came out on top with 66.7 pass rate But if you look at that next row, DeepSeek Harness in its creator configuration and Claude Code both scored 63.3%. that's the same pass rate, same model, But the DeepSeek Harness run cost only about $3.28 per successful task, and Claude Code cost about $18.34.
22. u22 5:05 Now, across the whole table, the gap between the cheapest and most expensive configurations was actually about 17.5x Now I would be careful reading too much into the exact configurations here. It's 30 tasks, So one task is worth about three and a third points. The difference between Codex and DeepSeek is literally just one task here But I do
23. u23 5:27 think the big picture holds true here, that the harness isn't just a wrapper. It changes the cost, the caching, the speed, and the success rate, even when the model is held constant. so if you're evaluating a model, I'd try and do it in two or three harnesses before deciding whether the model is any good.
24. u24 5:47 Otherwise, you might be just blaming a model for what actually is the harness's responsibility
25. u25 5:52 DeepSeek Harness: everything is a plugin
26. u26 5:52 All right, so what is DeepSeek Harness and why does it do well here? So DeepSeek Harness or DSH came out on August 13th alongside, the initial release of DeepSeek V4 Pro. It's MIT licensed and there's a web UI. So you can start with just one npx command and a desktop app. It's not locked to the DeepSeek models.

    

27. u27 6:13 I think that's really important to stress here. It works with other providers and even with OpenAI compatible endpoints. The key tagline here, though, that sort of sums this up is that everything is a plugin, and they mean that very literally. in most agent frameworks, you've got a core, the agent loop, the model
28. u28 6:33 calls, the tool handling, and then plugins sort of hang off on the side. In DSH , the router itself is a plugin, the tool registry, a plugin, the session log, a plugin. Even the agent loop itself is a plugin underneath all of this is a
29. u29 6:49 Cordis
30. u30 6:51 framework called Cordis, and there's a paper behind that from three researchers at the Beijing University. and this framework DeepSeek called a programming paradigm for spatiotemporal composability. Now, that sounds like a lot, But the two ideas here are actually pretty simple. The first is what they call temporal composability.
31. u31 7:11 when you remove a component, everything it did gets completely undone. If a plugin registered a tool or a hook into event, unloading it reverses all of that The simplest way to think about this is that you can unplug something really cleanly. The second element here is spatial composability.
32. u32 7:29 Components declare what they depend on, and the runtime activates or deactivates them as those dependencies come and go. so you can basically plug in things safely and unplug them safely as well. now why does an agent harness need this? Because systems are changing constantly. You're swapping models, you're adding tools, you're turning things on and
33. u33 7:49 off per permission, and if every one of those changes sort of leaves junk behind, things get messy really quickly we saw this even when people sort of reversed engineered how Claude Code was working everyone that's making agent harnesses at the moment is moving at such a fast pace it's just a simple fact that often code gets left behind.
34. u34 8:09 Anyway, so how does this look in practice? well, running DSH is actually a tree of plugins which gets composed when it boots up from layers. First come bundles, which are packaged sets of plugins plus their configs. then your profiles patch a YAML file called cordis.patch. Then you've got a home level patch, and then anything you
35. u35 8:29 pass in on the command line. so each layer here can target any plugin by its ID and replace its config or insert new ones They've even got a command in there for dump config that just prints out the whole tree that your machine is booting from and every row in that can be overridden now in the UI, they've got four modes and they work in the same way.

    

36. u36 8:51 You've got standard, PTC, minimal, and creator and those themselves are just different sets of plugins. The creator mode is sort of the logical endpoint for this. You can describe a plugin in chat and the agent will write it, install it, and then check that it's actually live
37. u37 9:09 So you can kind of think of this as while everyone's been focused on just continual learning for models, this is bringing continual learning into the harness Another thing that's worth knowing here is that The core repo here isn't taking outside pull requests now. They're pointing people to discussions and building plugins instead Which actually makes total sense for this design, right?
38. u38 9:32 If there's no core to patch, then plugins are how you contribute. And that's what brings us back to the whole super agent so if you open the Super Agent repo, one of the first files you'll see is the cordis.patch YAML file, and that file is basically the whole integration. it inserts a core Super Agent plugin, a GitHub watcher plugin and
39. u39 9:52 a Feishu watcher plugin by default Now obviously if you're not using those, you could just turn those off but the way Super Agent works is that it defines a separate preset for the workers. You can think of it as DSH's standard preset with a bunch of things stripped out. No asking the person questions, no plan mode, no web fetch, no spinning off
40. u40 10:13 sub-agents, etc. And the shell is set so that any command running longer than five seconds gets pushed to a background job That way a long build Doesn't stop the worker from noticing that someone just left a new comment as it's going through Obviously that can be one of the frustrating things with Claude Code and Codex is once it starts going, you're sitting there waiting to basically update
41. u41 10:34 it, and you perhaps want to inject a prompt in while it's still going as you realize it's going in the wrong direction so what you're looking at in this agent is a fairly different system entirely. It's built from configurations and plugins. there's no forking of the harness, and really that's the whole payoff of the DSH design that we've just talked about Now DSH itself did actually have

    

42. u42 10:53 Agent teams vs Super Agent
43. u43 10:55 an experimental agent teams feature with a roster, a task board, a mailbox. So why build this? well, you can think about agent teams is about coordinating agents inside one job. The super agent is about handling lots of independent jobs that arrive from the outside world over perhaps a long period of time, and also from
44. u44 11:17 lots of different people posting here. It's actually addressing a different problem than what the teams feature did And one cool practical detail here is that the router and the workers Can each be given a different model. So come back to that in a second Now, if we look at the architecture here, this basically has two layers to it.
45. u45 11:36 on top there's one long-running session that they call the router. It handles all the human interaction, keeps the big picture context, hands out work to perhaps different plugins or different agents. underneath are those worker agents, each running in their own isolated session. Workers never have to talk to people directly.
46. u46 11:55 They report back to the router. the router does all the communication. everything going in from the outside is a trigger. A new issue, a review comment, a chat message, et cetera. Each trigger first goes through a gate, which is plain code and not even a model. and that gives you a deterministic feature to basically check is this
47. u47 12:15 person even on the allowed list to be able to comment or to be able to file a pull request, et cetera it also helps it to answer things like did they actually address the agent Now only when those checks have passed does the model actually get to look at it and decide, you know, whether it's real work. If it is, it becomes a ticket with what they call a mandate.
48. u48 12:35 that's a record of who asked for it, under which rules, how far the work is allowed to go, et cetera. that ticket and the mandate then get passed to a worker Now here's a really cool detail that they've got in there. Once a worker owns a ticket, it subscribes to that conversation. So when someone comments on the PR that it opened, that comment
49. u49 12:55 goes straight to the worker. It skips the router entirely and you can think about that skipping of that orchestration layer and going straight through Just saves you a huge amount on tokens, et cetera. In fact, when they turned off this in their experiments, Router decisions actually went up by 30%, and obviously the amount of tokens went up with it For me though, the part that I find most interesting here though is
50. u50 13:17 about the router as the bottleneck. So you would assume that one central session that's doing the orchestration, handing everything out would just get overwhelmed as things get busy it actually turns out here that it kind of does the opposite. When triggers arrive while the router is in mid-inference, they pile up and they get handled together in the next call
51. u51 13:39 And because The way that they've structured that router's job to be sort of long input and short on output, it actually allows it to batch these things really cheaply now in DeepSeek's stress test, they push the trigger rate from about one a minute to about 40 a minute. Average batch size went from one to 2.8.
52. u52 13:58 and sure, each call did get a bit slower from about 2.5 seconds to 3.9. but the time per decision, because it's being done now in batches, actually drops from 6.4 seconds down to 1.6 seconds. So it got more efficient under load they also say that the router job is often simpler than you'd expect, and a lighter model usually handles it fine.
53. u53 14:21 That kind of goes against the grain for a lot of thinking of Where people have been thinking that your orchestrator needs to have the best model and that your sub-agents can get away with simpler models It turns out that that router doesn't even need a Bash tool so overall that router can use a fast, cheap model You can actually use the stronger model for some of your workers and this is something that I definitely wanna test more with open
54. u54 14:43 models going forward anyway, on top of this, they have this philosophy, which I think is a really useful part. The principle is take as little human attention as possible and give as much value as possible. And I kind of feel as we're building agents, it's really hard to argue against that you want an agent that only acts when someone allowed asks for it, or when
55. u55 15:05 a rule the team wrote actually allows it Interestingly, even in there when work nobody ask for starts, it actually starts in a mode where it just records what it would've done it then confirms itself whether that would've actually worked and then only speaks up when there's a result or a decision that somebody needs to make I really think there are a lot of lessons in here that all of us can
56. u56 15:27 take away for how we build our own agents
57. u57 15:30 Limits: prototype, GitHub only, synthetic tests
58. u58 15:30 Okay, so what's missing here? Let me go through a few caveats here. First, this is a prototype, and they say that really clearly. The published code isn't identical to their internal version. Some designs in the article, are actually future directions that aren't in the repo yet and from what I can see, things like the watchdog session perhaps isn't fully there yet, and I'm sure there are others that are missing as well.
59. u59 15:53 Second, this is all kind of narrow. It's one GitHub repo they haven't set this up to work with Slack or with email But actually I'm not really worried about that Because everything is basically a plugin, they've also included a cookbook for adding your own source code in there so my guess is very quickly we will see forks of this with lots of other integrations
60. u60 16:12 in there third up the thing that we should be a little bit concerned about is that the super agent experiments that they ran on and reported their benchmarks on are actually run on synthetic workloads in a simplified environment. and they say themselves that this is basically just a preliminary reference and on things like the 30 tasks, this is just a small sample.
61. u61 16:32 so just treat those rankings as a rough guide. finally the big thing to be a little bit concerned about here is security. they do list the problems of prompt injection, credentials leaking, permissions across devices, et cetera, as things that they haven't fully solved yet so naturally you probably wanna be a bit careful about how you use this but if you are using it with local models in a totally locked down
62. u62 16:53 environment, you probably don't have a lot to really worry about here Alright. So overall, why I think Super Agent is a really interesting product here, what is even more interesting here it's just basically the proof of design. DeepSeek has built something which is quite a different agent system On top of their own harness with just a few patch files and plugins without
63. u63 17:14 touching the core of the harness at all. And for me, the bigger point here is just showing you how much harnesses are evolving at such a quick pace at the moment.
64. u64 17:23 Will harnesses become all plugins?
65. u65 17:23 Anyway, as always, I've put the links to the repos, the paper, the benchmark, all of that's in the description let me know in the comments what you think. Do you see the future of the harnesses of being these composable plugins Where different people create different ideas in different ways, and we're not just reliant on the same coding agent interfaces that we've seen up until now

    

66. u66 17:46 as always, if you found the video useful, please click like and subscribe, and I will talk to you in the next video. Bye for now