Transcript
Use with ChatGPT / Claude Auto-scroll A
Introduces the core question of when multi-agent workflows are worth the added complexity. The speaker outlines the video’s roadmap: subagents, goal loops, specialist profiles, and Kanban graphs.
Speaker A
That's just a really powerful way for you to significantly reduce the cost.There we go.It just dropped from 45,000 tokens down to 18,000.One agent can already delegate to sub agents.So what does making an agent team actually add?This is the question I get asked most often about multi agent workflows.Why build a team if one capable agent can actually get the job done?And honestly, sometimes you shouldn't.One powerful agent with sub agents can often be enough, but other times a more complex workflow can improve the quality and the efficiency.Hi, my name is Callum, also known as Wanderloots and welcome to today's video on agents loops and graphs.When are multi agent teams worth it?This process also works with agents outside of Hermes as well.In today's video we'll explore the different levels of agentic workflows.One agent with temporary helpers, AKA sub agents, goal loops that check whether the work is actually done.
Adding specialists with their own tools, skills and memories, AKA bot mode and then Kanban, a way to manage complex agentic tasks.Along the way we'll check what does each level actually need and when does it make sense for a specific task to add more agents or tooling, including a test at the end where I give the same task to each level and see how it does.Now let's take a look at agents, graphs and loops.So there are three separate questions that we're going to ask here.Who does the work, how do they check it, and what do they do next?So today I want to go through an example scenario that applies to almost every type of task working with an agent.If information comes in, what actions should I take, how should I take them, and what does done look like for that particular task?
For example, an email comes in or I take notes on a new article and I want to add it to my LLM wiki.I How does the agent process that information in a consistent, repeatable way so that it actually meets the satisfaction that I want for that particular task?But first, before we get into automations, triggers, task graphs and Kanban, let's start with just a single agent to see how it works and orchestrates.With subagents, we'll build up in complexity until we get to a full graph system that lets you orchestrate your tasks.If you find this video helpful, please like Hype and subscribe as I really appreciate your support a lot.If you're looking for more ways to support me, please consider joining my YouTube or Patreon memberships members get access to insights, tips and kits for agentic and knowledge workflows.I've also put together a free article that I'll link in the top comment that goes through agents loops and graphs in a little bit more detail for beginners as a guide.
I'll also include the results of the test that I ran so you can go through it in a little bit more depth and hopefully see how this can help you improve the quality of your own workflow.
Demonstrates a single agent using delegated subagents to handle research more efficiently. The speaker compares token usage, explains why delegation can reduce context load, and introduces the idea of setting goals.
Speaker A
All right, so the first example that we're going to go through is using a single agent here, which you're probably already familiar with.This would be just any type of chatbot, but we're going to give this agent the ability to have subagents.So we can see in the bottom left here we have this option for open agents and we can see that right now at the moment we have no live sub agents.So when we're working with this first example of a single specialized agent, we can think of this as a parent agent that has the ability to create multiple sub agents or children agents.So if we go over to capabilities on the left here and go over to tools, we can search for delegation and we can see that right now task delegation is turned off.
So I'm going to enable this tool right here and this will enable the parent agent to create a series of sub agents with specific capabilities.So let's get this started.It's going to be able to delegate to solve our particular problem, which is how do I turn incoming information into something useful, an action I can take or knowledge I can reuse?And what is the best strategy for that action system?Does it make sense to use a single agent with delegation capabilities or a multi agent team with different specialized agents?And the idea here is that if we can have one capable agent that's able to meet my standards, that's a complete solution on its own.So right now we can see that the agent was able to create all of these subagents that are now running in parallel.We have three of them.We can see on the bottom here that we have three different workers active at the moment.
And what's cool, this is a new update.If we click on the three sub agents here and click on a specific agent, we're able to give instructions to this sub agent and steer it.So I could get feedback saying make sure to please include citations.And I would be able to now steer this agent and that just sent off specific instructions to this particular agent that's looking at concrete end to end workflows for inbox information.And I could do that for each of the different subagents.And now we can see, for example, this particular agent, the one that I just steered, is now using the research grounded citations skills.
So I was able to give some instruction to the agent as it's running to help control the direction that it's going in.You can click on it here and you can go and see how it's thinking.Oh, we just saw this one finished right now.Now we have two agents instead of three, and we can see that one has completed right here and the other two are running.So now the main agent, the parent agent, is waiting for the sub agents to complete its work and then it'll synthesize a concrete recommendation when they return.
Okay, here we go.It looks like all three of those just finished.So now the main agent has gone through and it validated a few of the sources and now it is creating a report right here.Okay, so this gave what looks like a pretty comprehensive answer.You can see if I scroll all the way to the bottom, there's a lot of information here.So I'd have to go through that a little bit more in depth.And what's nice is if we take a look at the bottom here, this only used up 36,000 tokens.And the reason for that is because the parent agent delegated to subagents and only had to give definitions for them to go off and run.So the sub agents themselves then used up their own amount of context.And that's one of the major benefits of using a delegation system like this is I didn't have to have this main parent agent blow through its context window.
Instead it could delegate to subagents of lower intelligence and then take the synthesized reports rather than reading all of the pages itself.So the overall idea here is that we're delegating the work but not the judgment.And just to see how this compares, I'm going to give the same prompt asking it to do research, but do not delegate to subagent.So the approach where I just used a single agent and told it not to delegate to subagents, we can see that used 102,000 tokens, whereas the one that delegated to subagents only used 37,000 tokens.So keep in mind this is not taking into account the sub agent token usage.So the overall tokens was larger, there was more context used, but that context that made it back into the main higher intelligence agent was significantly compressed relative to the agent that just did it all itself and had 102,000.
If I ran this turn one more time, I might have to compress the context here and then you lose some quality.So that's the first comparison, just using a single agent versus using a single agent with multiple sub agents.So the biggest difference is that one uses up a lot more context.But this is also a very basic example and the results of both of these are basically the same.Build an accountable action steward with delegation capabilities, not a standing team of specialized agents.A permanent multi agent team adds coordination, cost, latency and evaluation problems before before it has proved its value.Multi agent designs work well when the task is genuinely decomposable in parallel.And this is a very similar answer to what we got with the delegation system.Do not begin with a peer team of autonomous agents.
Delegate bounded read only work to specialists when that work is genuinely independent.So both of our researchers found effectively the same thing, that we should only delegate specialist work when it actually makes sense to do so when the complexity needs it.But all of this is relative.This is specifically for a one off research task that we just did here.As the system starts to scale in complexity, we need to start thinking about other ways of orchestrating, for example, using all of the different bots like we've set up in previous videos.And one thing I want to mention too is that when we're delegating to subagents, subagents know nothing.They start with completely fresh conversations, so they have zero knowledge of the parent's conversation history, tool calls or anything discussed before they were created.For the delegation, the subagent's only context comes from the goal and the context field that the parent agent populates when it calls delegate Task.
Delegate task is this tool that we enabled at the beginning here.And the context is how much information goes into all of this.
But before we get into an actual situation where it makes sense to have multi agent workflows, there's one more thing I want to quickly talk about, which is a way that we can enhance the quality of the output of the single agent, whether it's a parent agent with delegated subagents or all in one.And that actually brings me back to the warning of the subagent system, which is that the context comes from the goal.
Shows how a standing goal lets an agent keep looping until quality criteria are met. The speaker explains how to constrain models, preserve quota, and decide when specialist agents are actually needed.
Speaker A
So what is a goal?
So to bring up goal, we can type in slash and goal, and this brings up the goal command, which is a way that we can set a standing goal that HERMES works across all turns until it's achieved.And basically what that means is before we get into the complexity of setting up all of these specialist Agents and figuring out how to coordinate them.There's one more step that you should try first, which is to enable a goal.A goal effectively allows you to link multiple prompts together into a bigger picture, a broader task than just one specific research task.For example, instead of managing every step, I hand over a bounded outcome.
What success means, how to verify it and when to ask me.The main agent acts as a judge that checks the progress and the session can continue within its own budget.And the goal isn't endless research, the evidence matters.So before we get into setting up a complex system to see if we can get more out of our agent, we we can try using this goal command.So let's give our multi agent a goal here.
So we can see by using goal, I now have turned this goal active.I've added a little bit more detail than just saying, hey, can you go research this thing?I've said specifically I want different streams of information.Please use delegated subagents of lower intelligence to do the research.So each one of these should be using at least a tera medium instead of Terrahi.I'll talk about model routing in a moment, but then I've also said please prepare a synthesized report and then once you are done that, corroborate the report against practical workflows from community best practices in Hermes.You also must make sure the report is less than 500 words and has clear citations.We can see that the sub agents are all running right now.So what I've effectively done here is I've told the agent what done looks like.So it's taken all of these criteria and it will just keep running.
We can see turn 1 of 20.The default limit is 20 turns.The agent is able to loop itself 20 times, checking to make sure that the information and the research and the output meet the quality standard that I've requested.So this is a really great way for you to increase the quality of your work without necessarily introducing a lot of complexity.I honestly use this all the time, especially for coding.So I can also add criteria on here.For example, we must have at least five peer reviewed sources and I can add that information to the criteria as the agent continues running and that now becomes a new definition of what done looks like.So we can see here it took my criteria into account because now the criteria is we must have at least five peer reviewed sources.And if we look here, it only produced eight sources and it doesn't look like they're peer reviewed.
So now the agent has started up its next task on Turn two and turn three and it's delegated to another series of sub agents to now cross reference the output against peer reviewed academic sources.
So it says it's now added an independent organizational coordination and team cognition literature to the evidence set and it's awaiting the peer review before it will work again.As this is working, I can think of more criteria and I can add this here and the agent will just keep looping.The more specific you are on what done looks like at the beginning, what the actual goal is, the better this process will work.Depending on the type of task, depending on the type of budget you have, depending on your goals, you're going to have different ways of doing this.So it's worth experimenting to see what actually makes the most sense for your particular situation.
So it's kind of a hands off method of operating.If you've established a good enough goal at the beginning, the agent can run on its own.In some systems, I've had my coding agents run for five or six hours straight working on a coding system delegating to lower intelligence sub agents.And it keeps automatically testing the code to make sure it works before it presents it back to me for approval.And that brings me to an important point because if you're running a goal here and it runs for hours, and you have this set to Astra, for example, or to Fable or whatever your frontier model is, it's possible that a goal could just completely blow through your quota in a very short period of time, especially if you're not sitting there monitoring it.So this brings me to an important question on who should actually be doing the work here.
So what we can see is the sub agents here.It just says GPT 5.6 tera.So I can't actually see at the moment if it is medium or lower.So as part of the goal here, I could have specified, rather than just please use delegated sub agents of lower intelligence, I could have said please use a local model or please use Luna only for the research.And then you, as the higher intelligence model can synthesize it.So this is where you can start being more specific with your prompting and specific with your orchestrating through a single agent, delegating to lower intelligence sub agents to significantly preserve your quota.It makes a massive difference because keeping an agent working isn't the same thing as using its intelligence.Well, I want the orchestrator agent, the main agent, to make the judgments, not to carry every source detail or do every little action itself.
So we can use these lightweight helpers for bounded extractions.With limited actions.And what I mean by that is we can be specific about what type of model is used in which type of situation.So this can apply to the original goal that I just give here.I can be specific, like I mentioned, of what type of model I want to be used.I can bring in the Agents MD file where for this particular profile, this particular bot or Hermes agent, I can specify inside of the Agents MD or inside of for example the sold out md.I can say when using subagent delegation, always use lower intelligence models.By including it here, it means that every single time this particular bot, this particular agent, wants to run a task that involves some sub agent delegation, it will always know to use lower intelligence models.
And I can go even a step further by going under settings and model and I can choose the auxiliary model for different types of tasks, where for example, maybe for image analysis I don't want to use my main model.I can change this and use a local model, or I could use a cheaper model.So you can go in and you can start limiting the specific actions to specific models to help conserve the quota and intelligence of the main agent for when it actually needs it.
And honestly, this did a really good job.It was able to specifically limit the report to just a couple hundred words instead of the original thousands and thousands of words it gave me off of the first one.So it wasn't just about adding that limitation at the beginning, it was framing the goal that I wanted it to go in a particular order for cross referencing and corroborating the report and then make sure that it was 500 words.But honestly, this example here is kind of disconnected from my actual workflow.This might be the generic best answer of when delegation beats a specialist team where we want to have an orchestration and delegation for a single evolving state, sequential or predictable work.And in contrast, you might want a multi agent team for breadth first research different types of due diligence pipelines with different specialist identities.
So this all makes sense.But everything I've just said here is not very specific to me.It doesn't know who I am or what I want.And that brings me back to Hermes corroboration, where delegatetask brings up a fresh context fork join primitive whose children return summaries.
So it fits bounded research review and repair work.But it doesn't necessarily make sense for other types of situations that require more specialization and more context and more knowledge.Because like I mentioned, subagents have zero knowledge from the parent's conversation history.They only have what comes from the goal and the context that the parent gives them.But what if we start getting into more specific context or more custom situations that involve other types of context outside of what the parent even knows?We can see here the decision test that the answer says is add a specialist if it is independent, needs different context tools and policy, and beats the single agent baseline on quality, coverage, latency and total review cost.So in other words, the answer is that we should add specialists if we want it to keep its own working knowledge and have access to different context tools and policies, perhaps have a different memory system rather than being spawned as a brand new agent every single time.
And I note that the Hermes corroboration here mentions Kanban or Kanban, depending on how you want to pronounce it.But before we get into Kanban, I thought that we could take a quick look at Hermes.Bot mode actually sets you up for success when you start using Kanban, because it helps you prepare the specialist profiles.Like we can see down here, I have orchestrator, researcher, and librarian.
Explains bot mode as a set of persistent specialist profiles with their own skills, memory, and context. The speaker shows how group chat creates a graph-like workflow and how it differs from simple delegation.
Speaker A
So let's take a quick look at bot mode.
So now we can go from a single agent operating in a loop with delegated subagents to a graph.That's where profiles come in.Okay, so this is bot mode.So we can see here a bot is just a profile.It's the same list of profiles that I have along the bottom here.A bot or a profile can retain its own skills, memory and working context with a model suited to its role.Each of these different bots here can have a default model that's different.For example, maybe my Orchestrator has one of the most powerful models available, a frontier model.But maybe the researcher needs a much less powerful model.And then I can use a feature like the group chat to coordinate how they work together.
So rather than a sub agent starting with zero knowledge, we can configure what type of knowledge and skills and memory we want available for each specialist.And that knowledge and all of that context and capabilities survives the chat conversation.It maintains it over time.And since Hermes is a self learning system, it can also learn more skills as well, getting better at its particular specialized task.And we can take a quick look at a group chat here where we can see, for example, I have the librarian, the orchestrator and the researcher, and they're all working together to solve the original task that I put out.
So you can think of this as a communication graph where we've set up a group chat here, and the group chat has particular members and they work together, communicating back and forth with one another to solve a particular problem.So this is where we go from not just having a loop, but going from a loop to a graph.Now, I've already talked a lot about this in the last two videos.In the first video, I gave an overview on what bot mode is, how to get it set up, and how to customize each of these individual profiles.So I'm not going to touch on that today.
And then in the second video, we did a specific research upgrade where I updated the capabilities of the researcher to be a much more powerful tool.The main skill that I gave the researcher as an upgrade allowed it to check both academic sources and state of the art sources and then corroborate the two of them.I just wanted to quickly show you this because it is a form of graph in the sense that the orchestrator is able to communicate and message back and forth with the different subagents.But it's not the same as a full task graph like we can get into with Kanban.All you need to know at this point is that the orchestrator is the one that I message.It's my human proxy, the one that controls the other agents the researcher is able to investigate.So in the example of information coming in, the orchestrator would create the task and then give it to the researcher to go investigate.
And then the librarian works with my existing LLM wiki to take the output research that I've approved as a human and file it into my LLM wiki or my knowledge base in Obsidian.So in a graph, each node can be a single agent or action, or a bundle of actions.For example, like an agent loop built into the group as part of a bigger macro loop.
So in group chats, one of the key limitations is that they only have the ability to go back and forth three times before they have to stop and check what you actually want.So before we actually get into running these full control graphs, I just wanted to quickly talk about a couple examples on how this fits together so that you can see what the graph might look like before we get into how to set it up, just so it makes a little bit more practical sense.So imagine you have an email come in and you want to have a decision, maybe you want to have a draft created, maybe you want to have some research done, maybe both.So the email can come in and it can trigger an agent, like the researcher agent to pull in the relevant context and the evidence by doing some research.
Once it's done, it can then create a brief, like a research brief, and draft a Reply and then hand it off to you for review.If you don't think it's good enough quality or you think it's missing something, you can provide some more context, some more commentary, or steer it, and you can have it go back and loop again.So this brings in a loop, but it's a human in the loop.Then, if it meets your approval, you can have it create the draft or even potentially send it right away if you've already reviewed the final result.It's up to you if you want to have the send capability given to the agent, or if you want to click the button.As another example, let's say you've come across a great article or a YouTube video or some other resource and you've taken some notes on it.
You can drop in the raw source and your notes and you can send it off to the librarian.The librarian agent can try and find the fit.How does this fit into your existing knowledge base?It'll check the context connections and draft an entry for you for your review to see is this good enough for it to make it into your knowledge base, into your curated library?If it's not good enough, you can suggest revisions and the librarian will update the draft entry and then pass it back to you for review.
Once you approve it, the librarian can then file it into the library and connect it to the rest of your research.And as a more complex system, we can actually start linking these loops together.For example, you can propose a question or a topic to the researcher.The researcher can go through a research loop, checking sources, checking it against the quality that you've given.This could be a goal loop.And then when it's done all of its research, it can pass it off to you as the human to validate that the information is good enough.You can add your own notes, connect it to that cited source and report, and then hand it off to the librarian.The librarian can then see how that fits into your existing knowledge base and prepare a draft for your review on whether or not it should make it into the library.
Again, you can go through a curation loop, but this one has a human in the loop as part of the core loop itself.Once you've approved it, the librarian can then go and file this into the library.And then as a coding example, let's say you're building an app and you want to add the ability to export to markdown.You can hand this off to your orchestrator and explain what you're looking for, and the orchestrator can understand it and then delegate it to the implementer.The implementer can then go through a goal loop where it builds it checks to see if it works, and if it doesn't, then it repairs it and then it checks it again.So it can loop as many times as you want until the task is actually done.Once it's done, you can pass it off to a reviewer for an independent review, kind of like a second version of the implementer, but specifically for quality assurance, who can then pass it off to the Orchestrator and check to make sure it matches the original goal.
If it does, then it can hand it off to you for either a pull request or for you to do something with that particular output.In the original research, the Hermes corroboration actually surfaced that Kanban is Hermes durable alternative with name profiles, shared state dependencies, retries, and work that survives the lead session.So what that means is it's a lot easier to start and stop and add more tasks and modify and just it gives you a lot more control on the actual task system that's happening here and the way the different agents fit into it.That's why it's called a task graph.But you might be wondering, isn't that kind of similar to what I already showed you, where we have the Orchestrator or the main agent delegating to subagents?
Compares Kanban to delegated subagents, emphasizing persistence, resumability, human-in-the-loop control, and database-backed transparency. The speaker then walks through enabling Kanban and the meaning of its task states.
Speaker A
So the Hermes docs has a good breakdown here of what the difference is, because they are actually quite different systems.In Delegate Task, the parent is blocked from doing things until the sub agent actually returns.Whereas in Kanban the orchestrator can just set the agent off, can assign the task, and it can just go and do its own thing and you don't have to have anything make it back to the Orchestrator unless you want it to.Rather than having some random anonymous sub agent that starts from scratch, you have a named profile with persistent memory.So that's a pretty important element.
Also for resumability, if the sub agent fails to do its task, it's just done.It just comes back and says incomplete.Whereas in Kanban you can set different types of restoration processes so it can be blocked and unblocked and then rerun again from where it left off.So this is what I mean when I say it's more durable.It has the ability to survive errors and keep going.With subagents you can steer, you can add some feedback, but it's not necessarily actually adding a human in the loop.But in Kanban, we can have specific actions or tasks actually block from happening until the human comes in and says go.And with delegation the audit trail, all of the context can be lost when the system actually compresses.This is what I was talking about with the context window on the bottom here.If this gets compressed, then if there was a sub agent within that compression, you can lose the context associated with it.
Whereas in Kanban it's stored in a SQLite database, so you get access to that forever.You can go back and take a look.So a good summary here is that DelegateTask is a tool call, it's just one function, whereas Kanban is a work queue where every handoff is a row in a database that any profile or human can see and edit.So there's a lot more transparency that happens here, which is why it starts to get into being a proper control graph or task graph.Thankfully Hermes has a built in feature called Kanban.So let's take a look at that.So the first thing we need to do for Kanban is you may not have this appearing on the side here.So we can go up to capabilities and then go over to plugins and we can see that we have three built in plugins that come with Hermes.
The first is bot mode that comes turned on like we've already looked at and the second is the Kanban.So make sure this is turned on here and then you should see this appear on the left hand side.So if we go over to Kanban here, we are not going to be the ones running things.The agent is.All we need to do is put a card into the ready section, assign it to a particular agent and the agent will pick it up in a minute.And there's even a triage section.So this is where if you're not quite sure exactly what the task is, you can have an agent rewrite the idea into a proper task first.
So that's actually a really important part of it.And I'll show you how we can change the settings for that in a moment.So triage is for raw ideas where that the specifier is going to flesh out the spec and then it will move it through the system.To do means it's waiting on dependencies or unassigned.So we can create task and not assign it.And that means the dispatcher won't send it off to go run.We can schedule which is we want a task to run at a particular time.So it could be, for example, check the latest series of emails and see if something has come in that I've been waiting for.If so, then execute the next task.Ready means that the dependencies are satisfied, it's been assigned to a profile and the dispatcher runs it.Running means it's claimed by a worker and an agent's actually working on it.
Block means it's waiting for human input.So this brings that human in the loop.And then review means that there's a review agent specifically checking out the work so you can establish which agent you want to operate as the reviewer.And this is the completed section.But with all that said, why don't we run a quick test task?So I'm going to leave auto decompose triage task turned on and I'm going to click new task.I'm just going to call this test task.I'm going to leave this assigned to the Wanderloot's tutorials assignee and click Create task.So what we should see now is we've added this card to triage and the dispatcher is going to recognize this and hand it over to the auto decomposer within a minute.
And I'll explain all of that in a moment.So triage is a place for raw ideas, where the specifier will flesh it out.So we just saw that it went from this raw idea into running.But this task here is clarify the scope because it sounds like a test.So that's where putting something in triage will automatically assign it to the default that we have set up and it will run over here.
So this should get blocked because this was a task that had no clear outcome.So this is where the human in the loop starts to come in.Because it basically said there's no body, there's no information here, we don't know what they want.So the dispatcher basically runs inside of the Hermes gateway, inside of the backend, and you don't have to install anything, it just checks every 60 seconds.Has there been a new card created?If so, let's move through the Kanban loop.Let's go through the graph.The idea is that once this task gets created as a card, the dispatcher will see, oh, there's a new card.Let me run the system for you.But if we go back to my task for a second, we can see here that we have a rough idea, the specifier will flesh it out.
So we can also see that we have auto decomposed the triage tasks.So this is where if we go over to settings again and inside of models, we go down to auxiliary models.We can see here that we have two different models set, two different auxiliary models that we can control here.The first is the triage specifier and this is the one that will take the idea, the goal that you have, and frame it as a better task, which will then get passed on to the Kanban decomposer to, to break that task into a task graph so you can control what you want these models to be.Here perhaps the specifier is a very lightweight model because you're basically just using text to explain text a little bit better.
But for the decomposer you probably want a much more powerful model.And Hermes Docs actually has a strategy for this where they say decomposing a project, breaking it into well scoped cards, takes frontier level judgment using the most intelligence that you have.But executing a card that has a clear goal, context and handoff doesn't really need that same level of intelligence, especially if it's running in a loop.Workers are where the vast majority of tokens are spent, so that's typically where the cost is.So that's what I'm getting at when I talk about this decomposer here.We can set this model to whatever we want.I could set this for example to GPT6 Astra if I wanted to.And what would happen is now the Kanban decomposer, this decomposer setting that we have here would be using Astray to convert whatever task I put inside of this task card into a series of subtasks that then get assigned to the worker profile, which is Waterloo's tutorials that I currently have set at Terra.
So that's just a really powerful way for you to significantly reduce the cost of your operations by having a powerful planning model and a less powerful execution model or implementer or worker agent.And we can see up at the top here that we have a default board.
So what we can do is we can click on the default, we can rename that board if we want to, or create a new one.So I can for example, create a new board called Test Create Board.And now when I click on this, I can switch between different boards.And what's cool too is within that test board you can assign it to a specific project.So what that means is you can have different tasks and different graphs and different configurations and settings and operations that you want for particular boards.
And all of that can be controlled at the project level.So you can create a new project.Like for example, maybe one is your admin project and it deals with everything related to email.Maybe another one is a research project and it deals with all of your research that you're bringing in.Maybe another is for a particular coding project or app that you're working on, and all of that can maintain the context within this particular project.
And then you can assign a particular board associated with that project to run these tasks.
Demonstrates creating and decomposing tasks in Kanban, including model selection, cost estimation, and board/project setup. The speaker shows how tasks move through the system and how orchestration settings affect execution.
Speaker A
So we can open up the orchestration settings here.And what that does is it brings up a list of all of the profiles.It brings up all of the different bots or agents that we have available with all of the particular settings and skills and memory and context that we were talking about earlier.Each of these operates as a different specialized agent.
So there's a few key settings we need to take a look at.The first is the Orchestrator profile.So right now it's defaulting to default.You can change which agent you want to operate as your orchestrator.This is the orchestrating agent that will decide which agent gets which task, and those tasks get assigned to the assignee, which you can set which one you want to be the default.Maybe I want to create an implementer profile whose sole job is to execute on things in a similar way that the researcher is the one that researches things and the librarian is the one that files things in my LLM wiki.
So for this one I'm going to leave on auto decompose, just so you can see how this works.I'm going to click new task.I'm going to call it Multi Agent Research, and I'm going to include the description of the same prompt that I gave previously.So here we can set the priority.This basically just controls the order if you have multiple tasks going in there at once, and then we can have the workspace that we want it to run in.I'm going to leave the current assignee as the Wanderloods tutorials as the default, even though I'm asking for research.So this is where the task decomposer should be able to recognize that this is actually a research task, not an implementation task.For the tutorials agent, I can list specific skills if I want, I can change the model that I want this to run at, or just have it run at the profile default.
And importantly, I can have this run on goal mode.So by default, each worker agent gets one shot at its card to do the work.But turning goal mode into true for that particular task lets that worker run in a goal loop like I've already shown you.And this is its own self contained goal loop.It doesn't connect to the existing goal that we have elsewhere.And what's cool too is we can also estimate the cost of what this task is going to be.So I can Click estimate.And then it, it gives me a list of the tokens that it thinks is going to cost for this particular prompt here.So it took this task and it analyzed it to give you an estimate.So it says it's going to be a broad, ambiguous research task requiring extensive source review, synthesis, architecture comparison, and likely iterative documentation or prototyping.
So now, for example, I can include a limitation here of please limit your search to five sources and the output document to 500 words or less.And then I can re estimate it.There we go.It just dropped from 45,000 tokens down to 18,000.There's a rough estimate researching up to five sources, comparing this particular task and then a synthesis and 500 words.And that dropped the complexity of this task down to medium.That's a cool way for you to do a lightweight check ahead of time to make sure that your task isn't going to blow through your whole quota.So now let's click Create Task.And this brings up the board that I was talking about.The triage section is where raw ideas we have a specifier that's going to flesh out the spec.So it's going to be converted from this into a different card.
And this is using that auxiliary model that I was talking about.Okay, here we go.So it just started.So that triage using the auto decomposer, the dispatcher checked, oh, it's been a minute, there's something here.Let's break it into two different tasks.So the task decomposer broke it up and assigned it to these particular sub agents where each one is now running on its own.And we can click into this and we can see the specific prompt that was given to it created by the auto decomposer.Using the default model, we can estimate the effort of this particular task, like I was just showing you, and we can comment.So as these tasks are currently running, we can actually send messages to the worker.And if there's a big enough change, we can even send a message and then re queue it and have it start that task over again.
So we get a chance to go through and see how all of this is working, what it's actually doing, how it's analyzing it.And we can see this for each card that's running here.So you get a lot of flexibility for controlling these cards here.And what's cool too is, for example, I can go back to the to do section, which are the currently blocked tasks.So these ones are waiting for the researcher to finish before they run and we can See, this one was actually assigned to default instead of Orchestrator.So I'm going to change the assignee from default here back to Orchestrator.And now we can see that changed the card over here as well.So I think it's just such a cool way for us to be able to take a look at how all of the tasks are broken up into their individual actions and see how they move through the Kanban.
And you can kind of just get a sense on how all of the project is working together.And that's just for one card.I can now add a second card and it can start running itself and keep going from here.
So you can really start to plan out.Maybe you have five or six or 10 or 20 tasks that you want to run.You can put them all in here, you can schedule them, you can let the agent know that some are waiting on others.There's a lot that you can do here.And it just takes a lot of that sub agent delegation that we were talking about in the first couple examples and makes it a lot more transparent and controllable.And that's why it's called a control graph or a task graph, because we can actually see the graph of how this is operating, what needs to be done first before the next task can be accomplished.So this one is still running here, but we can see this one finished.We can go through and see the full activity.So we can see that it was created and then promoted to ready to run.
And then it was claimed by a worker, which is this researcher agent.It ran through, completed it and it created a briefing doc that was saved right here.It only reviewed two sources because it was given a two source limit and it maintained everything.Okay, and it looks like the second one just finished as well.And now we can see that the Orchestrator task just moved from to do to ready.So once it's going from ready, once the dispatcher ticks in 60 seconds or so, it should get put over to running.And there we go.So basically we had those two researcher tasks and once they were finished, the to do of delivering the report was unblocked because the previous tasks were completed.And then once that was unblocked, the dispatcher running in the background moved it over to ready.And then once it was ready, it shifted it into running.
And again we can see all of this was done by the auto decomposer and here's the specific prompt.So it's pretty complex here.This is where it's important to be really strategic with the information and the tools.And the memory and the context, the skills and everything that you're giving to your specialized agents because you don't want to accidentally have them blow through your entire quota because you gave them more than they needed.So that's one of the dangers of running all of this autonomously, is that you might be giving these agents more than they need.So it's up to you to go through and experiment and test and just make sure that you're able to be more specific and strategic with how you want to set up these task graphs and how you want to run them.So that task just completed right here.
And now we have multi agent research ready.So we had the researcher run, create its research report, pass it off to the orchestrator, who then constructed a 500 word or less recommendation and then pass it back to the original prompt that I had put in here called multi agent research.And now this should be answered by it passing along the document that was created.Great, there we go.So now the dispatcher is running again the multi agent research.My original question that was created by me and now it's going to give me the report.Great.And everything is now done.And this is the report that it created from incoming information to action and reusable knowledge, which is the theme that we've been working with today.So you can see it's 484 words, it's limited to five sources and it gave a pretty solid recommendation.
Have a single accountable lead agent with bounded delegation is the best default.Use a manager style orchestration to keep one owner for state and a final output while allowing scoped specialists Use a persistent team only when measurement shows sustained independent parallel work.So again, this is basically the same answer as what we had before.So now let's quickly break down what just happened here before I explain the alternative option.
So this is the original prompt that I gave and what happened is you can see this was created by Dashboard.So this was created by me, I assigned it to the orchestrator and I gave it this particular prompt.Then we can see that the auto decomposer commented and said, hey, I decomposed, I broke up this task into these three subtasks.These were the two research tasks and then the writing of the article task, the root, this question here, this task will wake once all the children complete.So it took that description, it broke it into those three subtasks, it went through and ran.The researcher went into running, completed its two tasks here, sent it back to the orchestrator to write the article, which honestly, in the future I would probably have an implementer agent or a writing agent who specialized with this, leaving the Orchestrator to just deal with orchestration.
So that's one change I'm going to make.And then it gave the summary here, so it accepted the deliverable.The final is 485 words.All the sources check out.And here's the simple recommendation.So, honestly, that worked pretty well.But maybe we didn't need two researcher agents.That's a little bit of overkill for a five source limitation that probably used up more tokens than what we needed here.This is where if we close this and we go back to our Orchestration settings, we can start moving beyond this auto decomposer.
Explains the tradeoff between automatic decomposition and using the orchestrator as planner, then reviews the test results. The conclusion is to start simple and add coordination only when it clearly improves the workflow.
Speaker A
So this is where instead we can turn it off and we could let the Orchestrator be the one to decompose the triage tasks.So why would you want to do that?Well, my Orchestrator has a specific soul associated with it.If I go here and click Edit Soul, I have very specific instructions on how I want the Orchestrator to work, how I want it to coordinate my team, who I want it to work with.I can put limits, I can connect specific memories.
There's more context that can be given here from the Orchestrator profile than just the auto decomposer, which doesn't necessarily have that same level of context.This is just automatic mode.This is more of a curated mode.And it doesn't even have to go through triage.Instead it can just go straight into ready.But if we want to use the Orchestrator to operate as the task decomposer, we need to give it specific Kanban skills.So if I go over to Orchestrator and then we go to capabilities we can see here.If I go to tools again and then to task, I've turned off task delegation.So basically what that means is I've removed the ability of the Orchestrator agent to be able to create those delegated sub agents.Instead, I want the Orchestrator to run the Kanban board so I can turn on these tools here.
And what that does is if we go back over to Kanban by having auto decompose turned off and the Orchestrator turned on as the orchestration profile.With the Kanban tools, the Orchestrator will now break apart the tasks and then assign it to the particular profiles, defaulting to the default assignee here.So automatic decomposition buys you convenience.It's really easy.You just type in the task and click go and Hermes will break it down for you.
But creating my own planner as the orchestration profile, the Orchestrator Gives me a lot more deliberate control over the task design, the roles and the review.It's not that one necessarily has to be lower cost than the other.It depends on the task, the complexity and how much control you want to maintain and how the system operates.The real benefit is continuity.I can return tomorrow, I can see what's blocked, I can inspect the handoff, and I can resume without reconstructing the conversation or trying to set off more sub agents.
So the orchestrator plans, the dispatcher starts the system saying we're ready for work, and then the worker executes on the tasks assigned to it.So you can kind of think of each card as work units, not necessarily different agents.But a card can use helpers or contain a goal loop in and of itself.So if we were to do that again, we set which orchestration profile we want, what default assignee we want.But instead of creating a new card in triage here, new task in triage, it would just sit here forever because the dispatcher doesn't have the auto decomposer to break that single task into the series of subtasks that then would be put into Ready.I'm not going to go through that orchestration example.The key difference is that rather than dropping something into triage, you can either put it into todo and then wait until you're ready.
You can schedule it, or if you want to trigger the orchestrator right away, you would drop the new task in Ready and let it deal with the task decomposition instead of letting the auto decomposer do it.But I actually tested out the different scenarios to see which works best.So why don't we take a quick look at the results of my testing?
So my thought was there's a lot of different coordination methods here.Which one actually makes the most sense?The results showed that a single agent with task delegation for a simple task at least, and running the orchestrator without the auto decomposer actually had pretty similar token use usage and pretty similar quality.But using the auto decomposer and adding the goal loop actually added more overhead for this particular task.So this is obviously a very simple example.It's not by any means a proper benchmark.I just wanted to see how this worked for a particular research task for me.And one thing to keep in mind is that even if the workflow in the Kanban takes more tokens, it might be worth it because you can go through and take a look at what was actually done.So it gives you more transparency.The actual right choice just depends on what your workflow really needs.
So I'm going to keep exploring this more.I'm going to try and do some more complex Kanban systems with coding so I can actually see what makes sense for my own workflows, how we can leverage the orchestration and control graphs that Hermes has built into it.So do you need an agent team?Not necessarily.Start with the simplest level that actually meets your needs and then add coordination and complexity as you find yourself actually needing more.You want to find a specific problem that that extra coordination and effort is going to actually solve.Now today's example was a very simple one.Next we'll get more into how subagents, loops and graphs can fit together to solve more complex workflows.What workflow would be the most helpful for you?Please let me know in the comments and I'm happy to explore these topics more in future videos.
If you found this video helpful, please like and subscribe as I really appreciate it and please consider joining my memberships.My members enable me to continue making free videos like this one.Thanks again for watching and I will see you in the next video.