← Back to Blog
Multi-Agent Workflows: Graph Engineering With Hermes.
Learn how multi-agent workflows use Hermes graph engineering to split research, check findings, remove false waits and keep final approval with a human.
Learn how multi-agent workflows use Hermes graph engineering to split research, check findings, remove false waits and keep final approval with a human.
A multi-agent workflow splits one job across several agents, lets independent work run together, and sends the findings through a separate checking step before you see the result.
I am using “graph engineering” here in the operational sense. It is not a knowledge graph that stores connected facts. It is an AI agent graph that connects jobs, dependencies, reviewers, and delivery steps. The goal is to decide who does each part of the work, which jobs can run at the same time, and where a human keeps the final approval.
Machina helped popularise the term, while also acknowledging that the pattern is much older than the name. Engineers pointed out that he was describing a decades-old pattern wearing a new name. I would rather learn a pattern that has survived for twenty years than chase a trick somebody named last Tuesday.
This article explains how to design a useful graph, when one agent is better, and how to build a research workflow in Hermes without handing every decision to a swarm.
Multi-agent workflows use multiple AI agents to complete one larger job. Each agent gets a narrower responsibility, and the workflow passes useful outputs between them.
One agent might research competitors. Another might check customer language. A third might verify sources. A final agent can merge the findings into a report.
That structure is different from asking one agent to perform five tasks in sequence. A sequential workflow creates a queue. A graph shows which tasks depend on one another and which tasks can run independently.
Hermes gives this structure a practical home through delegation, shared context, skills, cron, and approval controls. The Hermes Agent documentation is the right place to check the current implementation details before copying any command or configuration.
An AI agent graph is a map of jobs and dependencies. The nodes represent work, while the connections show which output another job needs.
A job is something you could hand to one assistant. Research a competitor is a job. Check whether a citation exists is another job. Draft the final report is a third.
A dependency exists only when the next job needs the previous result. The draft depends on the research because the draft reads the research. A calendar check does not depend on a file summary if it never opens that summary.
A simple research graph looks like this:
one research question
>> independent research angle A
>> independent research angle B
>> independent research angle C
>> skeptic checks the findings
>> merge the supported findings
>> report delivered
>> human approvalHermes turns the main request into delegated work. The researchers collect findings, the skeptic challenges them, and the merge step produces one answer from what survives.
That is the useful distinction between prompt engineering and graph engineering. Prompt engineering improves the instruction. Graph engineering decides which agent receives the instruction and who checks the result.
Multi-agent workflows become faster when you remove dependencies that do not carry real work.
“Summarise this file and check my calendar” sounds sequential because both tasks sit in the same sentence. The calendar check does not need the summary. Those jobs can run together.
Use this test on every connection in your workflow:
This is the cheapest improvement to make because it costs no new model call. You are changing the workflow design, not adding more agents.
Draw the current process on paper or in a simple diagram. Circle every “and then”. Inspect each one. If no information moves between the two steps, they are separate jobs pretending to be a chain.
A graph should represent the work that genuinely needs to happen. It should not preserve the order in which you happened to describe the work.
A separate checking agent is useful because the agent that produced a finding has already committed to it.
An agent asked to research a claim and then approve its own research has no real separation between production and review. It can still catch mistakes, but the checking instruction is competing with the original conclusion.
Give the skeptic one narrow question. It can check whether a claim is supported, whether a source exists, or whether the information is current. A vague request to “review the report” encourages a quick skim.
The skeptic should be able to remove findings. That is its purpose.
In Hermes, the researchers and skeptic can be delegated sub-agents. The skeptic reads the findings, challenges unsupported claims, and removes anything that cannot survive the checking question before the merge step.
As @codeglitch explains, Hermes Mixture of Agents is “routing plus synthesis, not a secret model that beats everything by default.” The graph does not make weak reasoning disappear. It gives the reasoning separate jobs and a visible place to challenge the output.
A graph makes the most sense when work needs to begin without you opening a coding window.
A coding session is a good environment for work you want to inspect as it happens. You can watch the edits, respond to questions, and decide what the agent should do next.
Scheduled research has a different requirement. You should not need to sit in front of five agents while they read competitor pages. The work needs to start, run, and deliver its result while you are doing something else.
Hermes supports this always-on pattern through cron and gateway delivery. A scheduled workflow can run the research jobs and deliver the report through a channel such as Telegram or Discord. The exact setup should follow the current Hermes documentation, since commands and configuration can change.
This is where Hermes differs from a tool that only exists inside a coding session. The graph is not valuable because it looks impressive while running. It is valuable when the work starts on schedule and the finished report reaches you without requiring a window to stay open.
For coding, I would still use a coding agent. For scheduled research, recurring briefings, and work that needs to arrive in a messaging channel, Hermes is the more natural fit.
One agent is better when every step needs the full context from the previous step.
A graph buys breadth. It does not automatically improve judgement. Five independent research angles can run separately. A tightly connected chain of reasoning usually benefits from one agent holding the whole thread.
In my own workflows, I split collection work when the sources are independent. I keep one agent on a decision when every conclusion changes the next one. I use a separate reviewer when a bad claim would damage the report. My final test is whether the extra worker has a distinct job or is only passing text along.
Use this decision rule:
More agents also mean more context and instructions being sent. One developer measured fixed overhead at 73 percent of each API call on an older Hermes build in GitHub issue #4379. That is one measurement on one setup, not a universal cost estimate. It is still a useful warning against adding agents without checking where the work actually splits.
Use lower-cost models for broad collection work when that fits the quality requirement. Keep the strongest model for judgement, verification, or the final merge.
Human approval belongs at the point where a mistake becomes expensive to undo.
Approving every small step turns you into the bottleneck. Removing every approval lets the first confident mistake reach a customer.
The useful gate is usually near the end:
Hermes supports approval controls for sensitive actions. A separate reviewer can flag a command, while a direct message approval can hold an outbound action until you answer.
That is the structure I want from an autonomous workflow. Let the agents collect, check, and prepare the work. Keep the final yes human when the action is difficult to reverse.
Research is the best first multi-agent workflow because the work usually splits into independent angles. A weak result costs time, not a client relationship or a customer message. I start there because I can inspect the evidence before I trust the same graph with an external action.
Start with one question. Do not begin by choosing five agents. Decide what the finished report needs to answer, which sources count, and where the result should land.
The workflow can look like this:
one research question
>> independent research angles run together
>> skeptic removes unsupported findings
>> merge step ranks the survivors
>> report delivered to Telegram
>> you decide what happens nextPaste a prompt like this into Hermes:
I want to set up a research graph.
Before you build anything, interview me about:
the question I am researching,
the angles worth splitting,
the sources that count as credible,
the evidence each researcher must provide,
and where the finished report should land.
Then build the workflow as delegated work:
one sub-agent per research angle running independently,
a separate skeptic sub-agent that challenges every finding,
and a merge step that keeps only supported findings.
Every surviving finding needs a source and a date.
The final report should identify uncertainty instead of filling gaps with guesses.
Save the workflow as a skill so I can run it again.
Do not schedule it yet.Run it manually first. Inspect what the skeptic removes. Check whether the merge step preserves useful sources rather than simply producing smoother prose.
Only schedule the workflow after you understand its failure modes. Then add the recurring trigger:
Schedule this research workflow for Monday at 9am.
Send the finished report to my Telegram.
Do not send any other message or take any outbound action without my approval.The schedule comes last. A reliable manual graph is useful. An unreliable scheduled graph only produces mistakes earlier in the day.
You can also compare this pattern with Claude Code multi-agent workflows and Claude Agent Teams. Those approaches can be a better fit when the work lives inside a coding project and needs shared files, code changes, or an active development session.
For the wider Hermes setup, read Hermes Agent before you build a scheduled graph.
Test the handoffs before testing the schedule.
Check whether each researcher receives the right question. Check whether each result includes enough evidence for the skeptic. Check whether the skeptic can remove a weak finding. Check whether the merge step can distinguish a strong source from a confident paragraph.
Then test delivery. The report should arrive in the channel you chose, with the source details intact.
If the final output is useful only when you sit beside the run and repair every step, it is not ready for cron. Keep working on the graph or reduce it to one agent until the result is dependable.
The first version does not need to be large. Two independent researchers, one skeptic, one merge step, and one approval gate are enough to learn the pattern.
Graph engineering is worth using with Hermes when the work has independent parts, needs recurring execution, and benefits from a checking step before delivery.
It is not worth using when the graph exists only to create the appearance of a team. More agents add cost and coordination. They do not replace a clear question or a good source.
My preferred starting point is simple:
That sequence gives you a real multi-agent workflow instead of a collection of agents passing text around.
A multi-agent workflow uses several AI agents to complete one larger job. Each agent handles a narrower responsibility, and the workflow connects their outputs through real dependencies.
An AI agent graph maps jobs, dependencies, reviewers, and delivery steps. It shows which tasks can run independently and which tasks must wait for another result.
Graph engineering is the design of an agent workflow around the structure of the work. It focuses on splitting jobs, removing false waits, assigning checking roles, and placing human approval at the right point.
Hermes is a good fit for multi-agent workflows that need delegation, recurring execution, and delivery through a messaging channel. A coding-focused agent may be a better fit when the work depends on an active codebase and continuous file changes.
Use multiple agents when the work separates into independent research or collection tasks. Use one agent when every step depends on the full context from the previous step.
A separate skeptic gives the workflow an independent checking role. It can challenge findings produced by other agents and remove unsupported claims before the merge step.
Hermes supports scheduled workflows through cron. Run the workflow manually first, confirm that the handoffs and output work, then schedule it according to the current Hermes documentation.
A human should approve actions that send messages, publish content, issue invoices, process refunds, or move money. The agents can prepare the work while the human keeps the final approval.
Official documentation for Hermes features and current configuration.
Source for the cited fixed-overhead measurement on an older build.
Source for the decades-old-pattern comment referenced in the introduction.
Source for the “routing plus synthesis” description.
Start with a research question that has independent angles. Remove the waits that carry no information, give the checking to a separate agent, and keep the final yes human.
The graph does not need to be large. It needs to match the work. When the setup is reliable, Hermes can run it on a schedule and deliver the finished report where you already work.
If you want help choosing the first workflow around your business, start with the Claude Code Blueprint.
Five interactive lessons. Install Claude Code, build your first automation, and deploy it live on the internet — all in under an hour. Free, no coding required.
Grab the Blueprint →