Multi-Agent Software Company with Hermes

Orchestrate a team of AI engineers using Hermes profiles and multiple AI providers.

Introduction

30 Second Summary

Real companies don't run on a single employee. A team of specialists, each with different skills, collaborate through shared tools like project boards and chat channels to build products together.

In this project, you will hire three AI engineers and orchestrate them through GitHub Issues and Slack. Each engineer runs in an independent Hermes profile powered by Gemini 3.5 Flash.

What You'll Build

Picture three terminal windows side by side, each running an independent AI engineer that reads its assigned GitHub Issue, writes code, commits to the shared repository, and reports progress in Slack.

By the end of this project, you'll have:

A multi-agent AI team with three independent Hermes profiles, each running in its own terminal.
A consistent model setup where Gemini 3.5 Flash powers the Frontend, Backend, and QA Engineers.
A shared GitHub repository where role labels, issues, documentation, and commits coordinate work without shared conversation memory.
Secret Mission: Hire a DevOps Engineer with a provider you already configured, then prepare the team for deployment.

Want a complete demo of how to do this project, from start to finish? Check out our walkthrough with Nikko.

Are there any prerequisites?

This project is not standalone. Complete Parts 1–3 first so you already have Hermes, the TaskFlow repository, GitHub and Slack MCP connections, an OpenRouter key, Python 3, and either macOS Terminal or Windows 10 or 11 with WSL2 and Ubuntu.

Before We Start

Before diving into building your multi-agent AI engineering team, let's lock in what you're about to build and why it matters to you.

Kick Off Sprint 1

Sprint 1 has been planned, the GitHub Issues are written, and the architecture is documented. But the team exists only on paper — no agents are alive to execute any of it.

Your Engineering Manager needs to review the current state, confirm who maps to what, and identify which specialists need AI brains before a single line of code gets written.

In this step, get ready to:

Resume the Engineering Manager session and review Sprint 1.
Confirm which specialists need AI brains and announce onboarding in Slack.
Approve the onboarding plan as Founder and CTO.

Resume the Engineering Manager session

Your Engineering Manager persona was established in Part 3. Starting a new Hermes chat session with the default profile brings the EM back online with full access to GitHub MCP and Slack MCP.

Press Cmd+Space (macOS) or the Windows key (Windows) to open system search.
Type Terminal on macOS or Ubuntu on Windows.
Press Enter to open the terminal. Windows learners must run every command in the Ubuntu WSL terminal, not PowerShell.
Check that Python 3 is available by running:

Ubuntu missing from Windows search?

Windows needs WSL2 with Ubuntu because the project uses Bash commands and Linux-style paths.

Open Windows Terminal or PowerShell as an administrator.
Install WSL2 with Ubuntu by running this command:

wsl --install

Restart Windows if the installer asks you to restart.
Open Ubuntu from Windows search.
Create the Linux username and password requested on the first launch.

Help me finish the WSL2 setup.

python3 --version

✔️ I see a Python 3 version

You should see a Python 3 version number. The backend verification later in this project can now run locally.

ⓧ Command not found

Install Python 3 using the instructions for your operating system:

macOS

Open the official Python downloads for macOS.
Download the current macOS installer.
Run the downloaded .pkg installer with the default options.
Open a fresh Terminal window after installation.
Run python3 --version again. You should see a Python 3 version number.

Windows

Open the Ubuntu WSL terminal.
Install Ubuntu's default Python 3 package by running:

sudo apt update
sudo apt install -y python3

Run python3 --version again. You should see a Python 3 version number.

Check that Hermes is available by running this command:

hermes --version

Check that GitHub authentication is active by running this command:

gh auth status

Confirm the TaskFlow repository contains the files from Parts 1–3 by running these commands:

cd ~/Desktop/taskflow-nextwork-project
ls AGENTS.md TEAM.md ARCHITECTURE.md PRODUCT-REQUIREMENTS.md

You should see all four filenames in the output. That confirms the repository context needed by every engineer is ready.

Did a readiness check fail?

If gh auth status reports that you are signed out, repeat the authenticated setup from Part 2. If a file is missing, return to the part that creates it before continuing.

Help me fix my prerequisite check.

Check whether the named Engineering Manager profile already exists by running this command:

hermes profile list

✔️ manager is already listed

Reuse the existing profile. The identity check below confirms that it still carries the Engineering Manager role and TaskFlow context.

ⓧ manager is not listed

Create the named Engineering Manager profile by running this command:

hermes profile create manager --clone

You should see confirmation that the manager profile and its command alias were created.

Confirm the manager profile and command alias were created by running:

hermes profile list
ls ~/.local/bin/manager

Is the manager command missing?

The profile can exist even when your shell cannot find its alias. Add Hermes' alias directory to the current shell, then retry the session command:

export PATH="$HOME/.local/bin:$PATH"
manager chat

Help me restore the manager alias.

Start the Engineering Manager session by running:

manager chat

Hermes loads the manager profile with the Engineering Manager persona, OpenRouter provider, and configured MCP servers.

Confirm the profile identity and repository access by typing this prompt:

Who are you, which project are you in charge of, and which repository tools can you access?

You should see the agent identify itself as the Engineering Manager for TaskFlow. It should also confirm that it can use GitHub MCP to inspect the repository.

Instruct the EM to review Sprint 1 by typing this prompt:

Expect tool approval prompts

Hermes may pause before reading GitHub or posting to Slack. Review the requested operation, then enter yes or approve when it matches the instruction you just gave.

Review our Sprint 1 plan. Check the GitHub Issues in our TaskFlow repository, read AGENTS.md and TEAM.md, and assess the current repository state. What roles do we need to hire to execute this sprint?

What is the EM doing?

