DEV Community: Vivek Shetye

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

I Built a Team of AI Agents to Find Startup Opportunities

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

Most people use AI for startup research like this:

“Give me 10 promising AI startup ideas.”

A few seconds later, you get a polished list.

The problem?

You have almost no idea which conclusions are backed by evidence, which are assumptions, and which are simply the model confidently connecting dots.

So I tried something different.

Instead of asking one AI agent to find startup ideas, I built a small Startup Intelligence team using Hermes Agent.

The system uses four specialized AI agents that research markets, investigate competitors, audit evidence, challenge each other’s conclusions, and ultimately rank promising B2B AI SaaS opportunities.

And rather than producing another Markdown document full of ideas, the workflow produces structured research containing:

Market opportunity scores
Companies and competitors
Customer pain and unmet needs
Evidence-backed claims
Source URLs and supporting passages
AI advantages and workflows
Low-cost validation experiments

Here’s how the system works.

🎥 Full video walkthrough

The Problem With Asking One AI Agent to Find Startup Ideas

Startup research looks easy until you actually need to decide where to spend your time and money.

A few signals can be surprisingly misleading.

💰 Funding can look like customer demand.

A market receiving hundreds of millions in venture capital doesn’t necessarily mean customers are willing to pay for another product.

📈 Growth claims can look like market validation.

Especially when the numbers come directly from vendors.

🏢 Customer logos can look like retention.

A logo doesn’t tell you how much the customer pays, how heavily they use the product, or whether they’ll renew.

⚔️ A long competitor list can make a market look saturated.

But those companies may target completely different buyers, workflows, or budgets.

Generic AI research tends to compress all these signals into something like:

“This is a rapidly growing market with strong demand and significant opportunity.”

That sounds convincing.

But as a founder, it doesn’t tell me what I actually need to know:

Is this opportunity strong enough to investigate further?

So instead of optimizing the system for generating ideas, I optimized it for reducing uncertainty.

Building an AI Startup Intelligence Team

I created four separate Hermes Agent profiles.

Each agent has:

its own role
its own instructions
its own research skill
its own memory
a clearly defined responsibility

The architecture looks roughly like this:

                     ┌─────────────────────┐
                     │   Startup Director  │
                     └──────────┬──────────┘
                                │
                    Defines scope + rubric
                                │
                ┌───────────────┴───────────────┐
                ▼                               ▼
      ┌───────────────────┐          ┌─────────────────────┐
      │ Market Researcher │          │ Competition &       │
      │                   │          │ Signals Analyst     │
      └─────────┬─────────┘          └──────────┬──────────┘
                │                               │
                └───────────────┬───────────────┘
                                ▼
                     ┌─────────────────────┐
                     │   Skeptic Editor    │
                     └──────────┬──────────┘
                                ▼
                      Evidence-backed
                     research package

The important part isn’t simply having four agents.

It’s giving them different judgment lenses.

Let’s look at each one.

1. Startup Director — The Orchestrator 🧭

The Startup Director acts like the project lead.

Its first job isn’t browsing the web.

Instead, it converts an ambiguous founder question into a bounded research problem.

For example:

Find five promising B2B AI SaaS startup markets in North America with meaningful evidence of customer demand and new company formation between January 2025 and August 2026.

Before delegating research, the Director creates two important artifacts:

brief.md
rubric.md

The brief defines things such as:

geography
buyer
industries
time window
company scope
exclusions
deliverables
known unknowns

The rubric defines:

source tiers
scoring dimensions
claim statuses
evidence requirements
counter-evidence requirements
final output structure

This matters because otherwise different agents can quietly interpret the same research question differently.

One might optimize for funding.

Another might optimize for TAM.

Another might optimize for how many startups exist.

The rubric establishes the rules before the evidence is collected.

2. Market Researcher — Is the Pain Real? 🔎

The Market Researcher investigates whether there is meaningful evidence that customers actually have the problem.

It looks for signals including:

buyer pain
willingness to pay
customer demand
company formation
funding
adoption
traction
hiring signals

