Is Hermes Bot Mode Worth It? 🧠 My Best Practices (So Far)

Explore Hermes Bot Mode to create specialist agent teams for efficient workflows and bot-to-bot communication.

Key Takeaways

Hermes Bot Mode enables multiple specialist bots to communicate and coordinate tasks autonomously.
Specialization and pruning unnecessary capabilities improve efficiency and reduce token consumption.
Creating distinct bot profiles with clear roles enhances workflow management and task delegation.
Group chats facilitate seamless bot-to-bot messaging and collaborative task execution.
Human oversight remains important for final decision-making and quality control.

What the video covers

Introduction to Hermes Bot Mode and its feature allowing specialist agents to communicate and coordinate tasks.
Explanation of how traditionally one human connects different agents, but bot mode enables agent-to-agent communication.
Overview of creating specialist bots with unique profiles, skills, memories, and tools tailored to specific workflows.
Detailed walkthrough of setting up an orchestrator, researcher, and librarian bot to run a coordinated research experiment.
Discussion on the importance of removing unnecessary capabilities to improve efficiency and reduce token usage.
Demonstration of creating new bots, customizing avatars, and defining bot personas with descriptions instead of manual soul.md files.
Explanation of how the orchestrator bot manages task delegation, reviews work, and requests revisions.
Testing the bot team in a group chat environment to observe communication, task completion, and workflow improvements.
Insights on using different model qualities for various bots to optimize performance and cost.
Summary of benefits and practical best practices for using Hermes Bot Mode to improve agent workflows.

Chapters

What is Hermes Bot Mode?

Hermes Bot Mode is a feature that allows multiple specialist AI agents to communicate and coordinate tasks together, creating a team of bots with distinct roles.

How do specialist bots improve efficiency?

By assigning specific roles and pruning unnecessary capabilities, specialist bots reduce redundant tool calls and token usage, resulting in more efficient workflows.

Can humans still intervene in the bot workflows?

Yes, humans remain in the loop to oversee the process, review outputs, and make final decisions, ensuring quality control and appropriate task delegation.

Full Transcript — Download SRT & Markdown

Speaker A

I'm going to tag the orchestrator. Please help me with this research. The orchestrator tagged the researcher, and the researcher is now thinking about what it needs to do. When I use different agents for different jobs, usually I'm the one that ends up connecting it all

Speaker A

together, passing work between chats, checking the results, and then deciding on the next steps. But what if the agents could communicate together and coordinate the work? Hermes has a new feature called bot mode, where specialist agents can communicate and

Speaker A

work together. Today, I'm going to test it out by assembling a team of specialists, giving them one shared task, and then seeing what works and what doesn't. Hi, my name is Callum, also known as Waterloots, and welcome to

Speaker A

today's video on Hermes bot mode. Assembling teams of agents and bot-to-bot communication. By the end of this video, you'll understand how to create specialist bots, how to choose the capabilities each one needs, and more importantly, what each one doesn't need,

Speaker A

the essential settings that help the team run efficiently, and how to bring them together into a shared conversation to run a research experiment. The experiment I'm going through today involves setting up a researcher, an orchestrator, and connecting them to my

Speaker A

existing librarian. But this process works for any type of specialist agent. You can apply this to coding, writing, finances. Any type of predefined workflow with a specific job will work as part of this system. There's no limit to specializing your agents, and that's

Speaker A

kind of the point of bot mode. You can think of each bot as a specialist with its own workstation. Its profile holds its instructions, model, tools, skills, and memory. Rather than giving one bot everything, we can distribute the work amongst a bunch of

Speaker A

specialists and have them coordinate together, working on what each bot does best. And importantly, we can also remove unnecessary capabilities, which can lead to extra tool calls and longer runs, using more tokens, and eating into your quota and your budget. So, it's not

Speaker A

just about specialization, it's also about efficiency. In our example, the orchestrator coordinates, the researcher investigates, and the librarian organizes the approved knowledge. A report can go back for revision, and then I can decide when it's ready to actually move forward. It's an agent

Speaker A

team of specialists, but bringing a human into the loop. And that's what I want to test today with Hermes bot mode.

Speaker A

Does delegating specific tasks and jobs and capabilities to specialist agents and then coordinating them together in a single team actually improve my workflow and efficiency? If you find this video helpful, please like, hype, and subscribe as I really appreciate your

Speaker A

support. To accompany this video, I also created a free Patreon article that I'll link in the top comment that goes through more of the setup, the workflow, and how this all comes together to help you make your own setup more efficient.

Speaker A