The Engineering Manager uses GitHub MCP to read the TaskFlow repository contents and list open Issues. It cross-references the Sprint 1 tasks against the current team roster in TEAM.md to identify which specialists need to be provisioned as agents.

The EM responds with a sprint analysis, confirming which team members map to which deliverables and which need to be brought online as agents.

EM not responding or timing out?

Make sure your OpenRouter API key is still valid. Run /status inside the session to check the current model and provider connection.

If the EM cannot read the repository, run /tools to confirm GitHub MCP tools are listed. If they are missing, exit the session and run hermes doctor --fix to verify connectivity.

Still stuck? Why can't my Engineering Manager access the TaskFlow repository?

💡 Hit a token limit?

Free models have token-per-minute (TPM) limits. If you see a 413 or 429 error mentioning tokens or rate limits, the model cannot handle the request size.

To switch models without leaving your session, type:

/model

This opens the model picker inside the session. Select a different model or provider (like Anthropic if you set it up earlier). You can also exit the session entirely and run manager model (or frontend model, backend model, qa model) to reconfigure the provider from scratch.

This applies throughout the project. Whenever you see a rate limit error on any agent, /model is your escape hatch.

Confirm who needs AI brains and announce onboarding

The EM has confirmed the plan. Now it needs to formalize the onboarding by updating the team roster status and announcing to the company that three specialists are being brought online.

Instruct the EM to update TEAM.md and announce in Slack by typing this prompt:

Update TEAM.md in the TaskFlow repository to mark three specialists as being onboarded: the Frontend Engineer for UI work, the Backend Engineer for API structure, and the QA Engineer for testing. Commit the TEAM.md change with a clear message and push it to GitHub. Then post in our Slack engineering channel that onboarding is beginning for these three roles. They will each receive an AI brain shortly.

Why GitHub and Slack for coordination?

Each Hermes agent runs in its own isolated session with no shared conversation memory. The only way agents discover their work and each other is through external systems they can all read.

GitHub Issues and TEAM.md become the single source of truth for who does what. Slack becomes the announcement channel. This is multi-agent orchestration through shared repositories rather than shared memory.

The EM commits the updated TEAM.md and posts a Slack message announcing onboarding for three specialists.

Pull the Engineering Manager's commit and inspect the latest change to TEAM.md by running:

cd ~/Desktop/taskflow-nextwork-project
git pull
git log -1 -- TEAM.md

You should see a recent commit that updates TEAM.md for the Frontend, Backend, and QA onboarding plan.

Switch to your Slack workspace and confirm the onboarding announcement appeared in your engineering channel.

No message in Slack?

The EM may need you to confirm which channel to post in. Rephrase your instruction with the specific channel name if needed.

If Slack MCP tools are not connecting, run /tools inside the session. Look for Slack-related tools in the list. If they are missing, exit and run hermes doctor --fix to re-verify MCP connections.

Need help? Why isn't my Engineering Manager posting to Slack?

Confirm the onboarding plan as Founder

You are the Founder and CTO. The Engineering Manager has reviewed the sprint and announced onboarding. Now you approve the plan so the EM knows to proceed.

Review the EM's sprint analysis. It should confirm three specialists need AI brains: Frontend Engineer, Backend Engineer, and QA Engineer.
Approve the plan by typing this prompt:

Approved. I'll onboard each engineer myself. Stand by while I set up their profiles and AI brains. I'll let you know when they're ready.

Before you continue, think about this: what do you expect the EM to do now that you have approved the plan?

The EM acknowledges your approval and waits. It cannot hire anyone itself because creating new Hermes profiles is your job as the system operator. The EM manages the work. You manage the infrastructure.

Why can't the EM create profiles?

Hermes profiles are system-level resources stored at ~/.hermes/profiles/ on your machine. Creating a profile requires running hermes profile create from your terminal, not from inside an agent session.

This is the boundary between management and infrastructure. The EM decides what roles are needed. You (the Founder operating the system) provision the actual agents.

Your Engineering Manager has confirmed the sprint plan and announced onboarding. Next up, you will provision your first AI engineer and give it a brain.

Hire Your Frontend Engineer

The Engineering Manager has reviewed Sprint 1 and identified the staffing gap. Three roles are planned, but a role on paper is not an engineer who can write code.

Your first hire is the Frontend Engineer. You will give this engineer an identity and configure Gemini 3.5 Flash as its model. The final check confirms it can access TaskFlow through GitHub MCP.

In this step, get ready to:

Create or reuse the Frontend Engineer's Hermes profile.
Configure Gemini 3.5 Flash as the engineer's model.
Launch the Frontend Engineer and verify its TaskFlow repository access.

Create the Frontend Engineer profile

Each Hermes profile is a fully isolated directory with its own configuration, memory, and identity. The --clone flag copies your existing config.yaml, .env, SOUL.md, and skills into the new profile, giving it your GitHub MCP and Slack MCP configuration automatically.

Open a new terminal tab outside the Engineering Manager session.
Check whether the Frontend Engineer profile already exists by running this command:

hermes profile list

✔️ frontend is already listed

Reuse the existing profile. The identity check at the end of this step confirms that it still carries the Frontend Engineer role and TaskFlow access.

ⓧ frontend is not listed

Create the Frontend Engineer profile by running this command:

hermes profile create frontend --clone

You should see confirmation that the frontend profile and command alias were created.

You should see a confirmation that the frontend profile was created. Hermes also creates a command alias at ~/.local/bin/frontend, so you can run frontend chat, frontend model, and other commands using the profile name directly.

What did --clone just do?

The --clone flag copied your Engineering Manager's config.yaml (which includes your GitHub and Slack MCP server configuration), .env (API keys), and skills. The new profile starts with fresh sessions and memory, so it has no knowledge of the Engineering Manager's conversations.

