DEV Community: Vivek Shetye

Run Hermes Agent Inside Docker: A Safer Setup for Autonomous AI Agents 🐳

Vivek Shetye — Tue, 22 Sep 2026 16:35:22 +0000

Giving an AI agent unrestricted access to your entire computer is probably not a great idea.

Especially when that agent can:

Run terminal commands
Install packages
Create and modify files
Access external services
Work autonomously through multi-step tasks

Those capabilities are exactly what make Hermes Agent powerful.

But they also raise an important question:

Where should all of those actions actually run?

Instead of running Hermes Agent directly on my host machine, I decided to run it inside a Docker container and explicitly control what the agent can access.

The goal isn’t to make Hermes magically “secure” by putting it inside Docker.

The goal is much simpler:

Give the agent access to what it needs, not your entire computer.

In this tutorial, I’ll walk through the complete setup.

We’ll configure:

Hermes Agent inside Docker
Persistent storage for memory, sessions, and configuration
A limited filesystem boundary
Hermes Gateway
Hermes Dashboard
Dashboard authentication
Hermes Desktop connected to the container
Some important security considerations when containerizing autonomous AI agents

🎥 Prefer watching instead?

I walk through the complete setup step-by-step in the video:

Watch the full Hermes Agent Docker tutorial on YouTube →

🤖 Why Run Hermes Agent Inside Docker?

Hermes isn’t just a chatbot.

It can interact with your environment and perform actions on your behalf.

For example, depending on the tools you enable, Hermes can work with files, execute terminal commands, install dependencies, use external services, and autonomously work through tasks.

That’s incredibly useful.

But if the agent runs directly on your main machine, you need to think carefully about what files, credentials, and system resources it can reach.

That’s where Docker becomes useful.

Instead of letting Hermes operate directly across my host environment, I can put it inside a container and explicitly decide what crosses that boundary.

The architecture we’ll build looks roughly like this:

┌──────────────────── HOST MACHINE ────────────────────┐
│                                                      │
│  Docker                                              │
│                                                      │
│  ~/.hermes-docker  ───────────────┐                  │
│                                   │                  │
│                    ┌──────────────▼──────────────┐   │
│                    │      Docker Container       │   │
│                    │                             │   │
│                    │      Hermes Agent           │   │
│                    │                             │   │
│                    │  /opt/data                  │   │
│                    │  Gateway                    │   │
│                    │  Dashboard                  │   │
│                    └─────────────────────────────┘   │
│                                                      │
│  Personal files / SSH keys / other directories       │
│              NOT mounted into container              │
│                                                      │
└──────────────────────────────────────────────────────┘

Hermes gets a dedicated environment and a directory for its persistent data.

The rest of the machine stays outside that boundary unless I explicitly expose something.

🐳 Step 1: Install Docker

On macOS or Windows, install Docker Desktop and make sure the Docker engine is running.

On Linux, you can install Docker Engine using the instructions for your distribution.

You can verify Docker is available with:

docker --version

Once Docker is working, we can create an isolated environment for Hermes.

📁 Step 2: Create a Dedicated Directory for Hermes

First, create a directory specifically for the Dockerized Hermes instance:

mkdir -p ~/.hermes-docker

This directory is important for two reasons.

1. Persistence

Docker containers are disposable.

If we remove and recreate the Hermes container, we don’t want to lose things like:

Configuration
Sessions
Memory
Skills
Profiles
Logs
Other persistent agent data

We’ll store those outside the container in ~/.hermes-docker.

2. It becomes part of our trust boundary

Anything inside this directory is intentionally available to Hermes.

Instead of mounting my entire home directory, I’m giving the agent one dedicated location.

That distinction matters.

⚙️ Step 3: Run the Hermes Setup Inside Docker

Now we can start the official Hermes Agent image and launch the setup process:

docker run --rm -it \
  -v ~/.hermes-docker:/opt/data \
  nousresearch/hermes-agent setup

The most important part here is:

-v ~/.hermes-docker:/opt/data

The -v option creates a bind mount between a directory on the host and a directory inside the container.

Think of it like this:

HOST                           CONTAINER
~/.hermes-docker   ───────▶   /opt/data

The left side:

~/.hermes-docker

is the directory we just created on the host.

The right side:

/opt/data

is where that directory appears inside the Docker container.

So when Hermes saves configuration, sessions, memory, skills, or other persistent data under /opt/data, those files are actually stored in ~/.hermes-docker on the host.

That means we can destroy and recreate the container without losing the Hermes environment.

More importantly, we’re sharing one dedicated directory instead of the entire host filesystem.

🧠 Step 4: Configure Hermes Agent

The first run downloads the required Docker image and launches the Hermes setup wizard.

From there, follow the normal Hermes configuration process.

In my setup, I:

Use the quick setup
Authenticate with Nous Portal
Select a model
Keep the terminal backend local
Skip messaging platform configuration for now

Once setup finishes, the configuration is stored in our persistent directory.

That means future containers using the same mount can reuse it.

🌐 Step 5: Start the Hermes Gateway and Dashboard

Now we can start Hermes as a background container:

docker run -d \
  --name hermes-docker \
  --restart unless-stopped \
  -v ~/.hermes-docker:/opt/data \
  -p 18642:8642 \
  -p 19119:9119 \
  -e HERMES_DASHBOARD=1 \
  nousresearch/hermes-agent gateway run

There are a few important things happening here.

Run in the background

-d

starts the container in detached mode.

Give the container a name

--name hermes-docker

makes it easier to manage later:

docker logs hermes-docker
docker stop hermes-docker
docker start hermes-docker

Keep the persistent directory

We’re mounting the same directory again:

-v ~/.hermes-docker:/opt/data

So Hermes sees the configuration we created during setup.

Enable the dashboard

-e HERMES_DASHBOARD=1

enables the Hermes Dashboard.

🔌 Understanding the Port Mapping

You’ll notice I’m using:

-p 18642:8642
-p 19119:9119

Docker port mappings follow this pattern:

HOST_PORT:CONTAINER_PORT

So:

18642 → 8642
19119 → 9119

The ports on the right are the ones Hermes uses inside the container.

The ports on the left are the ones exposed on my Mac.

I’m deliberately using different host ports because I already have another Hermes instance running locally and don’t want the ports to clash.

If you’re running only the Docker instance, you can use the default ports 8642 and 9119 instead of 18642 and 19119.

✅ Step 6: Verify the Container Is Running

Run:

docker ps

You should see the hermes-docker container running.

If something isn’t working, one of the first places to look is the container logs:

docker logs hermes-docker

This becomes particularly useful when configuring the dashboard.

🔐 Step 7: Configure Dashboard Authentication

When I initially opened the dashboard, it didn’t start correctly.

Instead of hiding that part from the tutorial, I kept it in because it’s a useful troubleshooting example.

Checking:

docker logs hermes-docker

showed that the dashboard needed an authentication provider.

Hermes provides authentication options for securing dashboard access.

I configured mine using Nous Portal authentication.

Once authentication was configured, the dashboard started successfully.

With my port mapping, I can access it at:

localhost:19119

And now the Hermes Dashboard is running while Hermes itself remains inside the container.

💬 Step 8: Chat With Hermes Inside the Container

You can also enter the running container directly:

docker exec -it hermes-docker bash

Then start Hermes:

hermes

At this point you’re interacting with Hermes from a terminal inside the Docker container, rather than running Hermes directly on the host.

That’s useful for testing.

But I don’t necessarily want to enter the container every time I want to use the agent.

There’s a better option.

🖥️ Step 9: Connect Hermes Desktop to the Docker Instance

Hermes Desktop can connect to the Gateway running inside our container.

Open Hermes Desktop and navigate to:

Settings → Gateway → Remote Gateway

Then configure it to use the Gateway exposed by your Docker container.

In my setup, that’s my url:

http://localhost:19119

After authenticating, save the configuration and reconnect.

Now Hermes Desktop communicates with the Dockerized Hermes instance.

So from the user’s perspective, I still get the convenient desktop interface.

But the agent itself is operating inside the container.

🛡️ What Does Docker Actually Protect?

This is probably the most important part of the tutorial.

Running an AI agent inside Docker does not automatically make it safe.

Docker gives us a useful isolation boundary, but that boundary depends heavily on how the container is configured.

For example, imagine doing this:

Host machine
      │
      ▼
Entire home directory
      │
      ▼
Docker container
      │
      ▼
Hermes Agent

You’ve technically containerized Hermes.

But you’ve also exposed a huge portion of your machine to it.

That’s not the setup I want.

Instead:

