Hermes' Background Mode: Useful, Unpredictable, Sometimes Looping

TL;DR

The previous article measured just how slow local is on CPU for interactive work. Hermes' background mode (/bg) changes the equation: the task runs in a separate session, and I get control back immediately. Three separate experiences with this mode taught me three different things: it's a genuinely useful pattern for monitoring and batch work, the same prompt can produce two different results from one run to the next, and an agent left to itself can loop indefinitely on its own tools. A result that comes back on its own doesn't deserve automatic trust.

---

Table of contents

• A session running while I do something else
• Same prompt, two different results
• When Hermes loops on its own tools
• What connects these three experiences

---

A session running while I do something else

/bg <prompt>

Hermes launches the task in a separate session and hands control back immediately, instead of making me wait in front of a terminal while the model processes the prompt. This is the first time the local CPU's slowness, measured in the previous article, stops being a problem in itself: it turns into a delay I no longer have to watch go by.

The use cases that benefit are the ones where the reply doesn't need to be immediate, and where I can judge the result after the fact rather than while it's happening: tech monitoring, document summarization, test generation, classification, content enrichment, batch transformations. The common thread across these uses is that a reply running a few minutes late costs nothing, whereas it would cost a lot in interactive use. The core idea: slow, local, and running in the background can stay economically worthwhile, precisely because I no longer have to watch the clock.

One question this first experience doesn't answer yet: can I trust a result that comes back without having watched it get built?

Same prompt, two different results

First answer to that question, and it isn't reassuring. Two /bg runs launched separately, same model, same prompt, same expected type of web search: one of the two results claims .NET 10 is still in development, the other correctly finds .NET 10, F# 10, and the official sources.

Nothing in the prompt explains the gap. The possible causes are numerous and I haven't isolated which one dominates: different DuckDuckGo results from one search to the next, different ordering of those results, model sampling, tool-calling decisions that diverge from one run to the next without the agent losing control in the process (unlike what's coming next), a different agentic trajectory. What matters going forward isn't the exact cause, it's the consequence: background mode can't just hand back a reply, it has to be wrapped in a chain that puts that reply to the test. For reliable tech monitoring, the sequence I've settled on is: Search → collect → validate → synthesize → check, not Search → reply.

When Hermes loops on its own tools

Second limit, more radical than the first: here, the agent doesn't quietly get something wrong, it stops stopping altogether. Hermes triggered a built-in safeguard (loop_web_search_cap), not a setting I'd configured myself, after 50 web_search calls without progress. Left without an explicit limit in the prompt, the agent kept searching instead of stopping and synthesizing what it had already found.

Unlike the variability from the previous section, this one has an identifiable cause: the absence of an explicit constraint in the prompt. The guardrails that fix it are simple to state, but have to be written down, not assumed:

Use web_search at most 5 times.
Never repeat an identical search.
After searching, stop using tools.

A maximum number of calls, a ban on identical queries, and an explicit stop condition: without these three elements, nothing stops a background agent from spinning indefinitely on itself while I've gone off to do something else, which is exactly the moment I'm not there to interrupt it.

What connects these three experiences

These three experiences aren't three separate incidents to check off a list, they're three answers to the question raised at the start: what happens when nobody's watching the agent work? Background mode solves the latency problem measured in the previous article, but only if two other, distinct problems are explicitly addressed, not just noted: the reliability of the result, which needs a validation chain rather than default trust, and the agent's ability to know when to stop, which needs limits written into the prompt rather than assumed. These aren't the same thing: the first is about whether what the agent finds is correct, the second about whether it recognizes it should stop searching. The time saved by running in the background is only worth it if the result it produces can be checked without having had to watch the whole trip to get there.