The Godot build finished compiling at 4:42 AM. I saw it at 8:11, when I unlocked my phone to a Telegram message from my Hermes Agent: build complete, stealth shooter playable, loot pickups working, patrol AI on three guards, last commit 04:42:13, no editor errors. I had typed one prompt the night before and gone to bed. That morning changed how I categorize Hermes: it is not a chatbot with extra steps, and if you use it like one you are wasting most of what you paid for. It is a workforce. Here are the six use cases that earn that word in my actual week.
To be clear about the shooter: it is a prototype, not a game. The enemy AI is dumb and the textures are placeholders. But it is playable, and it was built while I slept, which is the point.
Why "workforce" is the right frame
Hermes Agent, from Nous Research, makes three architectural choices that most people ignore because they treat it like a chat window.
It persists. Hermes runs as a long-lived process on a VPS or a machine that stays on. You talk to it from Telegram, Slack, or the terminal, but closing the window does not end the agent. I covered the always-on setup in my Hermes VPS build with Discord notifications.
It self-improves. Successful tasks get extracted into skills, and skills get sharper with use. A research pipeline I set up months ago is measurably better now than the day I built it.
It is multi-instance. You can run several profiles in parallel, an orchestrator, a researcher, a coder, and hand work between them through a literal Kanban board that ships with the product.
Persistence plus learning plus parallelism is an organization, not an assistant. Everything below follows from that.
Use case 1: Slashgoals for long, bounded work
The /goal command is what made me stop treating Hermes like a chatbot. Per the Hermes docs, /goal sets a standing goal and runs the worker in a loop: after each turn a judge model checks the output against the goal's acceptance criteria, and if the work is not done and budget remains, it keeps going. You hand it a target and it grinds.
My first attempt was the mistake everyone makes. I typed /goal build me an app and went to bed feeling clever. I woke up to a half-broken Express server, three contradictory README files, and a token bill I did not enjoy. The agent tried. It just had no idea what I wanted.
The lesson: a slashgoal is not a wish, it is a contract, and contracts work when they are specific. Now I metaprompt every goal first. I sit with Claude and answer: what is the deliverable, described as if handing it to a developer? Hard constraints? What does "done" look like? What may the agent decide alone, and what must it ask me about? What is the budget? The result is a goal prompt two or three pages long. Painful to write, magical to run.
The Godot slashgoal specified the engine (Godot 4), a third-person camera on a CharacterBody3D, two pickups (ammo, bandages), a wall-vision stealth mechanic, patrol AI for three enemies, the exact directory structure, and permission to commit at milestones and ping me on Telegram when blocked. The agent ran 23 hours, hit my iteration cap, and checked in twice, both times over genuine ambiguities in my spec.
The honest tradeoff: a misjudged run is expensive. That 23-hour run cost me roughly $38 in tokens routed through a top-tier model. Worth it for a real prototype, painful when the prompt was bad. Cap max iterations before you delegate anything ambitious. The best slashgoal candidates are bounded, verifiable, and long-tailed: if the task takes fifteen minutes, just do it yourself.
Use case 2: The Kanban board as dispatcher
The Kanban ships as a dashboard plugin. You launch it with hermes dashboard and get a local board with columns from triage through done. Calling it a to-do list undersells it. It is a delegation queue with routing.
My daily flow: around 8:30 AM I write my task list on paper, then split it into two piles. Pile A is work only I can do, calls, judgment, anything that depends on context the agent lacks. Pile B is research, drafting, scaffolding, refactoring, documentation. Pile B becomes cards in the Triage column. The dispatcher reads each card, looks at my profile roster, and routes it: research cards to the researcher profile, code cards to the coder. Big cards get decomposed into child tasks. Cards move across the board without me touching them, the way CI pipelines run.
The detail nobody tells you: the dispatcher routes on profile descriptions, not names. A profile called coder with no description gets generic routing. The same profile described as "TypeScript / Next.js specialist, lives in ~/projects/web" gets exactly the work it should. Writing good profile descriptions is the highest-leverage ten minutes in the whole setup. The second detail: long context belongs in card comments, not titles. The agents read comments.
The first day it clicked, I dropped seven cards at 9 AM. By noon, four were done, two were running, and one was blocked with a question in the comments. I answered in fifteen seconds and it resumed. That is not task management. That is reviewing the work of a team where I am the only human. It is the same delegation shape I use with Claude Code agent teams, with a board instead of a terminal.
Use case 3: Research that hands off to a build agent
Competitive analysis used to cost me an hour per product, often more. Now it is a card: analyze product X, produce a markdown report covering tech stack, features, pricing tiers, analytics, payment processor, positioning claims, and gaps versus two reference tools, output to ~/research/competitors/.
The agent reads every public page, inspects what is visible in the page source and loaded scripts, and writes a 1,500 to 2,500 word report. One run I gave it came back in about 40 minutes with the stack identified from headers and script tags, a feature inventory organized by product surface, a pricing matrix, and, the part that surprised me, a gaps section with three concrete opportunities the product was leaving open.
The reason this use case matters is the handoff. Because the output is clean markdown in a known path, it becomes input to the next agent: read the report, build a prototype that addresses the three gaps, same stack, output to ~/projects/prototype-x. Research then build, both autonomous, both producing artifacts I review. The constraint I hard-code into the researcher profile: public pages only, nothing behind authentication, nothing scraped as a simulated user.
Use case 4: A memory wiki the agent maintains
This is the use case I would fight hardest to keep, and it never shows up in listicles. I run a private wiki, hosted on a subdomain only I can reach, that Hermes maintains for me. Setup was one prompt: build a static site (mine is Astro) with active projects, a daily log, and topic pages, with write access to my notes vault and the conversation log directory.
Every night a scheduled task pulls the day's conversations, extracts decisions and lessons, writes them to topic pages, and cross-links them. By morning the wiki has grown a day of searchable memory without me touching it. The same scheduling pattern works in other stacks too; I wrote about it in loop and cron scheduling for Claude Code.
Two payoffs. First, my own recall: on a client call, they referenced an authentication decision from months earlier that I had completely lost. Six seconds of wiki search brought back the entry, the reasoning, and my own caveat at the time. Second, and this is the part I did not anticipate: the wiki is also the agent's context source. Ask Hermes about last quarter's project and it reads its own notes before answering. It is the agent's long-term memory, externalized in a form I can browse and audit.
Use case 5: Tailscale makes every device a terminal
I run Tailscale, a WireGuard-based mesh VPN, on every device I own: MacBook, a Mac mini that runs long jobs, phone, a spare Linux box. Every device gets a stable hostname reachable only inside my private mesh, and setup is genuinely about twenty minutes.
What that unlocks for a persistent agent is out of proportion to the effort. The Hermes dashboard on the Mac mini is reachable from my phone's browser at the machine's mesh hostname, so I can watch cards move and answer blocked questions from anywhere, the same reason I run Claude Code from my phone. The Ollama endpoint on the Linux box answers at its hostname from any machine, as if it were localhost. Files live where they live; nothing needs syncing.
The safety note that matters: a mesh feels private, and it is, but a compromised device can reach services on every other device. Scope access with Tailscale ACLs and keep authentication on your services anyway. The mesh being private does not make your services safe to run open.
Use case 6: The 9 AM priority prompt
The smallest use case, and the one I would defend hardest. Every morning at 9:00, Hermes asks me one question on Telegram: what is your number one priority today? I answer in a sentence.
Three things happen. The answer lands in the wiki's daily log, which after a few weeks becomes a pattern I cannot see in real time: Mondays trend toward writing, Fridays toward shipping. Second, Hermes drops supporting cards onto the Kanban; the first week I deleted half of them, and by week three I was keeping most, because the agent learned which supporting tasks I actually value. Third, that learning compounds: the smallest possible daily signal produces the largest behavior change over time.
It is a five-minute build: a cron entry inside Hermes, pointed at your Telegram bot, with a small handler skill. Week one it interrupts your coffee. Month three it is the most important habit in your day.
What ties the six together
One primitive, six production functions. The slashgoal is the night-shift worker, the Kanban is the dispatcher, the research engine is the analyst, the wiki is institutional memory, the mesh is the office network, the morning prompt is the standup. I run a similar division of labor across my multi-agent Hermes and OpenClaw setup, and the pattern holds across tools.
The honest downside is maintenance. Hermes ships updates fast, the auto-decomposer is opinionated in ways that occasionally annoy me, slashgoals sometimes burn budget before failing usefully, and the wiki needs pruning when topic pages sprawl. None of that is a dealbreaker. The question is whether the workforce produces more than it costs, and after six months of running it, my answer is an easy yes.
Building this six-function version into someone else's infrastructure — slashgoals, dispatcher, memory wiki, mesh and all — is work I take on. Tell me what you would delegate first and I will tell you honestly whether Hermes is the right tool for it or whether a cron entry would do the same job for free.