Host machine
      │
      ├── Personal files       ❌
      ├── SSH keys             ❌
      ├── Other projects       ❌
      ├── Docker socket        ❌
      │
      └── ~/.hermes-docker     ✅
                │
                ▼
          Hermes Container

The container should get access only to the resources required for the task.

🚫 1. Don’t Mount Your Entire Home Directory

If you mount your complete home directory into the container, Hermes could potentially access whatever the container’s permissions allow within that mount.

That might include personal files, source code, configuration files, credentials, or other sensitive data.

That’s why I’m using:

~/.hermes-docker

as a dedicated location instead.

If Hermes doesn’t need something, don’t expose it.

🔑 2. Be Careful With Credentials

The same principle applies to API keys and tokens.

Only provide the credentials Hermes actually needs.

Avoid unnecessarily exposing things such as:

~/.ssh

or unrelated cloud credentials and secrets.

Containerization doesn’t help much if you put every sensitive credential inside the container anyway.

⚠️ 3. Don’t Expose the Docker Socket Without a Very Good Reason

Another thing I’m deliberately not mounting is:

/var/run/docker.sock

Giving a container access to the host Docker daemon can dramatically expand what that container is capable of doing.

For an autonomous agent, that’s an especially important boundary to think about.

If Hermes doesn’t need to control Docker on the host, don’t give it that capability.

🧩 4. Docker Doesn’t Solve Prompt Injection

There’s another important limitation.

An AI agent can still encounter malicious or adversarial content.

For example, content from a webpage, repository, document, or other external source could attempt to manipulate the agent into performing unintended actions.

Putting the agent inside Docker doesn’t eliminate that problem.

The difference is what happens after the agent attempts the action.

If Hermes only has access to:

/opt/data

then we’ve limited the environment available to it.

If we’ve mounted our entire computer, exposed sensitive credentials, and given it access to the Docker daemon, the potential impact is very different.

That’s why I think containerization is better understood as blast-radius reduction, not a magic AI security solution.

🎯 The Principle: Least Privilege for AI Agents

As AI agents become increasingly capable, I think one traditional security principle becomes even more important:

Least privilege.

An agent should receive the minimum access required to complete its task.

Not:

Agent
  │
  └── Everything on my computer

But:

Agent
  │
  ├── Required files
  ├── Required credentials
  ├── Required network services
  └── Required tools

Nothing more.

This becomes increasingly important as agents gain longer-running autonomy, terminal access, browser access, external integrations, scheduled execution, and the ability to coordinate multiple tools.

Docker vs VM for AI Agents

Docker is not the only way to isolate an autonomous agent.

You could also use:

A virtual machine
A dedicated VPS
A sandboxed execution environment
A separate physical machine
More restrictive container runtimes

A VM generally provides a stronger isolation boundary than a standard application container because it virtualizes a larger portion of the environment.

Docker, however, is lightweight and convenient for local development.

For my Hermes setup, it gives me a useful middle ground:

Direct Host Execution
        ↓
Docker Container
        ↓
Virtual Machine / Dedicated Environment

The appropriate boundary ultimately depends on what capabilities you’re giving the agent and what resources it can access.

Final Architecture

After everything is configured, my setup looks roughly like this:

                   ┌─────────────────────────────┐
                   │        Host Machine         │
                   │                             │
                   │      Hermes Desktop         │
                   └──────────────┬──────────────┘
                                  │
                           Remote Gateway
                                  │
                                  ▼
              ┌─────────────────────────────────┐
              │       Docker Container          │
              │                                 │
              │       Hermes Gateway            │
              │       Hermes Dashboard          │
              │       Hermes Agent              │
              │                                 │
              │       /opt/data                 │
              └───────────────┬─────────────────┘
                              │
                         Bind Mount
                              │
                              ▼
                    ~/.hermes-docker
                              │
              ┌───────────────┴──────────────┐
              │ Config • Memory • Sessions   │
              │ Skills • Profiles • Logs     │
              └──────────────────────────────┘
       Rest of host filesystem → NOT MOUNTED
       SSH keys                → NOT EXPOSED
       Docker socket           → NOT EXPOSED

Hermes still has the environment it needs to work.

But we’re being much more deliberate about what crosses the boundary.

Final Thoughts

Autonomous AI agents are becoming capable of doing much more than generating text.

They’re increasingly able to:

⚡ Execute commands
🗂️ Manipulate files
🌍 Interact with external systems
🧰 Use specialized tools
🔄 Run multi-step workflows autonomously

That’s exciting.

But the more capable the agent becomes, the more important its execution environment becomes.

Running Hermes Agent inside Docker doesn’t solve every security problem.

It does, however, give us a practical way to control what the agent can access and reduce the potential blast radius when something unexpected happens.

The rule I follow is simple:

Only give an AI agent access to what it actually needs.

Everything else should stay outside the boundary.

🚀 What if your AI agent wasn’t tied to a single model provider? I connected Hermes Agent to OmniRoute to route across free AI models from multiple providers. Here’s the full setup 👇 #AI #AIAgents #OpenSource

Vivek Shetye — Tue, 15 Sep 2026 15:14:45 +0000

Vivek Shetye

Sep 15

How I Run Hermes Agent on FREE AI Models with OmniRoute 🚀

#ai #hermes #agents #opensource

7 min read

How I Run Hermes Agent on FREE AI Models with OmniRoute 🚀

Vivek Shetye — Tue, 15 Sep 2026 15:05:20 +0000

Free AI models are great.

Until your agent hits a quota halfway through a task.

Then suddenly you’re:

Searching for another provider
Generating another API key
Changing endpoints
Switching models
Restarting your workflow

For a simple chat application, that might just be annoying.

For an AI agent executing multi-step tasks, it becomes a much bigger problem.

So instead of connecting Hermes Agent directly to a single AI provider, I tried a different architecture:

                 ┌── OpenRouter ──→ Free Models
                 │
Hermes Agent ─→ OmniRoute
                 │
                 └── NVIDIA ──────→ Available Models

Hermes talks to one endpoint.

OmniRoute sits between the agent and the model providers and handles the routing.

The result is a surprisingly useful setup for experimenting with Hermes Agent on free AI models without tightly coupling the agent to one provider.

In this tutorial, I’ll walk through exactly how I set it up.

🎥 Prefer the Video?

I created a complete step-by-step video showing the setup, configuration, and a real Hermes Agent task running through OmniRoute.

Watch: How I Run Hermes Agent on FREE AI Models

If you’d rather understand the architecture and follow the setup at your own pace, keep reading.

The Problem With Depending on One Free AI Provider

There are now plenty of ways to experiment with capable AI models without immediately paying for API usage.

That’s great for:

Learning agent development
Building prototypes
Testing AI workflows
Experimenting with different models
Running personal automation
Comparing model capabilities

But there’s an obvious limitation:

Free access is rarely unlimited or guaranteed.

A provider may impose request limits.

A particular model might become unavailable.

Traffic might affect access.

A model could disappear from the free catalog.

Or you might simply exhaust your quota.

If your architecture looks like this:

Hermes Agent
     │
     ▼
Provider A
     │
     ▼
Model

your agent is directly dependent on that provider.

Once Provider A stops serving your requests, your workflow stops too.

Instead, I wanted something closer to this:

                     ┌── Provider A
                     │
                     ├── Provider B
Hermes Agent ──→ Gateway
                     ├── Provider C
                     │
                     └── Provider D

That’s where OmniRoute comes in.

🧠 What Is Hermes Agent?

Hermes Agent is an open-source agent harness from Nous Research for building AI agents capable of doing much more than generating chat responses.

Depending on the tools and configuration available to it, Hermes can perform tasks involving things like:

User Request
     ↓
Hermes Agent
     ↓
Reasoning
     ↓
Tool Calls
     ↓
Files / Terminal / Web / Other Tools
     ↓
Tool Results
     ↓
More Reasoning
     ↓
Final Result

This makes model availability particularly important.

A multi-step agent workflow might require many model calls before the task is finished.

If your model becomes unavailable halfway through, that can interrupt the entire workflow.

🚦 What Is OmniRoute?

Think of OmniRoute as a traffic director for AI models.

Rather than forcing your application to manage every model provider individually, OmniRoute provides a gateway between your application and those providers.

Instead of:

Application → Provider

you get:

Application → OmniRoute → Providers

For this experiment, our application happens to be Hermes Agent.

So the architecture becomes:

                       ┌──────────────┐
                       │  OpenRouter  │
                       └──────┬───────┘
                              │
┌──────────────┐      ┌───────▼───────┐
│ Hermes Agent │ ───→ │   OmniRoute   │
└──────────────┘      └───────┬───────┘
                              │
                       ┌──────▼──────┐
                       │   NVIDIA    │
                       └─────────────┘