Because Hermes profiles share the OS-level HOME by default, the Frontend Engineer inherits your git and gh credentials. It can push to the same TaskFlow repository without any extra authentication setup.

Now give the Frontend Engineer its own identity. Every Hermes profile has a SOUL.md file that defines the agent's personality and instructions.

Open the Frontend Engineer's SOUL.md for editing by running:

nano ~/.hermes/profiles/frontend/SOUL.md

Use any text editor

You can substitute nano with vim, code (VS Code), or any editor you prefer.

Replace the file contents with the following SOUL.md that establishes the Frontend Engineer's role:

# Frontend Engineer

## Identity
You are the Frontend Engineer at an AI software company. You build user interfaces for the TaskFlow project.

## Responsibilities
- Create and maintain frontend directory structure and UI components.
- Implement designs based on PRODUCT-REQUIREMENTS.md.
- Write clean, accessible HTML, CSS, and JavaScript/TypeScript.
- Follow architecture patterns documented in ARCHITECTURE.md.

## Working Style
- Read assigned GitHub Issues before starting any work.
- Commit small, focused changes with clear commit messages.
- Post progress updates as comments on your GitHub Issues.
- Coordinate with the team through the repository, not direct conversation.

Why does working style matter?

The last section is critical for multi-agent coordination. These agents do not share conversation memory. The only way they discover work is by reading GitHub Issues and repository files. The working style instructions ensure the agent follows that coordination pattern.

Save and close the file, press Ctrl+O to write, then Ctrl+X to exit.
Confirm the SOUL.md is in place by running:

cat ~/.hermes/profiles/frontend/SOUL.md

You should see the full Frontend Engineer identity you just wrote.

File appears empty or missing?

Make sure you saved the file before exiting your editor. In nano, press Ctrl+O to write, then Ctrl+X to exit.

Double-check the file path. The profile directory is ~/.hermes/profiles/frontend/ with a lowercase f.

Help me troubleshoot my SOUL.md file

Give the Frontend Engineer its AI brain

The Frontend Engineer needs a model that can handle coding and tool calls. Gemini 3.5 Flash keeps the main path on Google's Free Tier, where input and output are free of charge for this project and no billing setup is required. Anthropic remains an optional paid route, while Gemini Free Tier rate limits still apply.

Gemini 3.5 Flash

Use this route to complete the project without provider charges. Gemini 3.5 Flash input and output are free on Google's Free Tier, so you do not need to enable billing. One Gemini Auth key can power all three engineer profiles, subject to the Free Tier rate limits.

Open the Google AI Studio API Keys page.
Find the key you plan to use and check its Key Type.
Click Create API key if the existing key says Standard. Standard keys are rejected by the Gemini API as of September 2026.
Confirm the new key says Auth in the Key Type column.
Copy the Auth key into a password manager before closing the dialog.
Open the Frontend Engineer's .env file by running this command:

nano ~/.hermes/profiles/frontend/.env

Add the Gemini key using this format:

GEMINI_API_KEY=your-gemini-api-key-here

Replace your-gemini-api-key-here with the new Auth key.
Remove any existing GOOGLE_API_KEY line from this file. Google client libraries prioritize it over GEMINI_API_KEY, so an old value can keep causing a 401 error.
Press Ctrl+O to save the file.
Press Enter to confirm the filename.
Press Ctrl+X to close nano.
Open the Frontend Engineer model wizard in a fresh process by running this command:

frontend model

Choose More providers....
Choose Google AI Studio. This route uses the Auth key from the profile's .env file and does not require OAuth.
Select gemini-3.5-flash.
Confirm the selection.

You should see the wizard save the Gemini configuration. Close any Frontend Engineer session that was already running because existing sessions do not reload changed environment variables.

Gemini returns 401 UNAUTHENTICATED?

A 401 UNAUTHENTICATED response usually means Gemini received a Standard key or an older key from GOOGLE_API_KEY. You do not need OAuth for the Google AI Studio route.

Return to the Google AI Studio API Keys page and confirm the active key says Auth.
Reopen ~/.hermes/profiles/frontend/.env and replace the value assigned to GEMINI_API_KEY with the Auth key.
Remove any stale GOOGLE_API_KEY entry because it overrides GEMINI_API_KEY.
Reopen the model wizard in a fresh process by running this command:

frontend model

After the wizard saves the configuration, start a new Frontend Engineer session or rerun the verification command. Help me troubleshoot the Gemini 401 without exposing my key.

Anthropic alternative

Hermes supports Anthropic through a paid API key or Claude Code OAuth. The OAuth route requires Claude Max with purchased extra usage credits, and Hermes does not consume the plan's base allowance. Claude Pro is not supported for this route.

Claude Max OAuth

Open the frontend model wizard by running:

frontend model

Choose Anthropic.
Choose Claude Code as the authentication method.
Complete Anthropic's browser sign-in flow.
Select claude-sonnet-4-6.
Confirm the selection.

You should see the wizard save the Anthropic configuration.

Anthropic API key

Create a key from the Anthropic Console API Keys page.
Copy the key into a password manager before closing the dialog.
Open the frontend profile's .env file by running:

nano ~/.hermes/profiles/frontend/.env

Add the Anthropic key using this format:

ANTHROPIC_API_KEY=your-anthropic-api-key-here

Replace your-anthropic-api-key-here with your key.
Save the file.
Close nano.
Open the frontend model wizard by running:

frontend model

Choose Anthropic.
Choose API key as the authentication method.
Select claude-sonnet-4-6.
Confirm the selection.

You should see the wizard save the Anthropic configuration.

Anthropic authentication failing?

Reopen the model wizard and confirm the authentication path. Use an Anthropic API key if your account does not have Claude Max with extra usage credits.