Now, let's check out Hermes bot mode. So, when we first get into Hermes, we can see up in the top left, we have sessions. And this is what you might be familiar with. This is where you just have a conversation with the Hermes

Speaker A

agent, and the sessions get stored on the side here under your projects, under your particular profile. But we also have this new mode called bots. And the key here is that this is not a new primitive to learn. A bot is a Hermes

Speaker A

profile. So I'll get into what that means a little bit with all of these more specific features here. But the key difference here is that rather than dealing with one profile that is loaded at a time, we can see I just switched to

Speaker A

my librarian profile and I can only add one conversation here and then I have to go back and switch to a different profile to start another chat over there. They can work in parallel, but I have to be the one manually switching

Speaker A

between them. Instead, what we can do is we can go over to bot mode. So let's take a look at that.

Speaker A

So in bot mode, we get all of those different profiles that you just saw below on the side here. And each one of these gets its own dedicated bot chat.

Speaker A

See, if I right-click on Hermes, this is my default profile. It says open bot chat. And this is different than having a new chat with this bot. We can see here on Hermes, we have a default, "Hey,

Speaker A

tell me about yourself," that was created when I first opened the bot. And it explains what this particular bot is able to do, what this profile is able to do. Switching into bot mode changes the way that we can think about how we're

Speaker A

communicating, where the agents are able to communicate with one another. For example, I can go to the default Hermes profile and I can type in @librarian and I would be able to tag and mention that specific bot and ask it to do

Speaker A

something. So, we'll get into that a little bit more in a few minutes. I just really wanted to emphasize not only are we able to create new bots, new profiles, we're also able to create new group chats. So this agent-to-agent

Speaker A

communication, the bot-to-bot messaging that happens in here is a way for you to specialize each individual bot for a particular type of workflow, but have them communicate with each other. Rather than being one universal agent, they're a team that has various skills. So the

Speaker A

first specialized agent that I built is the librarian, and that's the one that I talked about in my last video. So today, I want to add two more bots that we can use to create our first group chat, the

Speaker A

orchestrator and the researcher. So, let's create the orchestrator bot. So, I'm going to click new bot here.

Speaker A

Each bot is a named teammate with its own memory, skills, and chat, and it can message your other agents. So, I'll touch on each of those in a few minutes.

Speaker A

So, the first thing we can do is we can control the profile picture. You can generate your own by just describing it.

Speaker A

You can upload your own or you can choose a pet. So, here are some built-in pets, and for example, you could look for something like Pikachu and get a Pokémon or you could get something like Socky, which is clearly a Dobby. And

Speaker A

these would be more animated characters. This all comes from something called pet decks that you can build your own, too.

Speaker A

And there's thousands and thousands of these that you can download yourself. And then you can give this avatar to one of your bots. So, I think that's just a pretty fun way to be able to customize it. Let's go with this one for my

Speaker A

orchestrator. Why not? The next thing we need to do is we need to create our name. So, I'm going to call this one Orchestrator, and I'm going to give it the title of Orchestrator. So, one of these is what will be presented on the

Speaker A

side, and the other is how you're going to be able to mention it using that @ symbol. And then we get to the description. So, this is where the way that they've built the bot mode is actually a lot more user-friendly than

Speaker A

the profile creation because previously you would have to manually create the soul.md. And I'll show you what that looks like in a moment. You can think of the soul as the persona. It defines how this particular teammate behaves. It

Speaker A

gives it an understanding of the capabilities to determine what it can actually do. So, for example, the orchestrator is going to be something related to orchestration or conducting or being a head of staff or a chief of staff. But what's cool is if we leave

Speaker A

this blank, Hermes will automatically generate this from the name, title, and description and then add it to the agent messaging roster. Rather than having to craft the soul ourselves, we can just put in a description here. So the

Speaker A

orchestrator is going to coordinate my team. I want it to clarify the outcome and acceptance criteria. It should delegate research to the researcher, which we'll create next. Review returned work for relevance, completeness, citations, uncertainty, unresolved gaps, and it should request one focused

Speaker A

revision when necessary. It then can hand accepted work over to

Speaker A

memory. So if any of that was confusing, I have a video here that goes deeper into using agent memory. But basically what I want to do is I want to have my orchestrator able to connect to my external memory and I'm going to limit

Speaker A

the memory of the researcher so that it can't do that. So I only have one agent here that's going to be writing approved memories. Great. So then we can go down from the description. I'm going to click clone from default for now because this

Speaker A