OmniRoute is open source, can run locally, and supports a large number of AI providers.

More importantly for this experiment, it allows us to expose a single endpoint to Hermes while managing multiple model/provider connections behind it.

⚡ Why Put an AI Gateway Between Hermes and the Models?

You could simply connect Hermes directly to OpenRouter, NVIDIA, or another provider.

So why add another layer?

Because it separates two responsibilities.

Hermes Agent handles the task.

OmniRoute handles model access and routing.

Conceptually:

Hermes:
"What should I do next?"

        ↓

OmniRoute:
"Which configured model should serve this request?"

That separation becomes increasingly useful as you add more providers.

Instead of reconfiguring the agent every time your model strategy changes, Hermes continues talking to the same gateway.

You manage providers behind it.

🛠️ Step 1: Install OmniRoute Locally

The first thing I did was install OmniRoute locally.

After following the installation instructions, OmniRoute can be started from the terminal.

Once the server starts, it provides access to its local dashboard.

From there you can manage things like:

Providers
Models
Endpoints
API Keys
Routing
Analytics

This becomes the control plane for our model infrastructure.

Important security note 🔐

If you’re running a gateway locally or exposing it beyond your machine, don’t leave default credentials unchanged.

Create proper API keys and configure authentication appropriate for your environment.

🔌 Step 2: Connect OpenRouter

The first provider I added was OpenRouter.

Inside OmniRoute:

Providers
   ↓
OpenRouter
   ↓
Add Connection

You’ll need an OpenRouter API key.

Once the connection is configured, OmniRoute can import the models available through that account.

For this experiment, I enabled the option to import only free models.

The result looks conceptually like:

OpenRouter
     │
     ├── Free Model A
     ├── Free Model B
     ├── Free Model C
     └── ...

You can also perform health checks to see whether configured models are currently available.

That’s already useful but we’re still relying on one provider.

So let’s add another.

🟢 Step 3: Add NVIDIA as Another Provider

I repeated essentially the same process with NVIDIA.

Generate an API key through NVIDIA’s model/API platform and add the connection inside OmniRoute.

Now our gateway has multiple provider connections:

                OmniRoute
                   │
          ┌────────┴────────┐
          ▼                 ▼
     OpenRouter           NVIDIA
          │                 │
      Free Models      Available Models

And this is where the architecture starts becoming interesting.

Hermes doesn’t need separate configurations for both providers.

As far as Hermes is concerned, there is still only:

One API endpoint

OmniRoute handles what happens behind it.

🤖 Step 4: Connect Hermes Agent to OmniRoute

Now we need to point Hermes toward the gateway.

Hermes supports configuring a custom model endpoint.

Using the Hermes model configuration flow, I selected the custom endpoint option and provided:

API Base URL → OmniRoute local endpoint

API Key → OmniRoute API key

Compatibility → Auto Detect

For the model configuration, I used OmniRoute’s:

auto/best-coding

This is where the model selection gets abstracted away from Hermes.

Instead of telling Hermes:

Always use Model X

we’re effectively saying:

Send the request to OmniRoute.

Let the routing layer determine the appropriate
configured model for the request.

Once that configuration is saved, OmniRoute becomes a model endpoint available to Hermes Agent.

🧪 Step 5: Give Hermes a Real Agent Task

A simple “Hello World” wouldn’t tell us much.

So I gave Hermes something closer to an actual agent workflow.

The task was essentially:

Find the latest and most important AI news from reliable sources, summarize the key developments, and create a polished single-page visual report presenting the major stories, trends, and sources.

That means Hermes needs to do much more than answer a single prompt.

Conceptually:

Research
   ↓
Collect Information
   ↓
Evaluate Sources
   ↓
Summarize
   ↓
Identify Trends
   ↓
Generate Web Page
   ↓
Write Files

And here’s the important part:

Hermes was sending its model requests through OmniRoute throughout the workflow.

Hermes Task
    │
    ▼
OmniRoute
    │
    ▼
Best Available Configured Model
    │
    ▼
Response
    │
    ▼
Hermes Continues Task

After a minute or two, Hermes completed the task and generated the visual AI news report.

📊 Step 6: See Which AI Models Actually Handled the Requests

This was one of my favorite parts of the experiment.

After Hermes finished, I went back into OmniRoute.

Under its usage analytics, I could inspect information about the requests being sent through the gateway.

That included things such as:

Requests
Input tokens
Output tokens
Model usage
Which models actually served requests

So instead of the model-routing layer being a complete black box, I could inspect what happened after the task.

The workflow effectively becomes:

             ┌───────────────┐
             │ Hermes Agent  │
             └───────┬───────┘
                     │
                     ▼
             ┌───────────────┐
             │   OmniRoute   │
             └───────┬───────┘
                     │
            Routing Decision
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
      Model A                Model B
          │                     │
          └──────────┬──────────┘
                     ▼
                 Response

                     +

              Usage Analytics

For agent development, that observability is useful.

It gives you visibility into what your model-routing infrastructure is actually doing rather than only seeing the final agent output.

🧩 Why This Architecture Matters Beyond Free Models

The interesting part isn’t actually the word free.

It’s the abstraction.

Without a gateway:

Agent → Specific Provider → Specific Model

With a gateway:

Agent → Model Gateway → Routing Strategy → Provider/Model

That means the agent doesn’t necessarily need to care whether the underlying request eventually reaches one provider or another.

This becomes useful when experimenting with:

Multi-provider AI infrastructure

Different providers can sit behind one gateway.

Model fallback strategies

Your application doesn’t have to own every routing decision.

Cost optimization 💰

Different models can potentially be selected based on your infrastructure strategy.

Model experimentation

You can change the models behind the gateway without redesigning your entire agent integration.

Observability

A centralized gateway can give you a better view of model usage across your agent workflows.

And these patterns aren’t limited to Hermes.

The broader architecture is applicable to many AI applications:

AI Application
      ↓
AI Gateway
      ↓
Routing / Policies
      ↓
Multiple Models & Providers

As AI systems become more agentic, this layer becomes increasingly interesting.

⚠️ But There’s a Catch: “Free” Doesn’t Mean Unlimited

This is important.

Using multiple free-model providers does not magically create unlimited free inference.

Every provider has its own policies and constraints.

For example:

OpenRouter free models have limits.

NVIDIA access can vary depending on the model, account, availability, and traffic.

Free models may also:

Respond more slowly
Become temporarily unavailable
Change their limits
Disappear from catalogs
Have different context windows
Behave differently across tasks

And there’s another important consideration:

Always read the provider’s terms.

Some services have specific rules around:

Automation
API usage
Processing
Redistribution
Rate limits
Free-tier usage

A few minutes checking those requirements before building automation around a provider can save you problems later.

Think of this architecture as a way to use available resources more flexibly, not as a way to bypass provider limits.

🏗️ The Bigger Lesson: Decouple Your Agent From Your Model Provider

This experiment reinforced something I’ve increasingly found useful when working with AI agents:

The agent and the model infrastructure don’t have to be the same layer.

Your agent should focus on:

Reasoning
Tools
Memory
Tasks
Workflows

Your model gateway can focus on:

Providers
Models
Routing
Availability
Usage
Policies
Observability

Put those together and you get a much cleaner architecture:

┌──────────────────────────────┐
│          AI Agent            │
│                              │
│ Tools • Memory • Workflows   │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│          AI Gateway          │
│                              │
│ Routing • Models • Analytics │
└──────────────┬───────────────┘
               │
       ┌───────┼───────┐
       ▼       ▼       ▼
   Provider Provider Provider
      A        B        C

For small experiments, this might feel like an extra layer.

But once you’re testing multiple models and providers—or building longer-running agent workflows—the separation starts making much more sense.

🎯 Final Thoughts

If you’re learning AI agent development and want to experiment without immediately spending heavily on API calls, Hermes Agent + OmniRoute + free AI model providers is an interesting setup to explore.

You get:

✅ One endpoint for Hermes Agent

🔀 Multiple model/provider options behind the gateway

🧠 Automatic model selection strategies

📈 Centralized usage analytics

🛠️ The flexibility to add or change providers later

Just remember that the free tiers still have their own quotas, availability constraints, and terms.

The real value here isn’t “unlimited free AI.”

It’s building an agent architecture that isn’t unnecessarily coupled to one model provider.

Hermes Agent goes far beyond basic prompting. 🤖 I broke down /loop, /goal, Cron, Delegation, Bot Mode, Kanban & Mixture of Agents and when each actually makes sense. A practical mental model for building more autonomous AI agents. 👇