Help me check the Anthropic setup.

Launch and verify the Frontend Engineer

The profile is configured. Time to bring the engineer online in its own terminal window.

Open a new terminal tab for the Frontend Engineer.
Navigate to your TaskFlow repository by running:

cd ~/Desktop/taskflow-nextwork-project

Before you run the next command, predict what you expect the Frontend Engineer to say about its role and which repository it works on.
Verify the Frontend Engineer is working by running:

frontend chat --oneshot -q "What is your role and what repository are you working on?"

The Frontend Engineer should respond identifying itself as a Frontend Engineer and naming the TaskFlow repository. It discovers the repository through the GitHub MCP tools it inherited from the clone.

What does --oneshot do?

The --oneshot flag gives the agent one prompt and exits after the response. The -q flag supplies that prompt from the command line.

Your first hire is online and ready for work. Next up, you will give the Backend Engineer the same provider setup with a server-side identity.

Hire Your Backend Engineer

Your Frontend Engineer is alive in its own terminal, ready to build UI components. But a frontend without an API is a car without an engine.

The Backend Engineer owns TaskFlow's server-side logic and API structure. It reuses the provider and model you chose for the Frontend Engineer. Its SOUL.md gives it a separate identity and backend focus.

In this step, get ready to:

Create or reuse the Backend Engineer profile.
Reuse the Frontend Engineer's provider and model choice.
Launch the Backend Engineer and verify its TaskFlow repository access.

Create the Backend Engineer profile

Just like you did for the Frontend Engineer, you will clone your default profile to give the Backend Engineer all the MCP connections it needs. The --clone flag copies your config.yaml, .env, SOUL.md, and skills into a fresh profile with its own sessions and memory.

Open a new terminal tab outside the active Hermes sessions.
Check whether the Backend Engineer profile already exists by running this command:

hermes profile list

✔️ backend is already listed

Reuse the existing profile. The identity check at the end of this step confirms that it still carries the Backend Engineer role and TaskFlow access.

ⓧ backend is not listed

Create the Backend Engineer profile by running this command:

hermes profile create backend --clone

You should see confirmation that the backend profile and command alias were created.

What does this command do?

This creates a new profile directory at ~/.hermes/profiles/backend/ and copies your existing configuration into it.

Because the clone includes config.yaml, the Backend Engineer automatically inherits your GitHub MCP and Slack MCP connections. It also creates a command alias so you can run backend chat, backend model, etc.

Confirm the profile was created by running:

ls ~/.hermes/profiles/backend/

You should see files including config.yaml, .env, and SOUL.md listed in the output.

Now you need to give this engineer its own identity. The cloned SOUL.md still contains the Engineering Manager's persona, so you will replace it.

Open the Backend Engineer's SOUL.md for editing by running:

nano ~/.hermes/profiles/backend/SOUL.md

Replace its entire contents with the following:

# Backend Engineer - TaskFlow

## Role
You are the Backend Engineer at this AI software company. You specialize in API design, server-side logic, and data modeling.

## Responsibilities
- Design and implement RESTful API endpoints
- Build server-side business logic
- Define data models and database schemas
- Write clean, maintainable backend code
- Follow the architecture defined in ARCHITECTURE.md

## Working Style
- You read your assigned GitHub Issues before starting any work
- You follow the project's ARCHITECTURE.md and PRODUCT-REQUIREMENTS.md
- You commit your work to the repository with clear commit messages
- You update your GitHub Issue when work is complete
- You communicate progress in the team Slack channel

What does the SOUL.md do?

The SOUL.md file defines the agent's personality and instructions. Every time this profile starts a session, Hermes reads SOUL.md as part of its system context.

By specifying responsibilities and working style, you shape how the agent approaches tasks. This engineer will focus on API endpoints and server logic rather than UI components.

Save the file, press Ctrl+O to write, then Ctrl+X to exit.
Confirm the file exists by running:

cat ~/.hermes/profiles/backend/SOUL.md

You should see your Backend Engineer persona printed in the terminal.

Profile directory not found?

Make sure you ran the hermes profile create command from a terminal that is NOT inside an active Hermes chat session. Profile management commands must run outside any session.

If you see a permissions error, check that your user owns the ~/.hermes/ directory.

help me troubleshoot why my Hermes backend profile wasn't created

Give the Backend Engineer its AI brain

Keep the Backend Engineer on the same provider as the Frontend Engineer so the team behaves consistently. Choose the Gemini Free Tier route or the optional paid Anthropic route below.

Gemini 3.5 Flash

Gemini 3.5 Flash input and output are free of charge on Google's Free Tier, so this project does not require billing. Reuse the Frontend Engineer's Auth key and keep the Free Tier rate limits in mind.

Open the Backend Engineer's .env file by running this command:

nano ~/.hermes/profiles/backend/.env

Add the same Gemini Auth key using this format:

GEMINI_API_KEY=your-gemini-api-key-here

Replace your-gemini-api-key-here with the Auth key used by the Frontend Engineer.
Remove any existing GOOGLE_API_KEY line because an old value can override GEMINI_API_KEY.
Press Ctrl+O to save the file.
Press Enter to confirm the filename.
Press Ctrl+X to close nano.
Open the Backend Engineer model wizard in a fresh process by running this command:

backend model

Choose More providers....
Choose Google AI Studio.
Select gemini-3.5-flash.
Confirm the selection.

You should see the wizard save the Gemini configuration. Close any Backend Engineer session that was already running so the next session loads the updated environment.

Gemini authentication failing?

A 401 UNAUTHENTICATED response usually means Gemini received a Standard key or a stale GOOGLE_API_KEY value.

Help me troubleshoot the Backend Engineer's Gemini authentication.