is going to bring in a lot of what I've already built in my default profile provider. This is basically building the brain of the system. So if the profile is the configuration, the provider is which model you can connect to it. So

Speaker A

again, I'm just going to leave this as inherit from provider. I'll show you a little bit more about that in a moment.

Speaker A

And then I'm going to leave the sole blank. You also have the option to create this as a completely empty system with no bundled skills, but I want this one to have the bundled skills, so I'm going to give it that. Let's click

Speaker A

create bot. There we go. So, we can see it's waking up the orchestrator. So, we now have the orchestrator has been created. So, we can see up in the top left, we have the name, which is what I

Speaker A

gave it, the at, which is the way to mention it. That's the lowercase one.

Speaker A

And we can see that it's operating on this device. So that's also one key element here is that not only can we have different bots communicating with each other, but we can connect different bots to different devices. So I could

Speaker A

have one bot running on my laptop and another one on my desktop and they could be communicating through each other. So each one lives in its own separate place, but it can pass information. So we can see here now we have I'm the

Speaker A

orchestrator, your coordination focused AI teammate inside of Hermes. So, it's best at clarifying outcomes, delegating research, quality control, coordinating knowledge, taking real action, using tools to research, build, run, and verify things, not merely suggesting what could be done. So, that sounds a

Speaker A

little bit like a problem because we're going to be building in a dedicated researcher. So, we don't necessarily want to do this. So, we might need to tweak this a little bit. I'll make sensible, low-risk decisions independently, but pause when something

Speaker A

consequential needs your judgment. That's exactly what I would hope for in an orchestrator agent or bot. So this is all happening inside of the bot chat. If we go back to sessions here and go over to orchestrator, we can see that that

Speaker A

bot chat doesn't exist on the side here. So that's only inside of bot mode, but we can create new sessions here in whatever folder or project you want with this orchestrator bot as well. So this is the canonical bot chat. It's a

Speaker A

forever chat. If you type in / new or reset, it just compacts it instead of creating a new one. So the bots tab is for you to communicate with your agents and have them communicate with each other. The sessions tab is for you to do

Speaker A

dedicated work with a particular profile or bot. But I wanted to come back over here because it's easy for me to now rightclick on this profile on the bot and click edit soul.md.

Speaker A

So if we click on that, we can see what was automatically generated as part of this system here. This is built on the name and the description that I gave this bot. And then Hermes automatically built a solem file for it. So honestly,

Speaker A

this sounds pretty similar to the description that I gave it. probably because my description was pretty thorough. But this is where if you want you can edit it. Okay, so I'm going to add a little bit more here on a team

Speaker A

protocol for the orchestrator. So I want it to always state the outcome, acceptance criteria, owner, deliverable, and stop condition. So this is just a way to give a little bit more context for the orchestrator to understand the way I want it to communicate with me.

Speaker A

And then I also wanted to add this in here to limit it from being able to do its own research so that it always remembers to delegate to the researcher rather than trying to do another specialist's work. And I have do not

Speaker A

write to the LLM wiki because that's going to be the responsibility of the librarian. So now I can click save soul.md. We can see it was saved for the orchestrator. And now what I can do is I can restart the gateway just to make

Speaker A

sure that comes into effect. Perfect. So we can see I said I just updated your soul file. How does your understanding change? So it says it understands that it should do the definition for working with different people. Delegate

Speaker A

specialist research and wait for my approval before the librarian. That all sounds excellent. So far what we've dealt with as part of the anatomy of the bot or the profile. We touched on the identity. There's still the brain, the

Speaker A

capabilities, memory system, and operations. But before I get into those, I want to add the next member of our team. So, let's build the researcher.

Speaker A

All right. So, for the researcher, I just uploaded my own profile picture. Gave it the name researcher for how I'm going to tag it, the title for how I want it to appear on the side, and then the description where I wanted to

Speaker A

investigate current reality questions using current and original sources, produce cited briefings. That's important. We want it to ground its answers with actual research and include uncertainty, counter evidence, gaps, and then return them to the orchestrator for quality review. Do not write to the

Speaker A

wiki. Perfect. And let's click create bot. Okay, so we now have the researcher waking up here. And if we go back down to sessions and over to researcher, we can click edit soul.md. This is a different soul than what we had before.

Speaker A

So this one investigates bounded current reality questions and then returns to orchestrator does not write to the wiki and some details on its ability to keep its own memory skills and conversation history. So I'm going to add a little

Speaker A

bit more again. I'm going to introduce a research protocol. Specifically I'm going to tell it to save its research as a file under workspace/ressearch which I'll show you in a moment and have more information on how I want it to operate.