Vivek Shetye — Tue, 08 Sep 2026 15:29:15 +0000

Hermes Agent Challenge Submission: Write About Hermes Agent

Vivek Shetye

Sep 8

🤖 Hermes Agent Advanced Features Explained: Loop, Goal, Cron, Delegation, Bot Mode, Kanban & Mixture of Agents

#ai #agents #hermesagentchallenge #opensource

6 min read

🤖 Hermes Agent Advanced Features Explained: Loop, Goal, Cron, Delegation, Bot Mode, Kanban & Mixture of Agents

Vivek Shetye — Tue, 08 Sep 2026 15:03:20 +0000

Using Hermes Agent as a normal AI assistant is pretty straightforward.

You give it a task. It reasons about the problem, uses tools when necessary, and gives you a result.

But Hermes gets much more interesting when you ask a different question:

How do I get an AI agent to keep working without constantly prompting it?

Hermes Agent gives you several ways to do this.

You can create recurring loops, give the agent a persistent goal, schedule Cron Jobs, delegate work to sub-agents, create persistent specialist bots, coordinate multiple agents through Kanban, or even use multiple LLMs through Mixture of Agents.

The confusing part?

These features all increase agent autonomy, but they solve very different problems.

I recently published a video breaking down how these advanced Hermes Agent features work under the hood and, more importantly, when you should use each one.

🎥 Watch the full video:

Here’s the mental model I use to distinguish them.

🔁 1. Loop: Repeat Something Inside the Current Session

The easiest way to understand Hermes Agent’s /loop command is:

“Do this again later while I’m working in this session.”

A loop takes a prompt and reruns it on a recurring cadence.

For example:

Check my deployment every 5 minutes and tell me when it goes live.

The key distinction is that Loop is time-driven and session-scoped.

Use it for monitoring, repeated checks, polling, or other temporary recurring work associated with your current Hermes session.

🎯 2. Goal: Keep Working Until the Objective Is Complete

/goal solves a completely different problem.

Instead of saying:

“Do this again later.”

You’re saying:

“Keep working until this is actually done.”

Some tasks can’t reliably be completed in a single agent turn.

Maybe Hermes needs to modify code, run tests, inspect failures, make another change, and repeat the process.

That’s where Goal becomes useful.

After each continuation, the result can be evaluated to determine whether the objective has actually been completed.

Hermes also supports a completion contract, which can describe:

The desired outcome
How success should be verified
Constraints that must remain true
What is inside or outside the task’s scope
When Hermes should stop and ask for help

Instead of:

Fix authentication.

You can define something closer to:

Fix authentication so all tests pass.

Keep the existing login API response unchanged.

Only modify the authentication service and its tests.

Stop and ask me if a database migration becomes necessary.

Now both execution and evaluation have a much clearer definition of “done.”

One important misconception:

Goal does not automatically create an agent team, Kanban workflow, or independent background process.

It keeps the current Hermes session focused on a standing objective.

So:

Loop → Do this again later.

Goal → Keep working until this is done.

⏰ 3. Cron Jobs: Scheduled, Unattended AI Agent Workflows

Both Loop and Goal are connected to an active Hermes session.

But what if you want Hermes to wake up every morning and perform some work even when you’re not interacting with it?

That’s where Cron Jobs come in.

For example:

Every morning at 9 AM:

- Check my news feeds
- Find important AI developments
- Summarize them
- Send me a report on Telegram

When the scheduled time arrives, Hermes can launch a fresh agent session specifically for that run.

This makes Cron useful for things like:

📊 Daily reports
🔍 Recurring research
🛡️ Security audits
🧪 CI health checks
📰 News monitoring
📨 Scheduled summaries

The fundamental distinction is:

Loop
↓
Keep checking while this session is active.

Cron
↓
Wake up independently on a schedule and run the task.

If I’m watching a deployment for the next 20 minutes, I’d probably use Loop.

If I want a report generated every morning whether I’m there or not, I’d use Cron.

🧩 4. Sub-Agent Delegation: Temporary Parallel Workers

Now we move from one autonomous agent to multiple agents working simultaneously.

Suppose I ask Hermes:

Compare three approaches for implementing authentication
and recommend the best one.

The main agent could investigate each approach sequentially.

Or it could delegate:

Parent Agent
     │
     ├── Sub-Agent A → Research approach A
     ├── Sub-Agent B → Research approach B
     └── Sub-Agent C → Research approach C

The sub-agents can perform those tasks independently and return their findings to the parent.

This provides two major advantages.

⚡ Parallelism

Independent work can happen simultaneously rather than forcing the main agent to perform everything sequentially.

🧱 Context Isolation

Large research, coding, refactoring, and analysis tasks can consume significant context.

Delegating them means much of the intermediate work stays inside the sub-agent’s context rather than flooding the parent’s conversation.

The important distinction is that delegation is temporary.

A sub-agent exists to perform a focused task, return its result, and finish.

If you want a specialist identity that persists over time, you need something else.

🤖 5. Profiles & Bot Mode: Persistent AI Specialists

Imagine having separate Hermes agents for:

👨‍💻 Coding
🔬 Research
✍️ Content
📈 Analysis

You probably don’t want your research agent’s accumulated context and workflows constantly mixed with your coding agent.

That’s what Hermes Profiles help solve.

A profile acts like a separate Hermes environment with its own configuration and state.

This allows specialist agents to develop independently.

Bot Mode builds a more intuitive multi-agent experience on top of these persistent profiles.

The key distinction from delegation is persistence:

Sub-Agent
↓
Temporary worker for a task

Bot / Profile
↓
Persistent specialist identity

Multiple bots can also communicate with one another, allowing you to create workflows involving specialist agents.

But once those workflows become complicated, messages alone aren’t enough.

📋 6. Kanban: Durable Multi-Agent Orchestration

Suppose you have three persistent Hermes specialists:

Researcher
    ↓
Analyst
    ↓
Writer

You want the researcher to collect evidence.

Only after the research is finished should the analyst evaluate it.

And only after the analysis is complete should the writer produce the final report.

You could coordinate everything through agent messages.

But what happens when the workflow introduces:

Dependencies
Failures
Retries
Artifacts
Structured handoffs
Human review
Work lasting hours or days

Messages alone become fragile.

That’s where Hermes Kanban becomes useful.

Instead of the workflow existing only inside agent conversations, the work becomes structured, persistent task state.

Conceptually:

Research Topic
      ↓
Analyze Evidence
      ↓
Human Review
      ↓
Write Final Report

If Analyze Evidence depends on Research Topic, it waits.

Once the research task is completed, the dependent task can proceed.

This makes Kanban useful for durable, long-running multi-agent workflows.

And Kanban and delegation aren’t competing ideas.

A persistent Kanban worker could own a research task and then delegate parts of that research to several temporary sub-agents.

Think of it this way:

Delegation → temporary help

Bot Mode → persistent specialists

Kanban → coordination between specialists

🧠 7. Mixture of Agents: Multi-Model Reasoning

This is probably the easiest concept to confuse with multi-agent orchestration.

Mixture of Agents (MoA) operates at the model layer.

Imagine you’re solving a difficult software architecture problem.

Instead of asking one LLM to immediately decide what to do, you could ask several models to independently analyze the problem.

Reference Model A ──┐
                    │
Reference Model B ──┼──→ Aggregator Model → Hermes Agent Loop
                    │
Reference Model C ──┘

One model might notice a security problem.

Another might suggest a much simpler architecture.

Another might identify an assumption everyone else missed.

Their perspectives are then provided to an aggregator model, which becomes the model responsible for acting.

This is why Mixture of Agents is better understood as a model strategy rather than a traditional multi-agent workflow.

You’re not necessarily creating:

Research Agent
+
Coding Agent
+
Review Agent

Instead, you’re giving the acting model multiple model perspectives before it makes decisions.

The Hermes session, tools, and underlying agent loop can remain the same.

What changes is the model strategy powering that loop.

🗺️ The Mental Model

If you remember only one thing from this article, make it this:

Hermes Feature	Mental Model	Best For
🔁 Loop	Repetition	Repeated checks in the current session
🎯 Goal	Completion	Working toward a clearly defined outcome
⏰ Cron	Scheduling	Unattended scheduled workflows
🧩 Delegation	Temporary parallelism	Independent subtasks
🤖 Profiles / Bot Mode	Persistent identity	Long-lived specialist agents
📋 Kanban	Durable orchestration	Dependencies, handoffs, retries, and review
🧠 Mixture of Agents	Multi-model reasoning	Multiple LLM perspectives on difficult problems

The features become much easier to reason about once you stop grouping all of them under “autonomous AI agents.”