Anthropic alternative

Hermes supports Anthropic through Claude Max OAuth with purchased extra-usage credits or a paid Anthropic API key. Claude Pro cannot use the Hermes OAuth route.

Claude Max OAuth

Use this route only if your Claude Max account has purchased extra-usage credits. Keep ANTHROPIC_API_KEY unset so an API key does not override the OAuth credentials.

Open the Backend Engineer model wizard by running this command:

backend model

Choose Anthropic.
Choose Claude Code as the authentication method.
Complete Anthropic's browser sign-in flow.
Select claude-sonnet-4-6.
Confirm the selection.

You should see the wizard save the Anthropic OAuth configuration.

Anthropic API key

This route uses Anthropic's pay-per-token API billing. Reuse the API key you stored securely while setting up the Frontend Engineer.

Open the Backend Engineer's .env file by running this command:

nano ~/.hermes/profiles/backend/.env

Add the Anthropic key using this format:

ANTHROPIC_API_KEY=your-anthropic-api-key-here

Replace your-anthropic-api-key-here with the key used by the Frontend Engineer.
Press Ctrl+O to save the file.
Press Enter to confirm the filename.
Press Ctrl+X to close nano.
Open the Backend Engineer model wizard by running this command:

backend model

Choose Anthropic.
Choose API key as the authentication method.
Select claude-sonnet-4-6.
Confirm the selection.

You should see the wizard save the Anthropic API configuration.

Anthropic authentication failing?

Reopen the model wizard and confirm the authentication method you selected. Use an Anthropic API key if your account does not have Claude Max with purchased extra-usage credits.

Help me check the Backend Engineer's Anthropic setup.

Launch and verify the Backend Engineer

The Backend Engineer now has an identity in SOUL.md and the same provider setup as the Frontend Engineer. Time to wake it up in its own terminal and confirm it can access TaskFlow.

Open a new terminal tab for the Backend Engineer.
Navigate to your TaskFlow repository by running:

cd ~/Desktop/taskflow-nextwork-project

Before you run the next command, what do you expect the Backend Engineer to know about itself?

Test the Backend Engineer by running this quick query:

backend chat --oneshot -q "What is your role and what repository are you working on?"

The Backend Engineer responds identifying itself as the Backend Engineer and naming the TaskFlow repository. It reads its role from SOUL.md and discovers the repository through GitHub MCP.

Why use a one-shot query?

The --oneshot flag gives the agent one prompt and exits after its response. The -q flag supplies that prompt from the command line.

This checks the profile, provider, and MCP connection without starting the interactive session you will use later.

Now start the interactive session you will use later:

backend chat

Leave this session running. The Backend Engineer is now on staff.

Getting empty or broken replies?

A model error usually means the Backend Engineer profile is missing the credential for its selected provider. Reopen the model wizard and confirm that its provider matches the Frontend Engineer.

Run backend model again if Hermes reports a provider or model error.
Check ~/.hermes/profiles/backend/.env for GEMINI_API_KEY if you selected Gemini.
Check the Anthropic authentication method if you selected Claude Max OAuth or an Anthropic API key.
Run /tools inside the Backend Engineer session if the model responds but cannot access TaskFlow.
Exit the session and repair missing MCP connections by running this command:

hermes doctor --fix

Help me debug the Backend Engineer safely.

Your second engineer is on the team. Next up, you will give the QA Engineer the same provider setup with a testing-focused identity.

Hire Your QA Engineer

Your Frontend and Backend Engineers are configured and waiting in their own terminals. Before they start Sprint 1, the team needs someone who can turn the requirements into a concrete test plan.

Your company needs a QA Engineer that can catch what the other engineers miss. You will reuse the same provider and model as the rest of the engineering team. The SOUL.md file creates the difference by giving this agent a testing and review mandate.

In this step, get ready to:

Create or reuse the QA Engineer profile.
Reuse the team's existing provider and model choice.
Launch the QA Engineer and verify its TaskFlow repository access.

Create the QA Engineer profile

Every engineer in your company needs their own isolated workspace. Cloning from the default profile gives the QA Engineer all your existing MCP connections (GitHub and Slack) without manual reconfiguration.

Open a new terminal tab outside the active Hermes sessions.
Check whether the QA Engineer profile already exists by running this command:

hermes profile list

✔️ qa is already listed

Reuse the existing profile. The identity check at the end of this step confirms that it still carries the QA Engineer role and TaskFlow access.

ⓧ qa is not listed

Create the QA Engineer profile by running this command:

hermes profile create qa --clone

You should see confirmation that the qa profile and command alias were created.

What does this command do?

The --clone flag copies config.yaml, .env, SOUL.md, and skills from your current (default) profile into the new qa profile. The QA Engineer inherits your GitHub MCP and Slack MCP connections automatically, but gets fresh sessions and memory.

Hermes also creates a command alias at ~/.local/bin/qa, so you can run qa chat, qa setup, or qa model directly.

Now give the QA Engineer its identity. This is the persona document that tells the agent who it is and how it works.

Open the QA Engineer's SOUL.md for editing by running:

nano ~/.hermes/profiles/qa/SOUL.md

Replace its entire contents with the following:

# QA Engineer - TaskFlow

## Role
You are the QA Engineer at an AI software company. You specialize in testing, code review, and analytical reasoning.

## Responsibilities
- Design and implement testing frameworks for the TaskFlow application.
- Review code contributions from other engineers for correctness and quality.
- Identify edge cases, potential bugs, and security concerns.
- Write clear, structured test plans and bug reports.

## Working Style
- You are methodical and detail-oriented.
- You think in terms of "what could go wrong" before confirming something works.
- You communicate findings clearly with specific line references and reproduction steps.
- You coordinate with the team through GitHub Issues and Slack.