Speaker A

So here we go. This is the initial researcher. It says basically everything we saw inside of the soul. And now I'm going to say I updated your soulm. Do you understand the changes? So we can see it went through. It viewed the

Speaker A

Hermes agent which is the underlying skill that makes Hermes what it is to some extent. And we can see that it understands the updated changes. In particular, I don't want it to pass files directly to the librarian. I want

Speaker A

it to default by giving it to the orchestrator. So you can see that just by updating that soul. MD file with some more ground rules, this agent now understands how it fits in with the rest of the team a little bit better. So, now

Speaker A

that you've seen more about the bot and the profile and the identity and how we can change that identity between different bots, let's get into the brain, the capabilities, and the continuity.

Speaker A

So, we can go to settings up in the top right here. And this brings up all of the settings and how we can modify it for each of the different profiles or each of the different bots that we have.

Speaker A

So, for example, if we go over to the researcher, we get an at a glance view of everything that's happening inside of the brain of this particular bot. So right now it's connected to my chat GPT my codec subscription. I have it

Speaker A

defaulting to 5.6 soul which I could looks like I can oh looks like I actually just got access to Astra literally since the start of this video.

Speaker A

So I'll have to test that out later. But you can control which model you want access to. You can give it specific limits. You can set its default reasoning. This is controlling the brain. And Hermes has actually made it

Speaker A

easier than ever now to work with local models. So this is where you could default select a local model to run a particular task. Like maybe my librarian because it's not accessing the internet and it's just processing information

Speaker A

from other bots. I could configure this to run a local model. So if you click on configure, we can see that Hermes by default now checks the specs of your device and then gives you suggested models that you could run that fits your

Speaker A

GPU and your potential workflow. So I could go down and search for a model like Gemma 4. I could pick one that fits my machine. And if I click show files, it finds the specific version of the local model that actually fits your

Speaker A

computer. So that's just made it so much easier than ever for you to not only create a bot, but now select with each specific bot what model you want to access and whether you want it to be a

Speaker A

cloud or a local model. So maybe for the researcher, I don't think it really needs to be operating on soul. That's probably overkill. So I'm going to downgrade it to Terra. Click apply. And then you could do the same for all of

Speaker A

the other ones as well. Like maybe orchestrator I want on a higher model. researcher, librarian, they can be on lower models. So that gives the brain.

Speaker A

Next, I want to look at the capabilities. So now we're getting into capabilities of our agents. The soul describes the bot's role, how it fits into the rest of the team. A skill describes a reusable method, a workflow, and tools enable the

Speaker A

workflow to actually take action. And this is where more bots is not necessarily better. Each bot needs a clear job, clear responsibilities, and an understanding on how it fits into the bigger picture of the team that you're building. So this is where if we go back

Speaker A

to sessions for a moment we can see we have capabilities on the side here and we have the option to connect skills tools and MCP which is external tools.

Speaker A

So a cool part about using Hermes is that it learns its own skills over time but every agent doesn't need access to every skill in every tool. I can go over to the researcher bot and for example we

Speaker A

know that we don't want it to have access to the LLM wiki because this is something that falls only under the responsibility of the librarian. So, I can just turn this skill right off. For whatever skill you don't want it to have

Speaker A

access to, you can just turn it off. So, you can go through and you can prune all the skills you don't want it to have access to. And an important one that I want to leave on is grounded citations

Speaker A

because what this does is it lets the agent basically create footnotes throughout its research so that you can track where the sources came from. So, that sounds like a perfect skill that I would want my researcher to have. The

Speaker A

key thing to remember about skills is that they are not loaded all the time.

Speaker A

They are lazy loaded or progressively loaded where the agent only loads the skill when it feels it needs to. So skills are like repeatable workflows.

Speaker A

Tools are more actual operations like write file, read file, check browser. So these two work together where skills can call tools. Tools are a little bit different because tools they can access whenever they need to. And this is

Speaker A

actually me recording from the future where I tested a few things out. So we can see for example which tools the researcher used in my previous test. But the key here is that a good bot isn't just a general agent. The goal is that

Speaker A

each bot each agent has one job and then we give it specifically the capabilities required for that job. All of the numbers here that you can see for researcher and for orchestrator and for the librarian. These are all counters

Speaker A

that show what the bots attempted when they inherited all of the broad defaults when I gave them access to every tool.

Speaker A

but frequent tool use here. This high number doesn't actually mean that it was necessary for the researcher to do. So, as part of best practices before we actually start running some tests, I highly recommend that you tighten the