But simply finding a claim isn’t enough.

The research needs to preserve where that claim came from.

That distinction becomes extremely important later when another agent audits the research.

3. Competition & Signals Analyst — What Already Exists? 🧩

The second researcher approaches the same markets from another direction.

Instead of primarily asking:

“Is there demand?”

It asks:

“How is this problem being solved today?”

That means researching:

startups
incumbents
internal tools
agencies
spreadsheets
existing software
adjacent products

It also investigates whether market attention is translating into something stronger:

adoption, payment, retention, or recurring usage.

This distinction matters.

A market can be extremely popular on X, LinkedIn, Product Hunt, or Hacker News while having surprisingly little evidence that businesses are paying to solve the problem.

The Market Researcher and Competition Analyst therefore examine overlapping markets but with different objectives.

4. Skeptic Editor — Try to Break the Thesis 🛡️

This might be the most important agent in the entire workflow.

Most AI pipelines optimize for generating an answer.

The Skeptic Editor optimizes for finding reasons that answer might be wrong.

It doesn’t simply read the summaries produced by the other agents.

It examines the underlying:

research files
claims ledger
source URLs
supporting passages
claim classifications
counter-evidence

Then it asks questions like:

Does this citation actually support the claim?
Is this vendor-reported or independently verified?
Does the evidence cover the correct market?
Does it fall inside the requested time window?
Are we confusing funding with customer demand?
Is a company-reported metric being presented as independent evidence?
What evidence contradicts the recommendation?

If a source supports only a weaker statement, the claim gets narrowed.

If the evidence quality is poor, confidence gets downgraded.

And if there isn’t enough evidence?

The answer can simply become:

UNKNOWN

That’s a feature, not a failure.

An AI research system should be able to admit uncertainty.

Orchestrating the Agents With Hermes Kanban

There was another architectural problem.

Separate Hermes profiles don’t share conversation history.

That means I needed a durable coordination mechanism.

This is where Hermes Kanban becomes useful.

The Startup Director creates two independent research tasks:

Market Research
Competition & Signals

Because neither depends on the other, they can run in parallel.

The Director then creates another task:

Skeptical Review

But this task has both research tasks as parents.

Conceptually:

             Startup Director
                    │
           ┌────────┴────────┐
           ▼                 ▼
     Market Research    Competition
           │                 │
           └────────┬────────┘
                    │
             BOTH COMPLETE
                    │
                    ▼
             Skeptic Editor

The Skeptic Editor therefore doesn’t start synthesizing conclusions while half the research is still missing.

This creates an actual dependency graph rather than simply launching several agents and hoping they coordinate.

What Did I Ask the Agents to Research?

For this experiment, I asked the system to compare five specific B2B AI SaaS startup markets in North America.

The industry scope covered:

🏥 Healthcare & Life Sciences

💻 Software Development

🎧 Customer Support & Contact Centers

📊 Finance & Accounting

🛍️ Retail

I also explicitly excluded:

generic wrappers around foundation-model APIs
consumer applications
AI infrastructure
chips
data centers
model providers
undifferentiated chatbots and copilots

The goal wasn’t:

“Which AI industries are growing?”

That’s too broad to be useful.

The agents instead compare specific combinations of:

Buyer + Pain + Workflow + AI Advantage

That’s much closer to the level at which a founder can actually validate an opportunity.

Every Important Claim Needs Evidence 📚

One requirement fundamentally changed the quality of the output:

Every important market claim needed to be backed by a source.

The claims dataset preserves fields such as:

claim
status
company / market
claim type
source URL
source title
publication date
retrieval date
source tier
supporting passage

This makes the research auditable.

Instead of seeing:

“Companies are increasingly adopting AI for this workflow.”

You can inspect the exact evidence that caused the system to make that statement.

And that means another agent—or a human—can challenge it.

The Final Output Isn’t Just a Report

The Skeptic Editor produces several structured CSV files.

markets.csv
experiments.csv
competitors.csv
companies.csv
claims.csv