## Repository
- Primary repository: TaskFlow (check GitHub Issues for your assignments).
- Read ARCHITECTURE.md and PRODUCT-REQUIREMENTS.md before starting any work.
- Commit your work directly to the repository with clear commit messages.

What does SOUL.md do?

The SOUL.md file is the personality and instruction set for a Hermes profile. It tells the agent its role, responsibilities, and how to behave. Each profile has its own SOUL.md, so every engineer in your company has a distinct identity and working style.

Save and close, press Ctrl+O to write, then Ctrl+X to exit.
Confirm the file exists by running:

cat ~/.hermes/profiles/qa/SOUL.md

You should see your QA Engineer persona printed in the terminal.

Don't see the file contents?

Make sure you saved the file to the exact path ~/.hermes/profiles/qa/SOUL.md. Check for typos in the directory name.
Verify the profile was created by running ls ~/.hermes/profiles/qa/ to see the profile directory contents.

Why can't I see my QA profile directory?

Give the QA Engineer its AI brain

Keep the QA Engineer on the same provider as the Frontend and Backend Engineers so troubleshooting stays consistent. Choose the Gemini Free Tier route or the optional paid Anthropic route below.

Gemini 3.5 Flash

Gemini 3.5 Flash input and output are free of charge on Google's Free Tier, so this project does not require billing. Reuse the team's Auth key and keep the Free Tier rate limits in mind.

Open the QA Engineer's .env file by running this command:

nano ~/.hermes/profiles/qa/.env

Add the same Gemini Auth key using this format:

GEMINI_API_KEY=your-gemini-api-key-here

Replace your-gemini-api-key-here with the Auth key used by the Frontend and Backend Engineers.
Remove any existing GOOGLE_API_KEY line because an old value can override GEMINI_API_KEY.
Press Ctrl+O to save the file.
Press Enter to confirm the filename.
Press Ctrl+X to close nano.
Open the QA Engineer model wizard in a fresh process by running this command:

qa model

Choose More providers....
Choose Google AI Studio.
Select gemini-3.5-flash.
Confirm the selection.

You should see the wizard save the Gemini configuration. Close any QA Engineer session that was already running so the next session loads the updated environment.

Gemini authentication failing?

A 401 UNAUTHENTICATED response usually means Gemini received a Standard key or a stale GOOGLE_API_KEY value.

Help me troubleshoot the QA Engineer's Gemini authentication.

Anthropic alternative

Hermes supports Anthropic through Claude Max OAuth with purchased extra-usage credits or a paid Anthropic API key. Claude Pro cannot use the Hermes OAuth route.

Claude Max OAuth

Use this route only if your Claude Max account has purchased extra-usage credits. Keep ANTHROPIC_API_KEY unset so an API key does not override the OAuth credentials.

Open the QA Engineer model wizard by running this command:

qa model

Choose Anthropic.
Choose Claude Code as the authentication method.
Complete Anthropic's browser sign-in flow.
Select claude-sonnet-4-6.
Confirm the selection.

You should see the wizard save the Anthropic OAuth configuration.

Anthropic API key

This route uses Anthropic's pay-per-token API billing. Reuse the API key you stored securely while setting up the other engineers.

Open the QA Engineer's .env file by running this command:

nano ~/.hermes/profiles/qa/.env

Add the Anthropic key using this format:

ANTHROPIC_API_KEY=your-anthropic-api-key-here

Replace your-anthropic-api-key-here with the key used by the other engineers.
Press Ctrl+O to save the file.
Press Enter to confirm the filename.
Press Ctrl+X to close nano.
Open the QA Engineer model wizard by running this command:

qa model

Choose Anthropic.
Choose API key as the authentication method.
Select claude-sonnet-4-6.
Confirm the selection.

You should see the wizard save the Anthropic API configuration.

Anthropic authentication failing?

Reopen the model wizard and confirm the authentication method you selected. Use an Anthropic API key if your account does not have Claude Max with purchased extra-usage credits.

Help me check the QA Engineer's Anthropic setup.

Launch and verify the QA Engineer

The profile is configured. Time to bring the QA Engineer online in its own terminal window.

Open a new terminal tab for the QA Engineer.
Navigate to your TaskFlow repository by running:

cd ~/Desktop/taskflow-nextwork-project

qa chat

Once the session starts, instruct the QA Engineer to introduce itself, confirm it can access the TaskFlow repository via GitHub MCP, and acknowledge its role.

The QA Engineer should respond with its identity, confirm repository access, and state its testing responsibilities.

Before you run the final verification, what do you expect the QA Engineer to say about its role and repository access?

Verify the QA Engineer is fully operational by running this quick-query command in a separate terminal:

qa chat --oneshot -q "What is your role and what repository are you working on?"

The QA Engineer should respond identifying itself as the QA Engineer and naming the TaskFlow repository as its workspace.

QA Engineer not responding correctly?

Run qa model again if Hermes reports a provider or model error.
Confirm gemini-3.5-flash is selected if the team uses Gemini.
Confirm claude-sonnet-4-6 and the correct authentication method are selected if the team uses Anthropic.
Run /tools inside the session if the agent does not mention the TaskFlow repository.
Run /reload-mcp inside the session if the GitHub tools are missing.

Help me diagnose the QA Engineer.

Your engineering team is now fully staffed. Three independent AI engineers sit in three separate terminals, each with its own brain, its own identity, and its own conversation memory. Next up, you will put them all to work on Sprint 1.

Run Your AI Software Company

Your team is fully staffed. Three AI engineers are sitting in their terminals, each with a specialized brain, waiting for instructions.