Speaker A

responsibilities and the tools associated with each of your agents, with each of your bots, so that way they don't unnecessarily make tool calls that they don't need. For example, in my previous test, the researcher ran task delegation where it tried to create a

Speaker A

sub agent six times. in my test that meant that it looped for an extra 20 minutes. That's not what we want. So, it's actually incredibly important to realize what we don't need because some of these tools can take 10 or 15 or 20

Speaker A

minutes to run and it can really slow down everything. So, I'm just going to turn off a few here like the task delegation, code execution, session search, and I'm going to turn off cron jobs. This is basically automation

Speaker A

skills. That's something that should be on the orchestrator, not on the researcher, but I'm going to leave on vision terminal so that it's able to process things. skills so it can find skills that I give it in the future, the

Speaker A

ability to work with files and the ability to search the web. And I'll leave on browser automation just in case. But you can see that already limited a bunch of tools that it had called previously in my tests. And I

Speaker A

should also do this on the orchestrator as well. So if the point of the orchestrator is that it's going to delegate tasks to the researcher, it shouldn't need access to the web. So I'm going to turn that off. I do want it to

Speaker A

be able to search past conversations. So that's good. I don't want it to delegate to sub agents. It shouldn't need to click on the browser. doesn't need to use the computer. So, you can see how I'm going through and I'm limiting what

Speaker A

each of these bots has access to. So, I'm going to keep doing that and I'll include a full list of what I enabled and disabled for each of the three bots in the free Patreon article that I'll link in the top comment.

Speaker A

Then, we get to MCP. MCP is model context protocol. This is just a way that we can connect to external tools.

Speaker A

And in the next video, I'm going to show you how we can bring in some heavily specialized research tools through MCP and skills to be able to connect our researcher to even more powerful external tools. So that completes

Speaker A

capabilities. Then I want to get briefly into continuity, which is basically just memory. How does our agent remember what it's doing?

Speaker A

So if we go back to settings here, we can go down to memory and context. We're still on the researcher bot right here.

Speaker A

And we can see I have persistent memory and user profile turned on. So basically what this means is there's a memory MD file and a user.m MD file that the researcher can write memories to and write its understanding of what I'm

Speaker A

asking for so that it slowly improves itself over time. So I recommend having these on, but you can also get into external memories like hindsight. And hindsight is a much more powerful memory engine that can connect all of your

Speaker A

different projects or different bots or different users together in one place and extract insights and reference old information. And it's honestly a super powerful tool, but it's not something that my researcher needs access to. My researcher is wanting to go get

Speaker A

information from the internet and then bring it back in. It doesn't need to access all of my other memories. So for this one, I'm going to leave this as built-in memory only. So this is a key element that we don't necessarily want

Speaker A

to have all of our bots writing to the same memory system because they might be conflicting with one another. Instead, I'll leave that ability, the external memory provider on orchestrator so that as my librarian and my researcher work

Speaker A

together with the orchestrator, the orchestrator will be the only one able to write to that external memory system.

Speaker A

So that sets up the private memory continuity and history. And then finally, we get into operations here.

Speaker A

So operations can be as simple or complex as you want. For example, if we go down to advanced, I currently have my terminal execution backend for all of my models running in Docker, which means that each agent gets its own isolated

Speaker A

place to write code if it needs to to run its browser to do the things I want it to do, and it helps protect my computer. So, I have a dedicated video that goes more into Docker if you're

Speaker A

interested in learning how to isolate your agents. But, we also have the workspace up here, which is the working directory. And basically, what this means is you can control which folder your agent has access to. So, for me,

Speaker A

I'm going to leave them all inside of my root workspace, but you could limit this if you want to. And this is where, if we take a look at the soul.md of the researcher, I added a workspace/ressearch folder. So, we can kind of think of the

Speaker A

workspace as a place for all of the different bots to come together and share information so that they can pass files and ideas back and forth with one another while mentioning each other in the group chat.

Speaker A

And then one more very important setting to turn on for best practices is you can see that I was clicking through the wiki skill which is the current librarian, the orchestrator and the researcher and it's able to load quite quickly. That's

Speaker A

because inside of settings under advanced we have this option here to keep bots warm which is basically how many bots can stay running for instant switching over time. It takes up a little bit more RAM, a bit more memory,

Speaker A

but I switch this from three to five because I have my default profile and then a couple others that I tend to switch between. And this significantly increased the speed of how the bots are able to work between each other. You can

Speaker A

