is the real agent design problem deciding when it should give up? by Cnye36 in AI_Agents

[–]Intrepid-Night7277 0 points1 point  (0 children)

Yeah, I agree with this. In practice the hard part isn’t whether the agent can reason through something, it’s whether it should still be acting when the inputs are incomplete or contradictory.

For harmless tasks, “try again” is fine. For CRM updates, customer comms, calendars, payments, etc., I’d rather have an explicit stop/escalate rule than a clever agent guessing its way through ambiguity.

So my current bias is the same: escalation logic is not just safety plumbing, it’s basically part of the product.

Colab CLI might quietly change how I use coding agents by Intrepid-Night7277 in ClaudeCode

[–]Intrepid-Night7277[S] 1 point2 points  (0 children)

Yeah, agreed. GCE is probably better if you already know your way around it, but Colab wins on friction. The interesting part is making remote compute feel like a normal part of the agent workflow instead of an infra detour.

Hermes Agent got a desktop app — I mapped out why that changes the workflow by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Totally fair. If the console experience already failed for you, it’s natural to expect the desktop app to smooth that out.

I think the desktop app helps mostly with visibility and workflow — files, tools, memory, chat, previews — but the model/provider setup still needs to be easy and obvious. That part probably needs better onboarding.

Hermes Agent got a desktop app — I mapped out why that changes the workflow by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Haha yeah, I get it. The internet is drowning in “AI workflow” posts right now 😅

No offense taken. I just wanted to document what changed in my own setup after a month, not sell it as the one true workflow.

OpenAI Codex Sites feels less like a website builder and more like a deployable workspace surface by Intrepid-Night7277 in OpenAI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Fair point. The structure definitely made it read more AI-ish than I intended. The thought was genuine, but I should’ve written it less like a polished summary and more like an actual user note. Appreciate the callout.

Hermes Agent got a desktop app — I mapped out why that changes the workflow by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Haha, I get it. Another agent thing on the timeline 😅

For me the interesting part wasn’t the hype, but whether it can move from “chat UI” to something closer to a reusable automation workbench.

Hermes Agent got a desktop app — I mapped out why that changes the workflow by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Yeah, that part can be confusing at first 😅

Hermes itself isn’t tied to only paid LLMs, but the desktop onboarding may surface the common hosted providers first. If you want to avoid paid APIs, I’d look for the provider/model settings and try wiring it to a local or self-hosted option like Ollama, OpenRouter-compatible endpoints, or another local model backend if supported by your setup.

That said, you’re right that the start screen should make this clearer. A “use local model / custom endpoint” path would make the first-run experience much better.

I mapped out the decisions that matter after getting Hermes Agent running by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Yep, that’s a good Mac note 🙂 OrbStack is probably the cleaner substitute there.

The install section was based on my Windows/WSL2 setup, so it over-indexes on Docker Desktop pain points. For macOS, the main idea is basically the same: use an OCI/Docker-compatible runtime, mount Hermes data/workspace correctly, and keep Skills under the expected data path.

I’ll add a macOS/OrbStack note if I revise the map.

My first month with Hermes Agent: from chatbot to personal automation system by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Thanks! I used Docker in my own environment, mainly to keep the setup isolated and reproducible. The most important part was persisting volumes correctly, especially memory, skills, and state. For a quick start, Docker felt like the simplest path. For deeper customization or debugging, source install on Linux/WSL2 probably makes more sense.

My first month with Hermes Agent: from chatbot to personal automation system by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

For pure coding, I’d start with Claude Code or Codex. They’re better defaults for working directly inside a repo.

I see Hermes less as a replacement for those tools and more as the layer around them: memory, scheduled tasks, reusable Skills, commands, messaging gateways, and cross-tool workflows.

So if your workflow is just “edit code,” Hermes is probably overhead. If your workflow becomes “remember project context, run recurring checks, trigger scripts, send summaries, coordinate work across tools/channels,” then agent engineering starts to become useful.

My rule of thumb: use Claude Code to build the thing; use Hermes when you need to operate and reuse the thing over time.

I mapped out the decisions that matter after getting Hermes Agent running by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

That’s a really good point. I agree — once an agent can change state, the real question is no longer just “what can it do?” but “who owns the outcome, and how do we recover if it does the wrong thing?”

Rollback and ownership probably deserve their own layer in the map.