This makes the results much more useful than one huge research document.

markets.csv

This contains the ranked opportunities.

For each market, the dataset can include:

market definition
opportunity score
target buyer
workflow
recommendation
companies
customer complaints
unmet needs
AI advantage
evidence quality

Now I can compare opportunities instead of reading five unrelated research reports.

companies.csv

This captures the companies discovered during research.

For example:

Company
Product
Buyer
Market
Differentiation

This helps answer:

Who is already attacking this problem, and how?

competitors.csv

Competition isn’t limited to startups.

The real alternative could be:

an incumbent SaaS platform
an internal operations team
an agency
a spreadsheet
a manual workflow

Understanding the status quo is often more useful than counting startups.

claims.csv

This is effectively the evidence ledger.

Every important conclusion can point back to the evidence supporting it.

That creates a useful chain:

Recommendation
      ↓
Market finding
      ↓
Claim
      ↓
Source
      ↓
Supporting evidence

This makes the final recommendation much harder to fake with confident language.

The Most Useful Output Might Be experiments.csv 🧪

Finding an interesting market still doesn’t mean you should build a product.

So every promising opportunity gets converted into a small validation experiment.

The experiments can contain:

Hypothesis
Target buyer
Procedure
Channel
Sample size
Cost / effort
Success threshold
Failure threshold
Decision rule
Evidence required

This changes the final question.

Instead of:

“Should I build this startup?”

The system asks:

“What’s the cheapest experiment that could prove this opportunity weaker or stronger?”

That’s a much better founder question.

AI Agents Should Reduce Uncertainty, Not Manufacture Confidence

After building this workflow, this was my biggest takeaway.

The value of multi-agent systems isn’t simply that you can run more AI agents.

Four agents producing four versions of the same answer isn’t necessarily better than one.

The advantage appears when agents have:

different responsibilities + independent evidence + explicit dependencies + durable state + adversarial review.

Then you’re building something closer to a research process.

The final system doesn’t claim:

“I found the perfect startup.”

Instead, it tells you:

what appears promising
what evidence supports that conclusion
what evidence contradicts it
what remains unknown
what you should test next

That distinction matters.

Because when you’re deciding where to spend months building a product, a confident answer isn’t enough.

You need a process that’s harder to fool.

🚀 Built an AI video production workflow with Hermes Agent and Remotion. The agent researches a topic, writes the script, generates visuals, creates motion graphics, adds AI voiceover, music, sound effects, animated captions, and renders the final video

Vivek Shetye — Tue, 04 Aug 2026 15:30:59 +0000

Hermes Agent Challenge Submission: Write About Hermes Agent

Vivek Shetye

Aug 4

🚀 Build an End-to-End AI Video Production Pipeline with Hermes Agent and Remotion

#ai #hermesagentchallenge #agents #automation

3 min read

🚀 Build an End-to-End AI Video Production Pipeline with Hermes Agent and Remotion

Vivek Shetye — Tue, 04 Aug 2026 15:04:33 +0000

Creating high-quality short-form videos traditionally requires switching between multiple tools for research, scripting, design, editing, voiceovers, captions, and rendering.

But what if an AI agent could orchestrate that entire workflow for you?

In this tutorial, I demonstrate how to build a complete AI-powered video production pipeline using Hermes Agent and Remotion. From discovering a viral topic to rendering a polished vertical video that’s ready for YouTube Shorts, Instagram Reels, or TikTok.

🎬 What You’ll Build

By the end of this tutorial, you’ll have an automated workflow that can:

🔍 Research trending topics from the web
📚 Collect sources and supporting references
✍️ Draft an engaging video script
🎨 Generate a detailed production plan
🖼️ Create AI-generated visual assets
🎥 Produce motion graphics with Remotion
🎙️ Generate natural AI voiceovers
🎵 Add background music and sound effects
💬 Create animated word-level captions using Whisper timestamps
📱 Render a production-ready vertical video

Instead of spending hours jumping between different applications, you describe what you want in natural language, and the agent coordinates the entire production process.