also make sure that the bot backend idle timeout takes a little bit longer. So 10 minutes is pretty decent unless you have some long running group chats or long running sessions. So you can always increase this to a higher number if you

Speaker A

want to to make sure that not only you have all of the bots you need, but that they stay on for as long as you need them. Okay, so now we have our bots configured. We've updated their souls.

Speaker A

We've checked out skills and tools to see what capabilities they have. We've limited access to specific bots. Now, I want to quickly go through the different ways that we can communicate with these bots and how they can communicate with

Speaker A

each other. The first way that I've already shown you is individual bot chat. We can just message each individual bot directly and have a conversation with it. So, this is one chat that is permanent and we can compact it over time by putting slash

Speaker A

new and it would compress this chat specifically instead of creating a new chat. And that's only for the bot mode.

Speaker A

But the next way that we can have the bots communicate is they can communicate with each other. So when I was testing this earlier, the researcher was messaging the orchestrator, telling it what it was up to based on the task that

Speaker A

the orchestrator had given it. Kind of like direct messaging between bots where they can give each other tasks and keep each other updated. So that's a pretty powerful use. But a problem with that is we can see here the researcher sent the

Speaker A

orchestrator four messages in a row. It's entirely possible that these two get caught in a loop and they run for hours and they burn through your entire quota. If you're running on a cloud model, this is where group rooms come

Speaker A

in, where we're able to create a group chat. And the group chat has a default number of turns that the agents are able to communicate with each other before they require you to come in and actually say what you want to happen next rather

Speaker A

than getting caught in an infinite loop. So, I'll show you that in a moment. So, botto messaging is great for when you have one-off tasks that you want the agents to work together on. And the group room makes sense when you want to

Speaker A

have several specialists sharing one visible huddle that you'll be able to go through and see them all having a conversation in one place. And it prevents the conversation from becoming infinite. And then the last way is if we

Speaker A

go to Cananban, we can have more control over the ownership, revisions, approvals, and just generally more control over complex tasks and building loops into it with goal. But I'll touch on that in another video because that's a little bit more complex. Today I want

Speaker A

to focus on a group chat. So we can see I have two group rooms already in here from previous tests that I ran. So let's create a new group chat.

Speaker A

So a group room shares a conversation. It doesn't share a memory, tools or permissions. So each bot within this conversation remains a separate profile and has its own memory and permissions.

Speaker A

Everything is separate. But we can take the tools of each of these specialist bots and put them in one place. so they can communicate and effectively give a broader skill and tool set even though the skills and tools are limited as I

Speaker A

showed you earlier for each individual bot. So let's add the researcher, the orchestrator, and my skill-based librarian which is separate from my other librarian that I talked about in the trust video. I'll call this research team limited tools because for this test

Speaker A

I have reduced the amount of tools available but create group. So I'm going to say everyone please say hi and give me your specific favorite color. Then orchestrator tell me what each bot's favorite color was. So, we can see that

Speaker A

the researcher said, "My favorite color is deep blue." Orchestrator, here you go. Orchestrator. Wow, that was so much faster than the last time I ran this test. That tool limit really seemed to help. So, we can see the researcher says

Speaker A

his favorite color is deep blue. And it tagged specifically the orchestrator to pass that information on. The orchestrator then replied and said his favorite color is emerald green. It tracked what the researcher had said, but was still waiting on the librarian

Speaker A

or at wiki skill. The librarian's favorite color is sunset orange, apparently. And then it tagged the orchestrator to understand and the orchestrator summarized it all saying here are the three favorite colors of each of the different bots. So that's

Speaker A

perfect. That's exactly what we want. All of these bots are loaded. They are available. The fact that I changed that setting to keep them warm really seemed to make a difference here. And we can also take a look at the activity here to

Speaker A

see what happened throughout the group chat. So this is where I was talking about that limitation in group chats or in group rooms where if these two agents were just messaging each other back and forth, they could potentially go

Speaker A

forever. But here we can see that they replied to one another and the librarian took a look and said, "Hey, I don't need to do anything." The researcher took a look and said, "Hey, I don't need to do

Speaker A

anything." So this turn is settled. So they all just communicated what they needed to. And then they paused and now they are waiting for my review. And that's why the orchestrator was able to tag me and say, "Hey user, here's the

Speaker A

result." So that's perfect. I can now reply and thread here and keep this particular thread going or I can start a new thread in research team. So why don't we run an actual research experiment to see how this works?

Speaker A

So I'm going to tag the orchestrator here and I say I want to understand the state-of-the-art 2026 best practices for agentic workflows with multi- aent teams to improve efficiency and effectiveness across different disciplines. Please help me with this research project. We