They’re different primitives for controlling different dimensions of autonomy.

🚀 Putting It All Together

The interesting part is that these concepts can be combined.

Imagine a software development workflow where:

Cron
  ↓
Starts scheduled workflow
  ↓
Kanban coordinates persistent specialist profiles
  ↓
Research Agent delegates work to temporary sub-agents
  ↓
Architecture Agent uses Mixture of Agents
  ↓
Goal keeps implementation focused until verification passes

Now you’re moving beyond a chatbot that happens to call tools.

You’re designing an agentic system where scheduling, persistence, parallelism, identity, orchestration, and model reasoning are separate architectural decisions.

And that distinction becomes increasingly important as AI agents become more autonomous.

Choosing an enterprise MCP gateway isn’t about the longest feature list. 👀 I compared Bifrost, Docker, Kong, Lunar MCPX & Microsoft MCP Gateway across identity, security, tool governance, deployment, and failure handling. Here’s what I found 👇

Vivek Shetye — Mon, 31 Aug 2026 15:05:34 +0000

Compares Bifrost to LiteLLM

Vivek Shetye

Aug 31

Best Enterprise MCP Gateway for Your AI Agents in 2026

#ai #mcp #agents #llm

10 min read

Best Enterprise MCP Gateway for Your AI Agents in 2026

Vivek Shetye — Mon, 31 Aug 2026 15:00:32 +0000

The best enterprise MCP gateway is not the product with the longest feature list. It is the one whose identity, policy, deployment, and failure model match your agents. After reviewing the current MCP specification and the leading gateway options, Bifrost is one of my strongest shortlist choices for application teams that want model routing and MCP tool access in the same self-hostable gateway, an embeddable Go SDK, and an explicit application-controlled tool-execution step. Its open-source codebase also gives platform teams an inspectable starting point.

That recommendation has boundaries. Bifrost Enterprise, not the open-source edition alone, is the relevant tier if you require high-availability clustering, enterprise identity federation, admin RBAC, and audit-grade logs. And if your main problem is container isolation, Kubernetes lifecycle management, or extending an existing API gateway, another product may fit better.

The short answer

Bifrost is a strong enterprise MCP gateway for teams that want one Go-based, self-hosted data plane for LLM provider traffic and MCP tools. It connects to multiple MCP servers, exposes their tools through one endpoint, supports shared and per-user upstream authentication, applies layered tool allow-lists, and keeps tool execution explicit by default.

It is not universally “the best.” Docker MCP Gateway is compelling for isolated local server runtimes; Kong is a natural extension of an existing Kong estate; Microsoft MCP Gateway targets Kubernetes-managed server lifecycle; and Lunar MCPX focuses on dedicated MCP aggregation and tool controls.

What is an enterprise MCP gateway?

An enterprise MCP gateway is an infrastructure layer between AI agents and Model Context Protocol servers. It gives agents one governed entry point for discovering and calling tools while centralizing identity, credential handling, authorization, routing, logging, and policy enforcement.

Without a gateway, every agent must connect to every server independently:

Direct connections

Agent A ─┬─ GitHub MCP server
         ├─ database MCP server
         └─ internal API MCP server
Agent B ─┬─ GitHub MCP server
         └─ database MCP server

With a gateway

Agents ── MCP gateway ─┬─ GitHub MCP server
                       ├─ database MCP server
                       └─ internal API MCP server
             │
             └─ identity, tool policy, credentials,
                approvals, traces, limits, audit

The direct model is fine for one developer and a few trusted tools. At enterprise scale, it duplicates configuration and secrets, scatters logs, and makes it difficult to answer a basic incident question: which user, through which agent, called which tool with what authority?

“MCP gateway” describes several different products

Flat comparison tables are misleading because the category contains at least four architectures:

Combined LLM and MCP gateways, such as Bifrost, govern model requests and MCP tool access in one gateway.
Dedicated MCP aggregation and control layers, such as Lunar MCPX, emphasize MCP federation, tool policy, and observability.
API gateways with MCP support, such as Kong, apply an established gateway and plugin ecosystem to MCP traffic and API-to-tool conversion.
Runtime and lifecycle gateways, such as Docker and Microsoft MCP Gateway, focus on where MCP servers run and how they are isolated or managed.

Before picking a vendor, decide which problem you actually have. A platform team replacing separate model and tool proxies has a different requirement from a security team placing policy in front of existing remote MCP servers.

Six tests for an enterprise MCP gateway

1. Whose identity reaches the tool?

Ask whether every caller collapses into one shared service account or whether the gateway preserves end-user identity. Shared credentials are simpler, but per-user OAuth lets the downstream system retain its own permission model and audit trail. Bifrost documents the available patterns in its MCP connection and authentication guide and lets operators inspect and revoke per-user MCP sessions.

The current MCP authorization specification requires each access token to be used only for its intended service. An MCP gateway must not reuse a client’s token to call another API; it should use a separate token with only the permissions that API requires.

2. Where is tool policy enforced?

Filtering tools/list reduces what the model sees, but discovery-time filtering alone is not authorization. Re-check access when tools/call executes. For destructive operations, the gateway or application should also support approval, argument validation, or a hardened read-only variant. Bifrost’s virtual-key MCP controls enforce an allow-list at inference and again at tool execution.

3. How are credentials stored and refreshed?

Verify shared OAuth, per-user OAuth, workload identities, static-key storage, token refresh, revocation, and secret redaction. Also check whether request headers are forwarded automatically. Bifrost’s connection documentation says incoming headers are not forwarded by default and describes per-client allow-lists. Safe defaults matter because a convenience feature can become a credential-exfiltration path.

4. Are logs actually audit evidence?

Operational logs, OpenTelemetry traces, and immutable administrative audit trails solve different problems. You normally need all three: traces for latency and failures, request logs for debugging, and retained audit events for security investigations and change accountability. Bifrost documents built-in observability and request logging, OpenTelemetry export, and separate Enterprise audit logs.

5. What fails, and how?

Test a dead upstream server, expired OAuth token, changed tool schema, slow tool, gateway-node loss, and duplicate call. “Retries supported” is not enough; retrying a read is different from retrying create_invoice after a timeout. Bifrost documents its MCP connection states, health checks, and retry behavior, but your proof of concept should still validate the failure semantics of each tool.

6. Which MCP specification does it implement?

The finalized MCP 2026-07-28 release made the HTTP protocol core stateless and added Mcp-Method and Mcp-Name routing headers. Many product pages still describe legacy SSE or session-affinity behavior. Require a version-compatibility matrix for your actual clients and servers rather than accepting “MCP compatible” as a complete answer.

How Bifrost’s MCP gateway works

Bifrost occupies a useful position because it is both an AI model gateway and an MCP gateway. According to its MCP architecture documentation, it acts as an MCP client to external tool servers and can act as an MCP server to clients such as Claude Desktop.

The verified request path looks like this:

Bifrost connects to upstream MCP servers and discovers their tools. Its connection guide documents STDIO, HTTP, and SSE connections.
Remote connections can use static headers, shared OAuth, or per-user OAuth. The connection and authentication documentation explains when each option applies.
Bifrost applies stacked tool filtering at client configuration, request, and virtual-key levels. Empty client tool lists deny access by default.
The model receives only the allowed tool definitions. Tool names are prefixed by client, avoiding collisions between servers.
By default, the model only proposes a tool call. Your application reviews it and invokes the separate tool-execution endpoint. Agent Mode can opt selected tools into automatic execution.
Requests and model operations can be exported through Bifrost’s OpenTelemetry integration.

That separation between proposal and execution is valuable. It creates a clean approval and validation point without claiming that a human is automatically in the loop. Your application still has to implement the approval policy.

Open source versus Enterprise

Bifrost’s open-source gateway is Apache 2.0 and includes the MCP connection/aggregation path, virtual-key governance, tool filtering, rate and budget controls, and observability plugins. The Enterprise overview describes a strict superset that adds high-availability clustering, identity-provider integrations, RBAC, audit-grade logging, and private deployment options. The clustering documentation covers peer discovery, state synchronization, and node failover.

Keep that boundary in your evaluation sheet. “Open source” does not mean every enterprise control is in the community edition. For deployment planning, Bifrost also provides an official Helm guide for OSS and Enterprise installations on Kubernetes.

Bifrost publishes impressive gateway-overhead figures, but I would treat them as vendor benchmarks. They measure Bifrost’s gateway path, not your end-to-end MCP tool latency, and there is no common independent benchmark here for ranking all six products.

Bifrost compared with enterprise MCP gateway alternatives