🎥 Full video walkthrough

🤖 Why Hermes Agent?

Hermes Agent isn’t just another coding assistant.

It can execute multi-step workflows that involve research, planning, asset generation, coding, media production, and iterative improvements.

For this project, Hermes Agent acts as an AI video producer by:

researching content ideas
writing scripts
planning visuals
generating production assets
building Remotion components
reviewing generated scenes
making improvements automatically

This allows creators to focus on storytelling instead of repetitive editing tasks.

⚡ Why Remotion?

Remotion lets developers create videos using React instead of traditional timeline-based editors.

That means your videos become:

version controlled
reusable
programmable
data-driven
easy to automate

When paired with Hermes Agent, Remotion becomes a powerful foundation for AI-generated motion graphics and automated video production.

🛠 The Workflow

The tutorial walks through the complete pipeline.

1️⃣ Research a Viral Topic

The first prompt asks Hermes Agent to research interesting recent discoveries about the universe.

Rather than returning a single answer, the agent:

searches the web
evaluates multiple sources
creates a structured research document
recommends the strongest topic

For the demo, I selected:

James Webb Space Telescope discovering methane on an interstellar comet.

2️⃣ Generate a Production Script

Hermes Agent converts the research into a complete production script containing:

narration
storyboard
Remotion cues
production notes
scene descriptions

Instead of just writing text, it prepares everything needed for video production.

3️⃣ Build a Scene-by-Scene Production Plan

Next, the agent generates a detailed production specification including:

🎨 color palette

🎞 animation style

📐 canvas resolution

⏱ frame rate

🎬 editorial direction

📋 scene breakdowns

This document becomes the blueprint for the entire video.

4️⃣ Generate Visual Assets

The workflow automatically creates AI-generated artwork for every scene.

Hermes supports multiple image generation providers, allowing you to use the model that best fits your workflow.

5️⃣ Generate the Motion Graphics Video

This is where Remotion shines.

Hermes uses the installed Remotion skills to:

generate React components
animate scenes
compose the timeline
organize assets
build the complete video

Even better, it reviews rendered frames against the production plan and iteratively improves scenes when needed.

6️⃣ Add AI Voiceovers

Once visuals are complete, Hermes generates narration using a text-to-speech model.

You can choose between:

local models
cloud providers
premium voices

depending on your setup.

7️⃣ Add Music and Sound Effects

The workflow also enriches the video with:

🎵 background music

🔊 sound effects

This makes the final result feel much more polished without requiring manual editing.

8️⃣ Generate Animated Captions

One of my favorite parts of the workflow.

Hermes uses Whisper to generate accurate word-level transcript with timestamps and creates captions that:

✨ highlight the currently spoken word

📈 animate smoothly

🎯 optimize readability

📱 are designed specifically for Shorts and Reels

The result looks significantly better than static subtitles.

💡 Why This Workflow Matters

AI video generation is evolving rapidly.

Many tools can generate clips.

Far fewer can manage an entire production pipeline.

This workflow combines:

AI research
scripting
planning
image generation
motion graphics
voice synthesis
caption generation
rendering

inside one cohesive workflow.

For developers and technical creators, this approach offers much greater flexibility than traditional video editors.

🎯 Who Is This For?

This workflow is ideal if you’re building:

educational YouTube channels
AI explainers
SaaS product demos
marketing videos
startup launch videos
developer tutorials
technical animations
social media content
automated content pipelines

💬 What Do You Think?

Would you trust an AI agent to produce your videos?

Or do you still prefer editing everything manually?

I’d love to hear how you’re using AI for content creation.

🚀 I Combined 3 AI Models Using Hermes Agent’s Mixture of Agents! Here’s What Happened

Vivek Shetye — Fri, 17 Jul 2026 19:45:56 +0000

We spend a lot of time asking one question:

Which AI model is the smartest?

GPT? Claude? DeepSeek? MiniMax?

But after experimenting with Hermes Agent’s Mixture of Agents (MoA), I started wondering whether that’s the wrong question.