Speaker A

should limit this to 10 sources and make the report less than 500 words ensuring that we track citations. So we can see the orchestrator took that information and translated it. It listed specifically the outcome. This is coming from the soul file and the acceptance

Speaker A

that we want including the type of format that we want and it says the owner of this project is the researcher.

Speaker A

So it tagged the researcher and the researcher is now thinking on what it needs to do. And then specifically it mentions don't involve the librarian or at wikiskll. I'll assess it and request at most one focused revision before

Speaker A

asking the user whether anything should be saved. So now we can see the researcher is currently working here.

Speaker A

And basically what's happening I message the orchestrator who then message the researcher and the researcher is going to produce a report and give it back to the orchestrator for review and if needed send it back to the researcher

Speaker A

for one specific quality check loop before passing it on to me for approval. If I approve it, I will then ingest it into my Obsidian LLM wiki. So this can take quite a few minutes depending on the complexity of this task. And this

Speaker A

will just run in the background. This is where having the idle time limit at or above 10 minutes is potentially a good thing because depending on the research, it could take a while. And it's also why I said please limit to 10 sources so

Speaker A

that the researcher isn't running for an hour and everything falls asleep and it just takes a while. So this is up to you to tweak and test and try different types of prompts. Maybe this situation it would have been better to just have

Speaker A

the orchestrator message the researcher directly. These are all experiments that we can run with this new bot mode in Hermes to see what ends up working best.

Speaker A

So, if you have any tips or best practices, please let me know in the comments. I'd love learning more about how you're using these tools.

Speaker A

Okay, so that actually only took 2 minutes. The researcher tagged the orchestrator and said, "I've completed it. Here it is." The key conclusion is that we should have manager specialist teams selectively, which is exactly what we set up here. So, that's good to know.

Speaker A

And then we can see that it created media uh 2026 multi- aent workflows brief. So if we go over to my Hermes workspace, we can see that we have the file here and it gave a summary with 500

Speaker A

words with specific suggestions on how we should be operating here, including the source ledger. So this looks like a pretty great summary and it only used six sources. So it was under its 10 source limit that I requested. Okay, so

Speaker A

now the orchestrator just wants to run a command to read the file. So I'm going to allow it. I think it's just doing this to calculate the number of words because if the orchestrator found oh hey the researcher actually wrote a 2000line

Speaker A

document maybe that failed the validation and it would have to go back and try again. Okay, so we can see the orchestrator said researcher I reviewed it. Everything looks good. One focus revision. The evidence base is vendor authored and contains no 2026 study. So

Speaker A

this is inadequate. Please use up the three remaining source slots for one update. But we can see here that I actually hit the round message cap. So this is where the researcher and the orchestrator have gone back a couple

Speaker A

times and they hit the group chat limit. So again, this is just one benefit and potential detriment of using a group chat is that it has this limit built into it. My guess is that they will allow this to be controlled in the

Speaker A

future, but this is where having them just go back and forth may have been better in this particular situation. But I can just reply here and say at researcher, please continue. So now the researcher received this from the

Speaker A

orchestrator and then I've told it you may continue. So this brings in the human in the loop element where I can control do I want this to keep working or is this sufficient as it is. So I could have told the orchestrator

Speaker A

actually this is sufficient please proceed. But I think that it makes sense that it didn't include a 2026 study. So it should. That's a good quality check by the orchestrator. And this actually comes in from my original prompt that

Speaker A

set the quality standard where I said best state-of-the-art 2026 practices. So now let's see. This might take a moment and it should go and update it. So we can see, yep, orchestrator revised and verified. There's now nine sources. We

Speaker A

added some more words and it added specifically 2025. And this brings in actually an element that I'm going to talk about in a moment as my takeaway from working with this where multi- aent advantages diminish with a stronger base

Speaker A

model. So the models are getting pretty incredible. One of the benefits of using a group chat like this is we can use lower quality models. We could have local models doing all this research and then have the orchestrator be a higher

Speaker A

power model. Great. There we go. So the orchestrator now said I've accepted the revision. This seems good. The uncertainty is closed. We have the report right here. user, please approve or decline handing it to the wiki skill, the librarian for durable storage.

Speaker A

So I'm going to say great, that sounds good. Orchestrator, can you please move this to the library raw, which is the inbox, and then ask the librarian to run the LLM wiki review skill. So this is something that I talk a lot more about

Speaker A

in what is an agentic librarian and I go through an LLM wiki which is just a way of organizing knowledge and having it be managed by an AI agent but then also bringing in a human in the loop for the

