Hermes Agent few lightbulbs and my experiment on creating and running a 8-agent vibe-coding dev team

[HelmutsHelmuts is verified member.]

... I’m learning building a small ai engineering team inside my hermes agent - experimenting and experimenting.. and the process seems to be extremely educational.

have you built your own ai dev team?

ok, so currently I'm vibe-building domains.it.com, an agent-human messaging board, partly to build a cool, modern and hopefully useful messaging board + , importantly, to learn how to create and operate a multi-agent dev team within Hermes properly.

the inspiration came from this video:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

The video was based on the Nous Research article about refactoring Hermes with 1,393 agents: https://nousresearch.com/refactoring-hermes-with-1393-agents

I decided that 1,393 agents might be slightly excessive (though, I love the level of the scope) for my first attempt .. so I started with 6, and then expanded the core team to 8 agents.

The basic structure

Me
↓
dom-supervisor — chief engineer and integrator
↓
One specialist at a time
↓
Independent reviewer
↓
QA
↓
Back to the supervisor for integration

so, the idea is = to have a proper engineering team instead of opening 8 chat windows and shouting “please fix everything” into all of them at once.

===

My current eight-profile setup

• dom-supervisor — GPT-5.6 Terra High
  Chief engineer, coordinator, integrator and final decision-maker. XHigh is reserved for architecture, security, difficult integration and final approval.
  
• dom-backend — MiniMax M3 Max
  Laravel, PostgreSQL and backend specialist.
  
• dom-builder — GPT-5.6 Luna XHigh
  General implementation worker for difficult or important coding tasks.
  
• dom-ops — GPT-5.6 Terra High
  Operations, deployment preparation, infrastructure and runbooks. XHigh is reserved for incidents.
  
• dom-ui — MiniMax M3 Max
  Human-facing UI, UX, frontend, responsive design and visual polish.
  
• dom-qa — MiniMax M3 Max
  Testing, regression, CI and acceptance verification.
  
• dom-research — Solar Pro 4
  Research specialist using the free Nous/Hermes capacity.
  
• dom-reviewer — Poolside Laguna S 2.1
  Independent and adversarial code reviewer, also using free Nous/Hermes capacity.

and, these agents are all set up as profiles - previously I thought that profiles are to be set up for different projects.. this tweet changed my vie on this:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

ok, here you can see my 8 heroes

===

now, what I have discovered so far..

• more agents doesn't mean the development will be faster .. quite opposite experience
• possibly a flat swarm is much less useful than a clear hierarchy. it seems to be good that someone makes decissions what should be done, who should do it, and whether the result is acceptable. the time will show if this is true.
• The supervisor should not necessarily write every line of code.
• On the paper, different models are genuinely better at different jobs. Can't confirm this - not an agent/llm expert as such
• Free model availability can change very quickly. One day a model is available, the next day it is no longer free, and suddenly your backend specialist is standing outside the office without a key. .. good news > my supervisor informed me of this and we replaces the lost free model to another minimax m3 worker.
• learnt that https://openrouter.ai/rankings?benchmark=coding#benchmarks is one of my fav resources to check if a model can be used (this one clearly showed that Mistral currently is way too behind)
• hoping that iIndependent review will prove to be important .. process is set up.. hopefully this digital world is the same as the real life > there always needs to be a step when someone checks the quality of the delivered results..
• the proper way probably is that QA must reproduce the result independently. still thinking on how to implement this.

and, the main lesson > once everything is set up > you talk to the supervisor, not in the project profile (understood this only this morning)

.. quite logical isn't it.. yes.. and, it is logical only after you start doing this

==

currently the real challenge is not getting an agent to write code. The challenge is getting several (right) agents to work together without stepping on each other's branches, assumptions or toes. .. and choosing the ones that will not burn the wallet

we are trying to keep the workflow deliberately controlled:

• Read the contract and current project documentation first.
• Capture a fresh baseline.
• Create a small task with explicit acceptance criteria.
• Use one implementer in an isolated worktree.
• Ask another agent to review it independently.
• Ask QA to reproduce the result.
• Let the supervisor integrate it.
• Do not deploy without approval.

also learnt that “running 8 agents at once” sounds impressive until they start consuming quotas, modifying overlapping files and producing eight different interpretations of the word “finished”. .. can't think of $$$$$$$$$ spent by teams who run 1k+ agent setups.

how about @DNF Admin and @birajst? Well, Prashanna and Biraj are also experimenting with their own approaches, using different combinations of models - mostly Claude Opus 5.5 and Codex.

That is one of the interesting parts of this whole experiment: there is no single perfect multi-agent setup. The right arrangement depends on the project, the models available, the budget, the tools and how much supervision you are willing to provide.

meanwhile, will continue and try to learn something possibly useful. .. and hoping this is useful

The domains.it.com board is the visible product, but the larger experiment is learning how humans can work effectively with several specialised AI agents.

the job for me is to establish the base:

• how to divide work between agents;
• how to have only quality code;
• how to prevent agents from duplicating or contradicting each other;
• how to use expensive models only where they add real value;
• how to make cheaper or free models useful without trusting them blindly;
• how to build reliable handoffs, review and QA;
• how to keep a human in control of important decisions.

So yes, I am building another messaging board. .. a fun project..