Gateway	Best fit	Verified differentiator	Watch before choosing
Bifrost	One self-hosted LLM + MCP gateway	Layered tool filtering, explicit execution, per-user upstream auth, Go gateway	Enterprise-only HA/identity/audit features; verify `2026-07-28` compatibility
Docker MCP Gateway	Docker-native development and server isolation	Runs MCP servers in restricted containers and manages lifecycle/credentials	Enterprise governance is a separate, invite-only offering in current docs
Kong AI Gateway	Existing Kong/API platform estates	MCP passthrough, API-to-MCP conversion, ACLs, rate limits, metrics	The AI MCP Proxy requires an AI Gateway Enterprise license
Lunar MCPX	Dedicated MCP aggregation and tool hardening	Tool groups, hardened tool variants, agent access control	Confirm which identity, audit, and secret capabilities require the Lunar platform beyond MCPX core
Microsoft MCP Gateway	Azure/Kubernetes server lifecycle	Reverse proxy plus adapter deployment, session-aware routing, Entra integration	A heavier, Kubernetes-oriented control plane; review the repository architecture

Why Bifrost belongs on the shortlist

Bifrost's case is strongest when the same application needs governed model routing and MCP tool access. Three documented design choices support that fit:

Bifrost returns proposed tool calls for review before the application invokes a separate execution API, creating an explicit point for approvals and argument validation.
Teams can deploy it as a gateway or integrate it directly through the Go SDK.
Its MCP Sessions UI supports inspection, re-authentication, editing, and revocation of per-user OAuth and header credentials.

Those capabilities do not make Bifrost the automatic winner for every deployment. They explain why it is a credible proof-of-concept candidate for the buyer profile in this article.

Kong’s configuration surface is an advantage if you already run Kong and overhead if you do not. Docker’s container isolation is excellent for local STDIO servers but does not automatically answer enterprise identity governance. Microsoft’s lifecycle manager is useful when the gateway should deploy servers, which Bifrost does not position as its primary job.

When I would choose Bifrost

I would put Bifrost on the proof-of-concept shortlist when:

the platform already needs multi-provider model routing as well as MCP;
the team prefers an inspectable, self-hosted Go service or wants to embed the gateway through its Go SDK;
explicit tool execution fits the approval design;
virtual-key and per-request tool allow-lists are sufficient for application-level access;
OpenTelemetry and private deployment are operational requirements; and
there is a clear path to Enterprise if clustering, SSO/SCIM, RBAC, and audit logs become mandatory.

I would look elsewhere first when the primary requirement is a curated connector catalog, container-per-server isolation, Kubernetes-managed MCP server deployment, or deep integration with an existing API gateway.

A proof-of-concept checklist

Do not evaluate an MCP security gateway from a demo dashboard alone. Run these tests with one read tool and one destructive tool:

two users with different upstream permissions;
discovery and execution denial for the restricted user;
OAuth expiry, refresh, and revocation;
attempted forwarding of an unapproved authorization header;
a tool description/schema change after approval;
gateway restart and upstream-server failure during a call;
trace correlation from agent through gateway to server;
audit export and actor attribution;
concurrent clients using the exact MCP protocol versions you deploy; and
edition/license mapping for every control in the acceptance criteria.

Final recommendation

Bifrost is one of the strongest enterprise MCP gateway options in 2026 for application teams that want unified LLM and MCP infrastructure, self-hosting or Go embedding, per-user MCP credential operations, layered tool governance, and an explicit execution boundary. That is a specific architectural fit, not a universal victory.

Choose the shape before the brand. Then require primary-source evidence and a failure-oriented proof of concept. For a Bifrost evaluation, compare the OSS and Enterprise editions explicitly and make 2026-07-28 protocol conformance part of acceptance testing.

Frequently asked questions

Do AI agents always need an MCP gateway?

No. A single trusted agent connected to a few local servers may be simpler without one. A gateway becomes valuable when multiple agents, users, credentials, policies, or audit requirements need one enforcement point.

What is the difference between an MCP gateway and an API gateway?

An API gateway primarily understands routes, services, and HTTP consumers. An MCP gateway understands MCP operations and entities such as tool discovery and execution. Products like Kong add MCP-aware capabilities to an API gateway; Bifrost combines MCP with model-provider routing.

Can Bifrost manage multiple MCP servers?

Yes. Bifrost connects to multiple upstream MCP servers, discovers their tools, filters them, and can expose the allowed aggregate through its /mcp gateway endpoint. It calls each upstream connection an MCP client.

Is Bifrost an open-source MCP gateway?

Yes. The Bifrost repository uses the Apache 2.0 license. Clustering, enterprise identity/RBAC, audit-grade logs, and some private deployment capabilities belong to Bifrost Enterprise, so evaluate the edition as well as the project.

How do you secure MCP servers behind a gateway?

Authenticate users and workloads, use audience-bound tokens, obtain separate upstream credentials, allow-list tools, enforce policy again at execution, require approval for risky calls, restrict header forwarding, trace every call, and retain security-relevant audit events. Also test protocol versions and tool-schema changes rather than treating the gateway as a complete security boundary by itself.

🤖 Hermes Agent Bot Mode or Kanban which should you use? I break down the difference, when each makes sense, and build a real workflow combining both for parallel AI agent research + automation. ⚡ Would love to hear how you’re using them! 👇

Vivek Shetye — Tue, 25 Aug 2026 15:23:17 +0000

Vivek Shetye

Aug 25

Hermes Agent Bot Mode vs Kanban: When to Use Each (and Why I Use Both)

#showdev #ai #hermes #agents

7 min read

Hermes Agent Bot Mode vs Kanban: When to Use Each (and Why I Use Both)

Vivek Shetye — Tue, 25 Aug 2026 15:15:28 +0000

Hermes Agent gives you Bot Mode and Kanban for working with teams of AI agents.

At first, they can look like two different ways of solving the same problem:

How do I get multiple AI agents to work together?

But they solve different layers of the problem.

Use the wrong one and you can easily end up with a group chat that becomes difficult to follow or a full task board for something that could have been handled by a single bot.

The simplest mental model I’ve found is:

🤖 Bot Mode = the team
📋 Kanban = the work

And when a workflow needs both persistent specialists and structured execution, you can combine them.

In this tutorial, I’ll explain the difference between Hermes Agent Bot Mode and Kanban, when I would choose each one, and how I combined both to build an automated AI-powered YouTube research workflow.

🎥 Full Video Walkthrough

The Problem: Not Every Multi-Agent Workflow Is a Project

Imagine I have three AI agents:

a research agent
an editor
an operations agent

Sometimes I simply want to talk to one of them.

Sometimes I want one agent to hand something to another.

And sometimes I have a much larger assignment:

Research Topic
     ↓
 ┌───┼──────────────┐
 ↓   ↓              ↓
A    B              C
 └───┼──────────────┘
     ↓
 Final Synthesis

Those are very different workflows.

The first doesn’t necessarily need project management.

The second might.

That’s where the distinction between Hermes Bot Mode and Kanban becomes useful.

🤖 What Is Hermes Agent Bot Mode?

Bot Mode gives you a roster of persistent, named AI bots inside Hermes.

Each bot can be backed by a Hermes profile with its own:

soul
model
memory
skills
instructions/personality

Instead of treating every interaction as a new generic AI session, you can create specialists.

For example:

Research Bot
Editing Bot
Operations Bot
Source Checker
Audience Researcher

You can then interact with those bots directly.

More importantly, bots can participate in workflows involving delegation and communication between specialists.

That makes Bot Mode particularly useful when you want persistent AI workers rather than creating a new agent configuration for every task.

When I would use Bot Mode

Bot Mode makes sense when I need:

🔹 Persistent specialist bots
🔹 Direct conversations with individual agents
🔹 Recurring routines
🔹 Agent-to-agent handoffs
🔹 Group discussions between specialists
🔹 Different models, memories, or skills for different roles

For example, suppose I regularly collect three articles and want my Research Bot to summarize them.

I probably don’t need a project board.

I can simply give the job to that bot.

📋 What Does Hermes Kanban Add?

Things change when the request becomes a project.

Suppose I don’t want one researcher anymore.

Instead, I want four specialists to investigate the same topic independently:

                  Topic
                    │
        ┌───────────┼───────────┐
        │           │           │
        ▼           ▼           ▼
     Sources      Audience   Competition
        │           │           │
        └───────────┼───────────┘
                    │
                    ▼
                 Synthesis

Now I have additional requirements.

Who owns each task?

Which tasks can run simultaneously?

Which task depends on another?

What happens if one fails?

When should synthesis begin?

This is where Kanban becomes useful.

Instead of keeping the entire workflow inside conversations, Hermes can represent the work as explicit tasks.