What if, instead of choosing one AI model, you could make several models analyze the same problem and let another model combine their best ideas?

In other words:

3 AI Models → 1 Smarter Decision → Better Results

That’s the idea behind Mixture of Agents.

And I decided to put it to the test.

🤝 What Is Mixture of Agents?

Most AI agents work with a single model.

You send a prompt.

The model reasons about it, uses tools, and gives you an answer.

Mixture of Agents introduces another layer.

Your prompt is first sent to multiple reference models in parallel.

Each model independently analyzes the same problem and provides its perspective.

Their responses are then given to an aggregator model, which reviews the different approaches, combines the strongest ideas, and decides what to do next.

The reference models act like advisors.

The aggregator is the decision-maker.

Only the aggregator can:

📂 Read files
🛠️ Execute tools
💻 Run terminal commands
✍️ Modify code
✅ Produce the final response

So from your perspective, you’re still working with one AI agent.

Behind the scenes, however, that agent is consulting multiple AI models before making important decisions.

🏢 Think of It Like Asking Multiple Senior Engineers

Imagine you’re making an important architecture decision.

Would you rather ask one senior engineer?

Or have three senior engineers independently review the problem first?

One might immediately spot a security issue.

Another might question whether the architecture will scale.

The third might find a much simpler implementation.

None of them necessarily has the complete answer.

But a decision-maker who can see all three perspectives has more information before choosing a direction.

LLMs work in a similar way.

Different models have different strengths, weaknesses, biases, and reasoning patterns.

The goal of Mixture of Agents isn’t simply to add more models.

It’s to give the final model access to diverse perspectives before it commits to a solution.

🎥 Full video walkthrough

⚙️ How the Architecture Works

The basic workflow looks like this:

                  YOUR PROMPT
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
      AI Model     AI Model     AI Model
      Advisor      Advisor      Advisor
          │            │            │
          └────────────┼────────────┘
                       ▼
               Aggregator Model
                       │
                 Makes Decision
                       │
                       ▼
             Tool Calls + Final Answer

The important distinction is this:

Reference models advise. The aggregator acts.

The advisors don’t modify your project or execute tools.

They analyze the problem independently and provide additional perspectives that the aggregator can use when deciding what to do.

🧪 Putting 3 AI Models to Work

For my experiment, I configured:

⚡ DeepSeek V4 Flash — Reference Model
🚀 MiniMax M2.7 — Reference Model
🧠 GPT-5.4 — Aggregator Model

I then gave the agent a practical task:

Build a Kanban board for a solo YouTube creator.

When I submitted the prompt using /moa, Hermes sent the same problem to both reference models in parallel.

Each analyzed the task independently.

Once their responses were ready, the aggregator received:

My original prompt + DeepSeek’s perspective + MiniMax’s perspective

It could then synthesize those ideas and decide how to approach the actual implementation.

The result?

After roughly 14 minutes, the agent had built a functional single-page Kanban application with:

📋 Seven creator-focused workflow columns
📝 Editable task cards
🏷️ Tags and priorities
📅 Due dates
☑️ Checklists
🔍 Search
🎛️ Filtering
🖱️ Drag-and-drop cards
📊 Workflow statistics
💾 Local browser persistence

All from a single initial prompt.

The interesting part wasn’t just the finished application.

It was being able to see how multiple models contributed perspectives before the acting model committed to an approach.

👀 Watching Different AI Models Approach the Same Problem

One of the most interesting parts of Hermes Agent’s implementation is the visibility into what the reference models are doing.

While the task is running, you can see each reference model independently analyzing the problem.

This makes it possible to observe:

🧠 What different models notice
🔍 Details one model catches that another misses
💡 Different approaches to the same problem
🤝 How those perspectives inform the aggregator

It’s a useful reminder that different LLMs don’t always approach problems in exactly the same way.

And that’s where the potential value of Mixture of Agents comes from.

You don’t necessarily need three models to agree.

Sometimes the disagreement is the useful part.

🎛️ One Configuration That Can Make a Big Difference