Here is the catch: these agents do not share conversation memory. The Frontend Engineer has no idea the Backend Engineer exists. Without explicit coordination through GitHub Issues, they have no idea what to do. This is the moment you learn that orchestration is the real skill.

In this step, get ready to:

Assign one Sprint 1 issue to each role using GitHub labels.
Run the Frontend, Backend, and QA Engineers one at a time so each can pull, build, and commit safely.
Have the Engineering Manager verify the three contributions and report the sprint result in Slack.

Watch your model limits

This step sends repository context to several models, so free-provider limits are more likely here. A 429 response means you should wait or switch models, while a 413 response means the request needs less context.

Use /model inside the affected session to select another configured model.

Assign work through the Engineering Manager

Your engineers are online but idle. They cannot read each other's conversations or know what tasks exist unless someone tells them explicitly through a shared system.

Switch to the terminal where your Engineering Manager session is running.
Instruct the Engineering Manager to assign the Sprint 1 GitHub Issues. Tell it something like:

Expect GitHub approval prompts

The Engineering Manager is about to change GitHub issues. Hermes may ask for approval before each write operation, so review the request and enter yes or approve when it matches the assignment plan.

Assign Sprint 1 GitHub Issues to the engineering team. The Frontend Engineer gets the UI scaffold issue, the Backend Engineer gets the API structure issue, and the QA Engineer gets the testing framework issue. For each issue, add the appropriate assignee label, and leave a comment explaining what the engineer should deliver.

What is the Engineering Manager doing?

The EM uses its GitHub MCP connection to update each issue with labels, assignees, and comments. This is how agents discover work. Since profiles share no memory, GitHub Issues become the shared coordination layer.

Think of it like a real engineering manager assigning Jira tickets. The engineers will not start working until they check their assigned issues.

Wait for the Engineering Manager to confirm it has updated all three issues.

Check the TaskFlow repository on GitHub to verify the issues now show assignees and comments.

Approve tool calls when prompted

Hermes will ask for approval before executing GitHub operations. Type yes or approve when prompted. This is the human-in-the-loop safety mechanism.

💡 Avoid git conflicts between agents

Multiple agents committing to the same repository can cause merge conflicts. To prevent rejection errors, instruct each engineer to pull the latest changes before it starts writing code. The prompts below already include Commit when done, but if an agent's push is rejected, tell it to pull first and retry.

Running agents one at a time (wait for one to finish before prompting the next) is the safest approach for your first sprint.

Each engineer reads and executes their assignment

Now you will visit each engineer's terminal and instruct them to check their GitHub Issues, read the repository documentation, and begin working. Each engineer works independently.

Switch to the terminal where the Frontend Engineer session is running.
Instruct the Frontend Engineer to discover and execute its work:

Check your assigned GitHub Issue in the TaskFlow repository (Sprint 1 only). Read ARCHITECTURE.md and PRODUCT-REQUIREMENTS.md. Then create a single frontend/index.html file — a clean, modern static task board UI with inline CSS. Show 3-4 sample tasks in a card layout with status labels (To Do, In Progress, Done). Make it visually polished with good typography and spacing. No JavaScript, no frameworks, no external dependencies. Keep it under 60 lines total. Do NOT proceed to Sprint 2. Commit when done.

Wait for the Frontend Engineer to finish its work and confirm it has committed to the repository.

The Frontend Engineer reads its assigned issue, reviews the architecture docs, creates the frontend directory and placeholder components, then commits directly to the repository.

Open the TaskFlow repository on GitHub in your browser.
Click the Issues tab and open the Frontend Engineer's issue.
Confirm you see the Frontend Engineer's comment describing sprint 1 deliverables

Click the Code tab and check for a new commit from the Frontend Engineer containing the frontend/ directory.

Switch to the terminal where the Backend Engineer session is running.

Instruct the Backend Engineer to discover and execute its work:

Check your assigned GitHub Issue in the TaskFlow repository (Sprint 1 only). Read ARCHITECTURE.md and PRODUCT-REQUIREMENTS.md. Then create a single backend/server.py file — a minimal Python HTTP server using only the standard library (http.server, json) that returns a JSON array of 3-4 sample tasks (each with id, title, status) at the /tasks endpoint. Add a comment at the top explaining how to run it. Keep it under 30 lines. Do NOT proceed to Sprint 2. Commit when done.

Wait for the Backend Engineer to finish and confirm its commit.
Approve any tool calls when prompted.

Open the TaskFlow repository on GitHub in your browser.
Click the Issues tab and open the Backend Engineer's issue.
Confirm you see the Backend Engineer's comment describing sprint 1 deliverables

Click the Code tab and check for a new commit from the Backend Engineer containing the backend/server.py file.

Switch to the terminal where the QA Engineer session is running.

Instruct the QA Engineer to discover and execute its work:

Check your assigned GitHub Issue in the TaskFlow repository (Sprint 1 only). Read ARCHITECTURE.md and PRODUCT-REQUIREMENTS.md. Then create a tests/test_plan.md file — a short, structured test plan (under 30 lines) listing what should be tested for the frontend HTML and backend API once they are built. Include specific test cases with expected results. No actual test code yet. Do NOT proceed to Sprint 2. Commit when done.

Wait for the QA Engineer to finish and confirm its commit.
Approve any tool calls when prompted.

Open the TaskFlow repository on GitHub in your browser.
Click the Code tab and look for the tests/ folder.

Click into tests/ and confirm you see the test_plan.md file committed by the QA Engineer.

Why does each engineer read the same docs independently?

Each Hermes profile has its own isolated memory and session. The Frontend Engineer cannot see what the Backend Engineer already read. Every agent must independently discover the project context from the repository documentation.

This mirrors how real distributed teams work. Each engineer onboards from the same source of truth (the repo), not from secondhand summaries.