That gives the multi-agent system structure.

Kanban is useful when you need:

⚡ Parallel execution
👤 Named task owners
🔗 Dependencies between tasks
🔍 Review stages
♻️ Recovery when something fails
📊 Visibility into larger assignments

The key difference is that Bot Mode organizes your agents while Kanban organizes their work.

Bot Mode vs Kanban: A Simple Rule

Here’s the rule I use.

Use Bot Mode when:

You need persistent specialists and conversations between them.

Use Kanban when:

You need structured execution across multiple tasks.

Use both when:

You have persistent specialists executing a repeatable, multi-step workflow.

Consider three examples.

Example 1

You want one bot to summarize three documents.

Documents → Research Bot → Summary

Use Bot Mode.

Example 2

You want four specialists to research a topic and a final agent to wait until every researcher finishes.

        ┌→ Researcher A ─┐
Topic ──┼→ Researcher B ─┼→ Final Agent
        ├→ Researcher C ─┤
        └→ Researcher D ─┘

Use Kanban.

Example 3

You want that research workflow to automatically happen every weekday.

Now we need:

persistent specialists
recurring execution
agent handoffs
parallel tasks
dependencies
final synthesis

That’s where I would combine Bot Mode + Kanban.

And that’s exactly what I built for the video.

🧪 Building an AI YouTube Research Team

For the demo, I wanted to answer a practical question:

What AI agent topic should I make my next YouTube video about?

Instead of asking one LLM for ideas, I created a small specialist research team.

The team contains several bots with different responsibilities.

🔎 News Scout

The News Scout is responsible for finding the initial opportunity.

Its job is simple:

Find the latest AI agent news
and send it to the Orchestrator.

Rather than manually triggering this every day, I created a recurring cron job.

The workflow can therefore begin automatically.

🎯 Orchestrator

The Orchestrator receives the news discovered by the News Scout.

But instead of trying to research everything itself, it turns the request into a Kanban workflow.

It creates tasks for several specialist agents.

This is the bridge between Bot Mode and Kanban.

Bot Mode
News Scout
     │
     │ handoff
     ▼
Orchestrator
     │
     │ creates tasks
     ▼
Kanban

🧠 The Specialist Research Team

Once the Orchestrator receives a potential story, several specialists investigate it.

📚 Source Checker

The Source Checker focuses on the evidence.

It asks questions such as:

Are there credible sources?
What claims can actually be verified?
Is there enough evidence to build a useful video around the topic?

👥 Audience Researcher

A topic can be technically interesting and still make a terrible YouTube video.

The Audience Researcher looks at the topic from the viewer’s perspective.

It tries to determine:

Why would viewers care?
What questions might they have?
What problem does this topic solve?
Is there a useful educational angle?

📈 Competition Researcher

Next comes competition.

If dozens of creators have already published nearly identical videos, simply repeating the same information isn’t particularly useful.

The Competition Researcher investigates existing coverage and helps identify where there may still be room for differentiation.

💡 Angle Editor

Finally, the Angle Editor looks for the strongest way to turn the research into an actual video.

Instead of stopping at:

“This is trending.”

I want the system to answer:

“Why should I cover this, and what should the video actually demonstrate?”

That distinction matters.

⚙️ Running the Workflow

The complete workflow looks roughly like this:

CRON JOB
   │
   ▼
🔎 News Scout
   │
   │ Finds AI agent news
   ▼
🎯 Orchestrator
   │
   │ Creates Kanban tasks
   ▼
┌─────────────────────────────┐
│        KANBAN BOARD         │
│                             │
│ 📚 Source Research          │
│ 👥 Audience Research        │
│ 📈 Competition Research     │
│ 💡 Angle Research           │
└──────────────┬──────────────┘
               │
        tasks complete
               │
               ▼
        🧠 Final Synthesis
               │
               ▼
     📄 Video Recommendation

The research tasks can execute in parallel.

The final synthesis task waits for the research to finish.

That’s exactly the kind of workflow where Kanban becomes much more useful than relying purely on conversational handoffs.

🚀 What Did the AI Team Find?

During my demo, the News Scout found a potential topic around Microsoft Agent Lightning.

But discovering the topic was only the beginning.

The specialist agents investigated it, and the final recommendation included information such as:

viewer questions around the topic
why the audience might care
evidence supporting the opportunity
a potential demonstration for the video
alternative video angles
audience considerations
competitive considerations

So instead of receiving:

“Microsoft Agent Lightning is trending. Make a video about it.”

I received something much closer to a research-backed content brief.

That’s a far more useful output.

🧩 Why I Like Combining Bot Mode and Kanban

One of the common mistakes when experimenting with multi-agent AI systems is assuming that more agents automatically means better orchestration.

It doesn’t.

Giving five AI agents access to the same conversation doesn’t necessarily create a good workflow.

The real questions are:

Who should do the work?
What should they own?
What can happen in parallel?
What depends on something else?
Who reviews the result?
What happens next?

Bot Mode solves part of this by giving you persistent specialists.

Kanban solves another part by giving their work explicit structure.

Together, they create an interesting pattern:

Persistent Agents
       +
Specialized Roles
       +
Agent Handoffs
       +
Task Dependencies
       +
Parallel Execution
       +
Recurring Automation
       ↓
Repeatable Multi-Agent Workflow

And I think that’s a much more useful way to think about AI agent teams than simply asking:

“How many agents should I use?”

🎯 The Mental Model I Use

If you remember only one thing from this article, make it this:

🤖 Bot Mode gives you the team.

Your persistent specialists.

Their roles.

Their memories.

Their skills.

Their conversations.

📋 Kanban gives the team structure.

Tasks.

Owners.

Parallel execution.

Dependencies.

Reviews.

Recovery.

⚡ Bot Mode + Kanban gives you repeatable workflows.

That’s when the two features become especially interesting together.

You can have a recurring bot discover work, hand it to an orchestrator, turn that work into a structured task graph, execute research in parallel, and finally synthesize everything into an artifact.

When Should You NOT Use Kanban?

This might actually be the most important part.

Not every AI agent task needs orchestration.

If your workflow is:

Prompt → Agent → Answer

don’t build a task graph.

If your workflow is:

Prompt → Specialist Bot → Artifact

you may still not need one.

Kanban starts becoming valuable when your workflow begins looking more like:

              ┌→ Agent A ─┐
Input → Plan ─┼→ Agent B ─┼→ Review → Final Output
              └→ Agent C ─┘

At that point you have coordination problems rather than simply prompting problems.

And that’s where explicit workflow structure starts paying off.

🏁 Final Thoughts

The interesting part of Hermes Agent Bot Mode and Kanban isn’t choosing which feature is “better.”

They’re designed for different jobs.

Bot Mode is useful for creating persistent AI specialists and enabling conversations and handoffs between them.

Kanban is useful when those specialists need to execute a larger assignment with explicit tasks, ownership, parallelism, dependencies, and review.

And when you’re building a recurring workflow involving both?

Use them together.

For my YouTube research system:

Bot Mode → creates the persistent AI team
Cron → starts the recurring workflow
Bot handoff → passes the opportunity
Kanban → coordinates the project
Specialists → perform parallel research
Synthesis → produces the recommendation

That’s the architecture.

Not a giant group chat.

Not a Kanban board for every tiny request.

Just enough orchestration for the complexity of the work.

Can AI agents actually hand work off to each other? 🤖 I tested Hermes Agent’s new Bot Mode with 3 specialists: research challenge synthesis. Here’s what worked, what failed, and where Bot Mode fits vs Kanban. 👇

Vivek Shetye — Wed, 19 Aug 2026 18:40:52 +0000

Hermes Agent Challenge Submission: Write About Hermes Agent

Vivek Shetye

Aug 18

Hermes Bot Mode: I Built a Team of AI Agents That Hand Off Work to Each Other

#showdev #ai #hermesagentchallenge #automation

6 min read

Hermes Bot Mode: I Built a Team of AI Agents That Hand Off Work to Each Other

Vivek Shetye — Tue, 18 Aug 2026 15:03:23 +0000

What if your AI agents behaved less like isolated chatbots and more like a team of specialists that could actually collaborate? 🤖

That’s what I wanted to test with the newly released Hermes Bot Mode desktop plugin.

Instead of manually switching between different Hermes profiles, copying context, and triggering every stage myself, I built a small team of three AI agents:

Researcher → Risk Analyst → Thesis Editor

Then I gave one task to one agent.

The goal was simple: see whether the agents could gather evidence, challenge each other’s work, and produce a final answer through agent-to-agent handoffs without me manually operating every stage.

And it mostly worked.

But the interesting part isn’t the stock research demo itself.