One setting worth understanding is:

reference_max_tokens

This controls how much output each reference model can generate for the aggregator.

Giving every advisor thousands of tokens isn’t necessarily useful.

The aggregator often needs the key insights, not another complete solution.

Lower limits can therefore mean:

⚡ Faster responses
💰 Lower token usage
🎯 More focused advice
📉 Less unnecessary context for the aggregator

Hermes recommends 600 tokens as a practical default for concise reference responses, though the ideal value will depend on your task.

🧩 Different AI Teams for Different Problems

Another feature I found useful is the ability to create multiple Mixture of Agents presets.

That means you don’t need one universal AI team.

You could have:

💻 Coding

Models selected specifically for software engineering.

🔬 Research

Models with different strengths in analysis and long-context reasoning.

🏗️ Architecture

Models that provide complementary perspectives on system design.

📈 Financial Analysis

A completely different combination optimized for analytical tasks.

Instead of constantly asking:

“What’s the best AI model?”

The more interesting question becomes:

“What’s the best combination of models for this particular problem?”

🎯 When Does Mixture of Agents Actually Help?

I wouldn’t enable Mixture of Agents for every prompt.

If you’re asking:

What’s 15 × 27?

Three AI models aren’t going to make the answer three times better.

The additional reasoning becomes valuable when there are multiple valid approaches to a problem.

Some good candidates include:

🏗️ Software architecture
🔍 Code reviews
🐞 Complex debugging
📚 Technical research
🔄 Migration planning
⚙️ System design
🤖 AI agent workflows

These are problems where a second or third perspective can expose something the first model overlooked.

⚖️ The Trade-Offs

Mixture of Agents isn’t a free intelligence upgrade.

💰 Higher API Costs

You’re making additional model calls.

With two reference models and one aggregator, you’re paying for multiple perspectives instead of relying entirely on one model.

Hermes preserves prompt caching, which helps, but the additional reference calls still introduce extra cost.

⏳ Increased Latency

The aggregator needs the reference outputs before it can use them.

That means complex tasks can take longer than simply sending everything directly to one model.

🤔 More Models ≠ Better Results

Adding models blindly isn’t the goal.

If all your reference models have similar strengths and approach problems similarly, the additional perspectives may not add much.

The real value comes from diversity.

A strong combination might include models that excel at different things rather than simply choosing the three highest-scoring models on a leaderboard.

💡 The Bigger Idea: AI Models Don’t Have to Compete

The most interesting takeaway for me wasn’t the Kanban application itself.

It was the change in how we can think about AI models.

Most of the AI industry conversation revolves around competition:

Which model is #1?

Which model has the highest benchmark score?

Which model should replace the one I’m currently using?

But maybe that’s only part of the story.

The next step in AI systems might not simply be:

One smarter model.

It could also be:

Multiple specialized models working together.

Instead of choosing between Claude, DeepSeek, MiniMax, GPT, or whatever comes next, AI agents can potentially use different models as a team—taking advantage of their individual strengths before making a final decision.

The question then changes from:

“Which AI model is the smartest?”

to:

“Which combination of AI models makes the smartest decisions?”

And I think that’s a much more interesting problem.

💬 Which 3 AI Models Would You Choose?

Here’s the experiment I’d love to see:

You get to build your own AI team.

You can choose two advisors and one final decision-maker.

Which three models are you picking?

And more importantly:

Why that combination?

Drop your AI team in the comments. 👇

🚀 I Built an AI Company That Shipped an App From Scratch (Using Paperclip AI)

Vivek Shetye — Tue, 07 Jul 2026 16:56:07 +0000

💬 What if AI didn’t work as a single assistant but as an entire software company?

That’s exactly what I wanted to explore.

Instead of asking one AI agent to build an application, I created an AI engineering organization with specialized roles and let them collaborate like a real development team.

The result?

A working CRM Dashboard MVP built using Paperclip AI, complete with planning, architecture, implementation, testing, security reviews, and multiple UI refinement iterations.