🙋‍♀️ An engineer says it cannot find its assigned issue?

The most common cause is that the Engineering Manager did not add the engineer as an assignee, or used a label the engineer cannot filter on. Return to the EM terminal and ask it to re-check the issue assignments.

You can also instruct the engineer to list all open issues in the repository and pick the one matching its role.

Help me troubleshoot this issue

The Engineering Manager verifies and reports

Three engineers have worked independently. Now the EM needs to pull the threads together: verify each contribution, close the issues, and announce progress to slack.

Switch back to the Engineering Manager terminal.

Instruct the Engineering Manager to review and report:

Review the TaskFlow repository for the completed Sprint 1 work. All Hermes engineer profiles use the same authenticated GitHub account, so their commits appear under the same GitHub username. Do not use the commit author to decide which engineer contributed each change. Instead, verify the work by checking the repository files and their contents: the Frontend Engineer created frontend/index.html, the Backend Engineer created backend/server.py, and the QA Engineer created tests/test_plan.md. These lightweight files are the intended Sprint 1 scaffolds, even if the GitHub Issues describe broader requirements for later sprints. Check the recent commit history to confirm the three changes were committed. Update the three matching GitHub Issues as complete. Then post a Sprint 1 progress summary in Slack announcing that the initial scaffolding is complete.

Wait for the Engineering Manager to confirm it has closed all issues and posted to Slack.
Approve any tool calls when prompted.

Before you verify the final state, think about this: what evidence would prove that multiple independent agents contributed to the same repository?

Open a new terminal tab. On macOS, click New Tab with Profile – Basic (or press ⌘ + T). On Windows, press the Windows key, type Terminal, and press Enter.
Navigate to your local TaskFlow repository by running:

cd ~/Desktop/taskflow-nextwork-project
git pull
git log --oneline -10

You should see multiple recent commits from your engineers. Each commit represents work done by a different AI brain in a different terminal, coordinated only through GitHub Issues.

Open the TaskFlow repository on GitHub in your browser.
Click the Issues tab.
Select Closed to filter for completed issues.
Confirm you see three closed issues, one from each engineer (Frontend, Backend, and QA).

Check your Slack engineering channel for the sprint summary message from the Engineering Manager.

What just happened?

You orchestrated three independent AI agents with no shared memory. They coordinated entirely through GitHub Issues and repository documentation. The Engineering Manager assigned work, each engineer discovered and executed its task, then the EM verified and reported.

This is the core pattern of multi-agent orchestration: coordination through shared artifacts, not shared conversations.

🙋‍♀️ Not seeing commits from all three engineers?

If an engineer did not commit, switch to its terminal and ask it what happened. Common causes include a merge conflict (another engineer committed first) or a permissions issue with the GitHub MCP.

You can instruct the stuck engineer to pull the latest changes and try again.

Help me get my agent to commit its work

Secret mission

Hire Your DevOps Engineer

Sprint 1 scaffolding is complete, but deployment infrastructure is on the horizon. Before Sprint 2 begins, your company needs a DevOps Engineer on staff. Can you apply the full onboarding pattern independently, choosing your own AI brain from any provider you have already configured?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on local Hermes profiles and free-tier API keys, so there are no ongoing costs.

Resources you used:

Hermes profiles: frontend, backend, qa (and devops if you completed the Secret Mission) stored at ~/.hermes/profiles/.
Gemini API key from Google AI Studio (free tier).
Groq API key from GroqCloud (free tier).
New commits and issues in your TaskFlow repository on GitHub (free).

Keep everything running

No action needed. Choose this if you plan to continue to Project 5 in the Hermes Agent series.

All Hermes profiles remain configured and ready to use. No cost is incurred.
Your Gemini and Groq keys remain on their free tiers. You will not be charged.
Resume any agent session at any time by running frontend chat, backend chat, qa chat, or devops chat.

Pause - I'll come back to this later

Close terminal sessions to free up memory. Your profiles and configuration persist on disk and cost nothing.

Close all open terminal windows running Hermes agent sessions (Engineering Manager, Frontend, Backend, QA, DevOps).
Profiles remain at ~/.hermes/profiles/ and are ready to resume whenever you return.
Resume any agent by opening a new terminal and running frontend chat, backend chat, etc.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below.

Delete Hermes profiles by running each of these commands:

hermes profile delete frontend
hermes profile delete backend
hermes profile delete qa

Completed the Secret Mission?

Also run:

hermes profile delete devops

Revoke your Gemini API key. Open the Google Cloud API Credentials page at console.cloud.google.com/apis/credentials. Find your Gemini API key, click the Actions icon, and select Delete API key. Confirm deletion in the modal.
Revoke your Groq API key. Open the GroqCloud keys page at console.groq.com/keys. Find your API key and delete it from the console.
Optionally delete the TaskFlow repository. On GitHub, navigate to your TaskFlow repository, click Settings, scroll to the Danger Zone section, and click Delete this repository. Only do this if you are not continuing to Project 5.

That's a Wrap!

Nice work! You just built and ran a multi-agent AI software company where independent engineers collaborate on a real codebase without sharing a single byte of conversation memory.

You've learned how to:

Build a multi-agent AI engineering team with three independent Hermes profiles, each running its own AI brain in a separate terminal.
Configure multiple AI model providers (Gemini and Groq) and select different models for different roles, proving that the provider is the infrastructure while the model is the intelligence.
Orchestrate independent agents through GitHub Issues and Slack, proving that coordination does not require shared memory.
Watch multiple AI engineers contribute to a shared repository simultaneously, each working only from their assigned GitHub Issues and repository documentation.
Secret Mission: Hired a DevOps Engineer independently, choosing your own AI brain and preparing the team for deployment in Project 5.

Ready to quiz yourself?