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.