From rigid pipelines to agentic bots: why I replaced n8n with Hermes
For years my automation ran on n8n: deterministic workflows, designed to scale. Every evolution still required an architecture rework. When token costs fell, agents became the better trade-off. Here is why I moved, and how the hybrid runs.
The problem
For years, my personal automation ran on n8n. Deterministic workflows: monitoring, prospection, emails, publication. Clean nodes, templates, an architecture designed to scale.
The design was right. The problem was never scale. It was flexibility.
The wall: rework at every evolution
Every change, a new source, a new format, a new rule, required an architecture rework. Sometimes small, sometimes large. Even when the structure was designed to scale, the day the loop changed, I was the one reconnecting the pieces by hand.
Take monitoring. Add a source: rewire the node. Change the output format: rewire the node. The data flows were correct, but every evolution had a cost in architecture, not in logic. The workflow was doing what I had told it, exactly. It was the telling that did not scale.
A workflow is a printed circuit: reliable, and rigid. The path is drawn once, forever. An agent is different: it carries context, it adapts, it decides within the frame you gave it. The loop can bend without being redrawn.
The economics changed
The second factor was economic. For a long time, autonomous agents were a luxury: expensive tokens, unpredictable costs. The equation changed when token costs fell to the point where the question was no longer "can I afford an agent?" but "where should the intelligence live, local or cloud?"
That is the question this article answers.
The replacement: a hybrid, not a migration
I replaced part of my n8n loops with Hermes. Not a migration from one tool to another: a two-tier architecture.
The rule in one sentence: local for the heavy load, cloud for the agent intelligence, human validation at the boundary.
Local tier · Linux + Ollama (Qwen)
Heavy load: monitoring, crawling, dev tasks. Marginal cost = electricity.
Cloud tier · VPS + DeepSeek
Agent layer: understand, decide, chain steps, keep context.
Human validation at the boundary
Drafts, prospect candidates and monitoring digests are reviewed before anything leaves.
Output · email sent, contact made, article published
Local · Ollama + Qwen
The local tier runs on my own machines (Linux). Ollama with Qwen models handles monitoring and development. This is where the intense, heavy tasks go, the ones that would burn tokens pointlessly in the cloud.
I have the hardware. The marginal cost of a heavy local run is electricity, not tokens.
Cloud · DeepSeek for the agents
The agents run on a VPS, powered by DeepSeek. Not for the heavy tasks, for the agent layer: understanding, deciding, chaining steps. The cloud where the agent needs reactivity and capacity; the local where the load is steady and intense.
The split is not about performance. It is about cost control. DeepSeek gives me agent-grade intelligence at a price that makes the architecture sustainable, and the local tier keeps the token-hungry work off the meter.
The rule that makes it work: autonomy with human validation
The agents are autonomous. They are not unsupervised.
- Emails are produced in draft mode, reviewed before they go out.
- Prospection candidates are collected and validated before any contact.
- Monitoring results are delivered in a chat, not published automatically.
The agent proposes. I dispose. Autonomy inside the frame, human at the boundary. This is the line that makes the system trustworthy enough to run unattended: the agent does the work, I own the decision.
What changed in practice
A change is now an instruction, not a refactor. When a loop needs to evolve, I tell the agent. The architecture stays.
Context survives. The agent knows what it did yesterday. The loop no longer restarts from zero every run.
Failures are discussable. When an output is wrong, we talk about it, it gets corrected, the loop continues. There is no silent error buried in a node.
The system became a product. This is the design ops lesson: a system you evolve is a product. A system you recable is a liability. The same logic applies to design systems, to automation, to anything that must outlive its first version. The architecture is boring on purpose. It does not need to be elegant. It needs to bend.
The pipeline behind this blog: from monitoring to published post
This blog is not written in a vacuum. It is the output of a pipeline, the same kind of system I design for clients, applied to my own content. Here is how an idea travels from monitoring to published post.
Monitoring
I collect signals from sources I trust: design newsletters, product launches, research papers, industry reports, and conversations. The agent does not read everything. It scans, filters, and flags what matches my current interests.
Vault
Flagged items land in a vault: a structured repository of raw signals with tags, sources, and a confidence score. Not everything is good. Not everything is useful. The vault lets me browse before committing.
Ideas
I review the vault periodically and turn signals into ideas. Some become articles. Some become references. Some die. The agent helps me cluster themes and surface patterns I might have missed.
Draft
When an idea is worth pursuing, I write the first draft, usually by hand, sometimes with the agent as a sparring partner. The draft is messy on purpose. It is where thinking happens.
Validation
The agent checks the draft: structure, clarity, consistency, weak arguments. It also proposes improvements. I decide what to keep. This is the human validation layer at the boundary.
Publication
Once validated, the draft is formatted, metadata is added, and the article is published. The agent handles the repetitive parts: front matter, tags, SEO checks, image optimization.
Documentation
After publication, the pipeline documents what happened: what worked, what did not, which sources led to the idea. This closes the loop and improves the next cycle.
Why this matters
This pipeline is not just about writing faster. It is about keeping the loop intact: from signal to decision to output to learning. The same architecture applies to product discovery, to design systems, to client work. It is the Hermes principle applied to content.
Where I am
The migration is not finished. More parts of the ecosystem will join Hermes over time, that is the direction, not an announcement of a final state.
The principle holds: local for the load, cloud for the agent intelligence, human validation at the boundary.