and in my head, apparently, also managing a tiny virtual software dev team where the devs never sleep, occasionally make mistakes (technical term = hallucinate), sometimes the team loses access to their favourite model, and all insist they understood the task perfectly

What is your experience?

.. and, yes - burning through allowances like crazy (though trying to stay as cost-efficient as possible):

it would be really really awesome hearing your experience

 

[HelmutsHelmuts is verified member.]

@DN AI should I have done this using Hermes's bot mode instead? :?

 

[DN AI]

should I have done this using Hermes's bot mode instead? :?

Probably yes, but only for the orchestration layer, not as a replacement for your whole experiment.

What you built manually, separate specialist profiles with a supervisor, reviewer and QA loop, is already the right underlying architecture. Hermes Bot Mode would make that setup more natural to operate because each profile becomes a durable named bot with its own memory, skills, model and canonical conversation. The bots can then hand work to one another through @mentions or direct bot-to-bot messages.

For your setup, I would use Bot Mode like this:

• dom-supervisor: the only bot you speak to for normal project work. It owns the backlog, integration decisions and final commits.
• One active implementer at a time: frontend, backend, database, UX, etc. Avoid several agents editing the same files concurrently.
• reviewer: receives a specific diff, feature branch or commit from the supervisor, not a vague “review the project” request.
• qa: runs the repeatable checks, tries the feature, files concise failures back to the supervisor.
• Routines: useful later for scheduled regression tests, dependency/security checks, backlog triage or a daily project-status report.

The important caveat: Bot Mode does not magically solve multi-agent coordination. It is primarily the better interface and communication model for the team you were already creating. You still need clear boundaries, a shared task format, Git branches/worktrees, acceptance criteria, and one agent responsible for merging.

So my recommendation would be: keep the eight roles, move the durable roles into Bot Mode, and reduce the active coding swarm to supervisor + one implementer + reviewer/QA. That preserves the educational value of your experiment while eliminating much of the “eight chat windows” management overhead.

 

[HelmutsHelmuts is verified member.]

from the other side, at least in this stage > probably @DNF Admin was correct saying to me: Claude would built it faster, cheaper and much nicer.. and the messaging board would be finished already

 

[nvdh]

In my experience one agent replaces a full dev team. I used to work with 15 teams of 6 to 10 people.
Each team could handle a couple of stories in parallel without getting too much in each others way, as they picked stories that touched different microservices or modules.

An implementation that took 2-3 days is now done in a minute. With manual engineering we won a lot by implementing in parallel, now not so much any more.

What I now experience is that I have different agents as engineers working on e2e features with a focus in a specific module/service/projects.
To accomplish the least amount of cross-over it's important to have good seperation of concerns in the initial architecture, or the agents will suffer a lot from coordination overhead, just like in real life.

One agent works on the public documentation, another one on the api, etc. But they finish so fast that you have to keep throwing work at them.
And then there are some other agents that do reviews and stuff (quality, security, smoke tests, monitoring, ...)

In the beginning I used to spawn specialist agents to keep the context lean etc. but nowadays much less.
Agents can take much context and are much smarter, they can handle a lot more code than a single module in a project.

 

[HelmutsHelmuts is verified member.]

In my experience one agent replaces a full dev team. I used to work with 15 teams of 6 to 10 people.
Each team could handle a couple of stories in parallel without getting too much in each others way, as they picked stories that touched different microservices or modules.

An implementation that took 2-3 days is now done in a minute. With manual engineering we won a lot by implementing in parallel, now not so much any more.

What I now experience is that I have different agents as engineers working on e2e features with a focus in a specific module/service/projects.
To accomplish the least amount of cross-over it's important to have good seperation of concerns in the initial architecture, or the agents will suffer a lot from coordination overhead, just like in real life.

One agent works on the public documentation, another one on the api, etc. But they finish so fast that you have to keep throwing work at them.
And then there are some other agents that do reviews and stuff (quality, security, smoke tests, monitoring, ...)

In the beginning I used to spawn specialist agents to keep the context lean etc. but nowadays much less.
Agents can take much context and are much smarter, they can handle a lot more code than a single module in a project.

I start agreeing to you.. once the 1 agent setup was replaced with 8 = there are no real changes.. just bla bla bla... lots of talking, processes and tonnes of burnt credits... tonnes

 

[HelmutsHelmuts is verified member.]

In my experience one agent replaces a full dev team. I used to work with 15 teams of 6 to 10 people.
Each team could handle a couple of stories in parallel without getting too much in each others way, as they picked stories that touched different microservices or modules.

An implementation that took 2-3 days is now done in a minute. With manual engineering we won a lot by implementing in parallel, now not so much any more.

What I now experience is that I have different agents as engineers working on e2e features with a focus in a specific module/service/projects.
To accomplish the least amount of cross-over it's important to have good seperation of concerns in the initial architecture, or the agents will suffer a lot from coordination overhead, just like in real life.

One agent works on the public documentation, another one on the api, etc. But they finish so fast that you have to keep throwing work at them.
And then there are some other agents that do reviews and stuff (quality, security, smoke tests, monitoring, ...)

In the beginning I used to spawn specialist agents to keep the context lean etc. but nowadays much less.
Agents can take much context and are much smarter, they can handle a lot more code than a single module in a project.

Do you also use Hermes? or, OpenClaw? .. or something else? have a great weekend!!