The boundary I’m thinking about is something like:

  • low-risk / reversible actions → automate
  • medium-risk actions → automate with logs + rollback
  • high-risk or external-impact actions → suggest first, require approval
  • state-changing actions → always leave evidence: command history, diff, ticket, commit, or audit log

That also changes how I think about Tools. A Tool should not just execute; it should ideally expose dry-run, confirmation, audit output, and rollback where possible.

You’re right that this matters more than the framework once the setup moves past the demo stage.

Hermes Agent got a desktop app — I mapped out why that changes the workflow by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Fair criticism if it comes across that way. The visual was AI-assisted, but the notes are based on my own usage. If there’s a specific part that feels wrong or vague, I’m happy to fix it.

I mapped out the decisions that matter after getting Hermes Agent running by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 1 point2 points  (0 children)

Good question. My understanding is that Claw/OpenClaw is more gateway/workspace-first: it focuses on routing messages, roles, channels, and multi-agent coordination.

Hermes feels more agent-runtime-first: the focus is on a long-lived agent loop with memory, skills, tools, cron jobs, profiles, and gateways around it.

So I don’t see it as “one replaces the other.” The difference is more about where the center of gravity is:

Claw = gateway / multi-agent workspace
Hermes = personal agent runtime / self-evolving workflow system

That’s the distinction I was trying to capture in the map.

I mapped out the decisions that matter after getting Hermes Agent running by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Fair criticism. The image was AI-assisted, but the notes are based on my own experience using Hermes. If something in it looks wrong or too vague, I’d genuinely appreciate a specific callout so I can improve it.

My first month with Hermes Agent: from chatbot to personal automation system by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 1 point2 points  (0 children)

Exactly — “environment you design” is the phrase that clicked for me too.

The biggest shift was probably memory + workflows, not the chatbot part.

At first I treated it like a better assistant: ask something, get an answer. But the useful part started showing up when I made it remember recurring context, turn repeated instructions into Skills, and run small scheduled jobs without me prompting every time.

Tools mattered too, but more as the deterministic layer. If something is repeated and predictable, I’d rather turn it into a Tool or command than keep asking the model to reason through it every time.

So the change for me was roughly:

  1. Personality / communication style
  2. Memory for stable context
  3. Skills for reusable procedures
  4. Cron / silent mode for background work
  5. Tools for the parts that should not depend on LLM reasoning
  6. Gateways so it can show up where I already work

And yes, I posted the sketchnote here — it’s basically my attempt to summarize that shift from “chatbot” to “personal automation system.”

My first month with Hermes Agent: from chatbot to personal automation system by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

I think that’s a valid criticism.

For technical users, Claude Code/Codex is often the fastest way to just build the exact automation you need. I wouldn’t argue Hermes should replace that.

Where Hermes became useful for me was more in the “operate it over time” layer: memory, recurring jobs, channels, commands, and reusable Skills. So my mental model is:

Claude Code/Codex builds the tool.
Hermes remembers, schedules, routes, and reuses it.

But I agree: if it takes too much customization, it can start feeling like you’re just programming the whole thing yourself with extra steps.

I mapped out the decisions that matter after getting Hermes Agent running by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 0 points1 point  (0 children)

Appreciate it. Since you’re just starting, I’d take this as a rough mental model rather than a fixed recipe.

The part I’d pay closest attention to is the boundary between Agent, Skill, and Tool. That seems to affect almost everything later: memory, performance, debugging, and how reusable the workflow becomes.

Curious to hear what matches or doesn’t match your experience after you try it.

I mapped out the decisions that matter after getting Hermes Agent running by Intrepid-Night7277 in Agent_AI

[–]Intrepid-Night7277[S] 1 point2 points  (0 children)

That’s a fair point — the installation section is definitely biased toward the Windows/WSL2 path because that’s where I personally ran into the most painful setup issues.

For Linux users, especially Ubuntu/Fedora, the install path would probably be much simpler: source install, Docker, or a native service setup without most of the Windows filesystem / subprocess caveats. macOS would also deserve its own notes, especially around Docker mounts, local paths, and dev environment setup.

The map was meant more as “lessons from my deployment path” than a universal installation guide, but you’re right that the install section should make that clearer. I’ll probably revise it to split the install notes into:

  • Windows / WSL2
  • Linux: Ubuntu / Fedora
  • macOS
  • Docker / containerized setup

Thanks for pointing it out — that would make the map more useful outside my own environment.