It’s what Bot Mode changes about how we interact with Hermes Agent, persistent AI agents, and multi-agent workflows.

🎥 Full video walkthrough

🧠 What Is Hermes Bot Mode?

Hermes already supports profiles.

A profile can have its own configuration, model settings, soul, memory, skills, and tools.

That means you could already create multiple specialized Hermes agents.

Bot Mode doesn’t replace that system.

Instead, it adds a visual usability and orchestration layer on top of Hermes profiles.

The easiest way I can describe it is:

Hermes Profiles give you multiple isolated brains. Bot Mode gives those brains faces, rooms, and a team interface.

Instead of remembering profile names or managing everything through the CLI, you get a visible roster of bots.

Each bot can have its own:

🪪 Name and visual identity
🎯 Specialized role
🧠 Personality and memory
🛠️ Tools and skills
💬 Persistent conversation
🔄 Ability to communicate with other bots

That last capability is where things get interesting.

🧪 The Experiment: Can 3 AI Agents Complete One Research Task?

I wanted a task where simply generating an answer wasn’t enough.

The workflow needed different types of judgment.

So I created three specialized bots.

🔎 Bot 1: Stock Market Researcher

The first agent gathers evidence.

Its job is to research two U.S.-listed companies in the same sector using public filings and reputable market data.

For the demo, I compared NVIDIA and AMD across areas such as:

Revenue growth
Margins
Balance-sheet risk
Valuation context
Business catalysts

But I didn’t want the first agent’s answer to automatically become the final answer.

That is where the second bot comes in.

⚠️ Bot 2: Risk Analyst

The Risk Analyst is deliberately adversarial.

Instead of expanding the researcher’s conclusions, its job is to attack them.

It checks things like:

Are the reporting periods comparable?
Are the numbers supported?
Are valuation assumptions reasonable?
What downside risks are missing?
Is there contradictory evidence?
Does any language sound like an unjustified forecast?

This creates an important separation between generating research and reviewing research.

📝 Bot 3: Thesis Editor

Finally, the reviewed material goes to the Thesis Editor.

Its job is not to research everything again.

It takes the evidence and critique from the previous agents and produces a balanced comparison containing:

📚 Sources
📅 Relevant dates
🎚️ Confidence notes
❓ Known unknowns
⚖️ A more balanced final analysis

Now we have a simple multi-agent pipeline:

Research → Challenge → Synthesis

🔄 The Interesting Part: I Only Talked to One Agent

This was the actual test.

I gave my instructions to the Stock Market Researcher.

That was my only initial task instruction.

I wasn’t manually taking its output and pasting it into the Risk Analyst.

I wasn’t opening the Thesis Editor and telling it what to do next.

Instead, the researcher gathered its evidence and then attempted to hand the work to the Risk Analyst.

The Risk Analyst reviewed it and attempted to pass the reviewed material further down the chain.

The bots were composing and routing these handoffs themselves.

That’s a much more interesting interaction model than:

Human → Agent A → Human → Agent B → Human → Agent C

Instead, we’re moving toward:

Human → Agent A → Agent B → Agent C → Human

The human defines the objective while specialized agents handle parts of the coordination.

👀 Persistent Conversations Make the Workflow Easier to Understand

One thing I like about Bot Mode is that these aren’t just invisible background calls.

Each specialist exists as a recognizable bot with its own persistent conversation.

I can open the researcher and inspect what it did.

I can open the Risk Analyst and see what it received.

I can inspect what happened during a handoff.

That matters when you’re experimenting with multi-agent AI systems.

If an AI team produces a bad result, you don’t just want the final answer.

You want to understand:

Where did the workflow go wrong?

Was the original research weak?

Did the critic miss something?

Did information disappear during a handoff?

Did the final agent overstate the evidence?

Making the agents and their conversations visible gives you a much better mental model of the system.

🛠️ Creating Specialized Bots

Creating a bot from the desktop interface is fairly straightforward.

You can give it a:

Name
Title
Description
Avatar

The advanced configuration is where the specialization becomes more powerful.

You can configure the bot’s soul, assign skills, control its available tools, or clone it from an existing Hermes profile.

That means these don’t have to be three copies of the same generic assistant with different names.

You can design genuinely different specialists.

For example:

Research Agent

Web access + research skills + evidence-focused instructions.

Critic Agent

Verification instructions + skeptical personality + strict rules around unsupported claims.

Editor Agent

Strong synthesis instructions + limited mandate to introduce new claims.

The architecture becomes interesting when the agents have different responsibilities, context, tools, and behavioral instructions rather than simply different labels.

⏰ Bots Can Also Run Recurring Jobs

Another useful feature is scheduled jobs.

You can configure a bot with an instruction and schedule it to run at a particular frequency.

For example, the stock research bot could potentially run a recurring morning research task.

That opens up use cases beyond manually initiated conversations:

📊 Daily market research
📰 News monitoring
🔍 Competitive intelligence
📈 Recurring business analysis
📋 Periodic reporting
🧭 Research updates

Persistent specialists become much more useful when they can perform recurring work instead of waiting for a new chat every time.

⚡ But Bot Mode Is NOT a Full Workflow Engine

This distinction is important.

It’s easy to see agents communicating and assume you’ve suddenly built a full multi-agent orchestration system.

That’s not what Bot Mode currently is.

The handoffs are real, but they’re per invocation.

A receiving bot might respond later, and a bot already processing something might not be interrupted immediately.

Bot Mode also does not guarantee parallel execution.

My demo was effectively sequential:

Researcher → Risk Analyst → Thesis Editor

So I wouldn’t treat Bot Mode as a replacement for a proper DAG or structured workflow engine.

🐛 It’s Also Still Beta

I actually encountered a failed handoff during the demo.

The Risk Analyst completed its review but failed to successfully pass the work to the Thesis Editor.

Rather than hiding the failure, I kept it in the video because it demonstrates an important limitation.

Bot Mode is currently beta release.

Failures can happen.

In my case, I instructed the researcher that the previous delegation had failed and asked it to retry.

The researcher then communicated with the Thesis Editor, passed along the reviewed material, and the workflow continued.

For production-grade autonomous workflows, that distinction matters.

A good agent interface doesn’t automatically give you guarantees around:

retries
dependencies
execution state
parallelism
deterministic routing
failure recovery

Those are orchestration problems.

🆚 Hermes Bot Mode vs Hermes Profiles vs Hermes Kanban

These three concepts solve different problems.

Hermes Profiles provide the underlying specialization.

They give agents separate configurations, model settings, memories, souls, tools, and skills.

Hermes Bot Mode makes those specialists easier to operate as a visible team.

You get identities, persistent conversations, a roster, and agent-to-agent communication.

Hermes Kanban is still more appropriate when I need a structured project with explicit tasks, dependencies, and organized multi-agent collaboration.

I have used Kanban extensively for more complex AI-agent workflows because those tasks need more structure.

So I wouldn’t think about Bot Mode as:

“Bot Mode replaces Hermes Profiles or Kanban.”

I would think about it as another interaction model.

Profiles = specialization 🧠

Bot Mode = persistent specialists + communication 💬

Kanban = structured task orchestration 🗂️

The right choice depends on the workflow.

💡 Why I Think This Direction Is Interesting

Most AI assistants still revolve around one interface:

one user ↔ one chatbot

But many real tasks aren’t naturally one-role problems.

Consider startup research.

You might want:

Market Researcher → Competitor Analyst → Skeptic → Founder Memo Editor

For software development:

Architect → Developer → Reviewer → QA Agent

For content:

Researcher → Scriptwriter → Fact Checker → Editor

For sales:

Lead Researcher → Account Analyst → Outreach Writer

The value isn’t simply having “more agents.”

Adding ten agents to a workflow doesn’t automatically make it better.

The interesting question is whether we can give specialists clear responsibilities and useful handoffs while keeping the system understandable to the human operating it.

Bot Mode is an interesting step toward making that experience more accessible.

I’m particularly interested in where this model goes next.

Because the bigger opportunity isn’t just giving AI agents better answers.

It’s giving us better ways to organize, observe, and operate teams of specialized AI agents.

I stopped asking one AI chatbot for startup ideas. 🤖 Instead, I built a 4-agent Startup Intelligence team with Hermes Agent to research markets, challenge weak evidence & design validation experiments. Here’s how it works 👇

Vivek Shetye — Tue, 11 Aug 2026 18:58:37 +0000

Hermes Agent Challenge Submission: Build With Hermes Agent

Vivek Shetye

Aug 11

I Built a Team of AI Agents to Find Startup Opportunities

#showdev #ai #hermesagentchallenge #startup

7 min read