In this article, I’ll show you how the workflow works, what impressed me, where it still falls short, and why I think this is one of the most interesting directions for AI-powered software development.

🎥 Full video walkthrough

🏢 Building an AI Company

Most AI coding tools give you a single powerful agent.

Paperclip AI takes a different approach.

Instead of one “super agent,” it lets you build an organization with reporting structures, responsibilities, approvals, and workflows that resemble a real engineering team.

For this project, my company consisted of:

👔 CEO
🏗️ CTO
💻 Software Engineer
🧪 QA Engineer
🛡️ Security Engineer

Every agent had:

Clearly defined responsibilities
Its own Agents.md
Its own SOUL.md
Specialized models and tools
A reporting hierarchy

Rather than sharing one giant prompt, every agent knew exactly what it was responsible for.

🎯 The Project

To test the workflow, I asked my AI company to build a production-ready CRM Dashboard MVP.

The application includes:

🔐 Secure authentication
📂 CSV lead import
📊 Visual sales pipeline
🔍 Search & filtering
📈 Dashboard metrics
📝 Opportunity management
📱 Responsive UI

Instead of writing code myself, I focused on defining requirements and improving the workflow.

⚙️ How the Workflow Actually Worked

This was probably the most interesting part.

The CEO didn’t immediately start generating code.

Instead, it:

Analyzed requirements
Broke down the project
Created an execution plan
Defined dependencies
Requested approval

Only after the roadmap was approved did the CTO begin working.

The CTO:

Designed the system architecture
Selected the technology stack
Planned APIs
Designed the database
Defined security requirements

Only then did implementation begin.

The Software Engineer implemented features.

After each implementation:

🧪 QA validated functionality.
🛡️ Security reviewed vulnerabilities.
🏗️ The CTO reviewed and approved completed work before tasks were marked finished.

It felt much closer to how real engineering organizations operate than traditional “single prompt” AI coding.

🎨 Iterating Instead of Starting Over

One thing I enjoyed was how easy it was to improve the application incrementally.

The initial dashboard worked…

…but the UI looked cramped and inconsistent.

Instead of regenerating everything, I created another task with:

acceptance criteria
design improvements
spacing fixes
layout enhancements
interaction improvements

The AI engineering team iterated on the existing application just like a real software team would.

🤖 Different Models for Different Jobs

Another thing I liked was assigning different models to different roles.

For example:

👔 CEO → Hermes
🏗️ CTO → Hermes
💻 Software Engineer → Codex (GPT-5.5)
🧪 QA → Codex (GPT-5.5)
🛡️ Security → Codex (GPT-5.4)

Instead of expecting one model to excel at everything, each agent could specialize.

That approach feels much more scalable as AI models continue improving.

💡 What Impressed Me Most

It wasn’t that AI generated code.

We’ve already seen that.

What impressed me was how work flowed through the organization.

Requirements.

↓

Planning.

↓

Architecture.

↓

Implementation.

↓

Testing.

↓

Security review.

↓

Approval.

↓

Iteration.

That mirrors the software development lifecycle surprisingly well.

⚠️ Let’s Set Realistic Expectations

Paperclip AI isn’t magic.

It won’t build a production SaaS application from a single prompt.

The quality depends heavily on:

Choosing the right model for each role
Writing good Agents.md
Designing strong SOUL.md
Creating clear task dependencies
Installing useful skills
Reviewing outputs
Iterating frequently

Think of it as managing an engineering team rather than using an autocomplete tool.

The better your team is organized, the better the results become.

🚀 Final Thoughts

I don’t think the future of AI software engineering is one massive agent doing everything.

I think it’s teams of specialized AI agents collaborating through structured workflows, with humans acting as engineering managers rather than code generators.

Paperclip AI is still evolving, and there are definitely rough edges.

But after building this project, I’m convinced that structured multi-agent orchestration is a direction worth watching.

I’m excited to see where it goes next.

If you’ve experimented with Paperclip AI, AI agents, or multi-agent software engineering, I’d love to hear your experience in the comments.

Happy building! 🚀