This Is How Graph Engineering Actually Works On Hermes
You give Hermes one job, it splits the work across several agents, and one of them checks the rest. Here's how to build it.
Graph engineering means two different things at the moment. One is knowledge graphs, where a model stores facts as connected entities. This article covers the other, where one job gets split across several agents before a separate agent checks what comes back.
Machina ( @EXM7777 ) is the reason the idea is all over my timeline, and he is upfront about where it came from. Engineers told him within hours that he was describing a decades-old pattern wearing a new name, and he agreed. I would rather learn a pattern that has survived twenty years than chase a trick somebody named last Tuesday.
Where you run it decides whether the pattern saves you any time.
The Slowest Way To Run An Agent
The default setup is one agent working down a list. It reads the file, checks the calendar and drafts the summary in the order you wrote them.
When step three stalls on a page that refuses to load, everything behind it waits. A ten-minute brief becomes forty minutes of watching a run you expected the agent to handle.
Nothing is broken. You have simply built a queue, so every job moves at the speed of the slowest one.
What A Graph Actually Is
A graph is that list drawn as a map. It shows the jobs and the genuine dependencies between them.
A job is something you would hand to one assistant, such as researching a competitor or checking a claim. A dependency exists when the next job needs that output. The draft waits for the research because the draft reads the research.
Machina calls his version "the Diamond". The useful idea is simpler than the name. Independent work fans out, then a separate agent tries to break the findings before anything reaches the final answer.
Hermes already has the pieces. Delegation turns one request into several jobs, while shared context carries the findings between them.
one question
>> researcher A
>> researcher B
>> researcher C
>> skeptic checks the findings
>> merged answer
>> you approve
Cut The False Waits
Two steps should only be connected when the second one reads what the first produced.
"Summarise this file and check my calendar" sounds sequential because of the word "and". The calendar check never opens the summary, so both jobs can run at the same time.
Most setups hide a few of these false waits. Draw yours on paper and inspect every "and then". If no work passes between two steps, remove the dependency before you add another agent.
That is usually the cheapest speed improvement available.
Give The Checking To Someone Else
An agent asked to check its own work will usually pass it. The checking needs to sit with an agent that did not produce the original finding.
Give that checker one narrow question. One can verify whether a claim is true, while another checks whether the cited source exists. A vague instruction to "review the report" invites a quick skim and a polite approval.
On Hermes, the researchers are delegated sub-agents and the skeptic is another sub-agent. The skeptic reads their findings first and drops anything it cannot support before the report reaches you.
That structure matters more than the model name. As @codeglitch put it, Hermes Mixture of Agents "is routing plus synthesis, not a secret model that beats everything by default".
Run It Where It Can Keep Running
Most walkthroughs put this pattern inside a coding session. That works when you are coding because you want to inspect each change before it lands.
Scheduled research has a different job to do. Sitting in front of five agents while they read competitor pages defeats the point of splitting the work.
Hermes can wake the graph with cron and deliver the finished report through Telegram or Discord. Since the Quicksilver release, a completed response can survive a gateway crash because delivery is written to a durable ledger rather than held in memory.
Claude Code remains the right home for a coding session. Hermes makes more sense when the work needs to start without you opening a window first.
Know When One Agent Wins
A graph buys breadth. When every step needs the full picture from the step before it, splitting the work makes the answer worse and the bill larger.
Five independent research angles come apart cleanly. A chain of reasoning where each conclusion depends on the last one belongs with a single agent.
The cost compounds quickly. One developer profiling an older Hermes build found that fixed overhead accounted for 73% of each API call. That was one measurement on one setup, but every extra agent still resends context and instructions.
Use cheaper models for broad collection work and keep the expensive model for judgement or the final merge.
Keep The Last Yes
Put your approval where a mistake becomes expensive to undo, usually when something leaves the business or moves money.
Approving every step turns you into the bottleneck. Removing approval entirely lets the first confident mistake reach a customer. The useful gate sits between finished work and an irreversible action.
Hermes provides that gate. Smart approvals put an independent reviewer in front of flagged commands, while a DM approval can hold an outbound message until you answer.
@iacker used that pattern for a kid-facing bot, so a parent read each message before it reached a child. That is the kind of friction worth keeping.
Build A Research Graph First
Research is a good first graph because the work splits cleanly and a weak result costs time rather than a client relationship.
one question
>> independent research angles run together
>> skeptic drops unsupported findings
>> merge the survivors into one report
>> deliver the report to Telegram
>> you decide what happens next
Paste this into Hermes:
I want to set up a research graph. Before you build anything, interview me:
what question am I researching, which angles are worth splitting it into,
what counts as a credible source for this, and where should the result land.
Then build it as delegation: one sub-agent per angle running in parallel,
a separate skeptic sub-agent that tries to disprove every finding and drops
whatever it cannot support, and a merge step that ranks the survivors by
confidence with a source and a date against each one.
Save it as a skill so I can run it again. Do not schedule it yet.
Run it by hand until you can see what the skeptic drops and what the merge keeps. Once the output is reliable, schedule it:
Set this up as a cron job that runs every Monday at 9am and sends the
finished report to my Telegram. Send nothing else without asking me.
Start With The Free Part
Draw your current setup and remove every dependency that carries no work. Then add a separate checking agent before you spend money on a larger swarm.
The schedule comes last. That is when the graph can start working before you sit down.
Get Help Setting This Up
If you want help choosing the first agent graph to build and setting it up around your business, book a free 30-minute AI audit. I will look at how your business runs and identify the highest-ROI automation to build first, then you will leave with a practical plan for setting it up.