Speaker A

review process. So that's using my specific LLM wiki review skill. Great. So we can see that the orchestrator moved the file directly into my LLM wiki here. It includes all the source ledgers, the inline citations, which is exactly what we wanted. That's using the

Speaker A

grounded citation skill. And now what we want to see is right now it is outside of the wiki. It's not connected to the actual wiki right here. It's just in a report. We should see it be proposed as

Speaker A

a review in a moment. Okay, here we go. So the librarian was able to create the proposal and it's saying here is what I think we should add. We should create a note called multi- aent workflows and it's specifically pulling in the

Speaker A

citation of the report that has all of the raw citations connected to it. So if we go back here, we can see that the report is now captured here. And then I can please choose approve, reject, revise, or defer. So like I talked about

Speaker A

more in my last video, this is where I would go through and review this more in depth. So I'm going to say at librarian I approve. If we go over to Obsidian here, we should see this graph change in

Speaker A

a moment as the librarian takes that research report and writes a new file and then connects it to the rest of the wiki. Yeah, there we go. We can just see that multi-agent workflows just appeared and it specifically connects to aentic

Speaker A

memory, Hermes agent, and LLM wiki. and it's specifically referencing the the brief as part of a inline connection and it's saying that here are the related concepts. So this is really where the wiki starts to grow. This librarian here

Speaker A

is just using some basic skills, but I've also built a full librarian that I talked about more in the last video.

Speaker A

So that's great. It looks like the group chat worked. I was able to have the orchestrator communicate with the researcher to run a research task. The orchestrator actually analyzed and found the researcher did not do a good enough

Speaker A

job and forced it to go back and do a better job, which is perfect, especially if I have the researcher running on a less intelligent local model. This is where you can have it do the bulk of the

Speaker A

work of reading all of these sources and the orchestrator becomes quality control and then when it was approved, it passed it on to the librarian and the librarian was able to bring it into the LLM wiki.

Speaker A

So, as an optional next step, normally what you could do is if you're in a chat, you can write refine and it will review the conversation and save what it needs to its own skills and memories.

Speaker A

So, what I'm going to say is at all, can you please update your memory with anything that you learned from this session? So, this is using just that specific memory file. It's not using my external hindsight. So, we can see that

Speaker A

the orchestrator said, "Oh, you know what? We should put the raw reports here. So, let's update the memory." So if I go into my Hermes profiles orchestrator profile and then go check out this memory, we can see that it was

Speaker A

able to update it itself today and add specific information on where the file should be stored before giving it to the librarian. So rather than me now telling it, oh hey, I approve of the file. Can you please move it to this folder? It

Speaker A

will now just remember to do that next time. So that saves me one step of communication. And we can see too looking at the turns here, the researcher also updated its memory file, but the librarian didn't have anything

Speaker A

it learned here. So this is just a good practice to get into where you can tell it to analyze what it just did. So all of that seemed to work particularly well, especially once I made those changes to tools. But now, why don't I

Speaker A

go through a few of my key takeaways and where I see this going next.

Speaker A

So, I honestly think that bot mode is going to take a little bit of work to get it going perfectly, but it definitely has potential. In this specific circumstance, I think that one very capable or highly intelligent agent

Speaker A

probably could have done the same, if not a better job on this particular research flow. The team needs refinement, but that's actually the key here. We can refine this. We can make it better. I can improve the instructions,

Speaker A

the tools, the skill choices, the memories. I can help tweak this system. I can delegate specific tasks or bots to local models so that a more powerful cloud agent like the orchestrator can delegate to local models to do most of

Speaker A

the work and still maintain the same level of quality but significantly reduce the cost. The potential here is to find any type of repeatable work that you have. See how a specialist bot or team can work together to accomplish

Speaker A

that task and then iterate and recalibrate on those workflows until it works at a level that you're actually happy with. So, with that in mind, in the next video, we're going to focus on refining one of these bots to improve

Speaker A

it, the research agent. If you found this video helpful, please like, hype, and subscribe, as I really do appreciate your support a lot. If you're looking for more ways to support me, please consider joining my YouTube or my

Speaker A

Patreon membership. Members get access to tips, insights, and kits on knowledge management and AI workflows. And your support enables me to continue making free videos like this one. So, thank you. Thanks again for watching, and I will see you in the next video.

Topics:Hermes Bot Modespecialist agentsbot-to-bot communicationagent coordinationworkflow automationAI agent teamstask delegationagent specializationgroup chatAI research experiment

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools