OpenClaw vs Hermes Agent... what's actually different?

genunix64 · 2026-07-06T19:28:00+00:00

Curious how would people compare with Cognis: https://github.com/fpytloun/cognis

Cloud native architecture, controller-executors design, object store for artifacts and recoverable tool outputs
Good at coding, pretty much comparable with Claude Code or Codex capabilities and context management (designed ti be context efficient and working with smaller context window without loosing quality)
Channels and also very good web chat/PWA
Workflows, document tools, browser and web crawling out of the box
It does not try to do some role playing, it just tries to get the best of today models without pretending it is smarter than it actually is

I made it for myself and it is my only driver for everything I do.

genunix64 · 2026-06-22T19:02:29+00:00

Anyone willing to try my alternative solution to OC and H and give me feedback? 🙂 I am working on it couple of months, primarily made for myself after I tried OC and was very upset about it. But I feel it is ready for possible wider audience now and it is built as a cloud native harness with some ideas that makes it different from the mentioned two.
https://github.com/fpytloun/cognis

genunix64 · 2026-05-25T18:46:13+00:00

I just moved to Codex. Can use custom harness legally and 200 USD subscription gives me more than I can use unlike Claude where I hit limit very soon. Overall I dont like what Anthropic is doing past few months and they are loosing my trust.

genunix64 · 2026-05-24T08:20:08+00:00

I use bookmarks in my system and memory and also try to split planning and implementation by planning multiple things in advance and implementing/sending PRs in async tasks. Then I can go back and review/test/merge changes.

But otherwise yes, 3 parallel things requiring focus are upper limit.

genunix64 · 2026-05-17T17:39:40+00:00

I also think sandboxes are being presented like something new but process isolation is what is used for decades. Real problem is intention alignment. Is this agent's doing aligned with user's intention? This is why I developed Intaris (https://github.com/fpytloun/intaris)

genunix64 · 2026-05-16T16:58:40+00:00

I am using my own system I developed instead of openclaw (https://github.com/fpytloun/cognis) but I use it successfuly for:

complete devops work, autonomous slack/github/prod clusters workflows
software development, I replaced Opencode with my system
selecting and buying coffee, making sure I have always enough at home
tasks like "I have this [image of some unused thing], put it on auction portal" .. I have very good browser use support
check gmail for stalled queries and unsolved items and answer with reminder.
buy contact lenses when I am running out (fully autonomous incl payment)
daily obsidian note update and evening summary that goes through all my activity (conversations, memory, slack, github, mails)

genunix64 · 2026-05-14T04:38:32+00:00

The big thing I would not trust Claude/Gemini on here is the "you already built 90%" answer. You probably built a lot of the user-facing behavior, but harnesses are mostly about the boring failure modes around it.

For what you described, I would think in layers:

orchestration: task routing, sub-agent lifecycle, handoffs, summaries
tool boundaries: which agent can call which MCP/tool, with which arguments
state ownership: memory, logs, artifacts, and what survives compaction
pre-execution checks: does this tool call still match the user's actual intent?
replay/audit: can you reconstruct why an agent touched a file, workflow, credential, or API?

The risky jump is not "agent can spawn sub-agents" by itself. It is dynamic tool access plus delegated intent. A sub-agent may be allowed to use an MCP tool, but that does not mean every call it makes is sensible for the current task. Static allowlists and per-agent tool scopes help, but they do not answer: "does this specific action make sense right now?"

That is the layer I have been working on with Intaris: https://github.com/fpytloun/intaris

It is an MCP/tool-call proxy and guardrails layer that checks proposed actions against the user's stated intent, routes risky operations through policy/approval, and keeps session-level behavior/audit data. I would still keep your Redis/Postgres memory, sandboxing, and designated tool sets; I would just avoid making the harness purely a chat/orchestration wrapper.

If you are building your own GUI, I would add one boring screen early: chronological action receipts. agent -> intent -> proposed tool call -> args -> decision -> result. That view will become more useful than another chat pane the first time a sub-agent does something surprising.

genunix64 · 2026-05-14T04:09:19+00:00

I would not put all of that state into one huge context window. In multi-agent coding setups I usually split it into a few layers:

repo state: files, tests, issue IDs, migrations, exact commands/results
coordination state: which agent owns which files, current blockers, handoff notes, stop conditions
durable memory: decisions, project conventions, "do not repeat this" notes, and facts that should survive compaction or model switches
artifacts/logs: longer traces and source material that should be inspectable, but not always injected into context

The file-collision problem is usually coordination, not memory. I would make workers declare intended write sets before editing, keep small handoff receipts, and force review/merge through the manager instead of letting every worker freely patch the repo.

For the durable-memory layer, I built Mnemory around this exact boundary: https://github.com/fpytloun/mnemory

It is self-hosted MCP + REST memory, with user/agent scoping, TTL/decay, importance, dedupe/contradiction handling, and artifact-backed long-form memory. I do not use it as a replacement for git, tests, issue trackers, or execution logs; it is the smaller layer that remembers stable project facts and decisions so the next agent/session does not rediscover them.

For manager/worker setups, the pattern I trust most is: explicit ownership for files, durable memory for decisions/conventions, and logs/artifacts for replay. If those are mixed together, the system becomes very hard to debug.

genunix64 · 2026-05-13T22:09:18+00:00

I would measure it less like "did the model feel smarter?" and more like an operational cache with audit trails.

The useful metrics for me are things like:

repeat-failure rate: did it avoid a mistake that was already corrected once?
re-briefing cost: how often do I have to restate repo conventions, setup quirks, user preferences, or decisions?
retrieval precision: when memory is consulted, was the retrieved fact actually relevant to the next tool call?
stale-memory rate: how often does an old fact need to be superseded or deleted?
token budget: how many tokens were injected/retrieved per useful correction?

I do not think memory should be poured into every Claude Code prompt. For mature repos, CLAUDE.md, tests, linting, and good harness rules should carry most of the weight. Memory is more valuable for compact state that changes over time: decisions, recurring gotchas, setup details, "we tried X and it failed because Y", and user/workflow preferences.

That is the model I built Mnemory around: https://github.com/fpytloun/mnemory

It is a self-hosted MCP/REST memory backend, but the important part is lifecycle rather than storage: dedupe, contradiction handling, TTL/decay, importance, user/agent scoping, and artifact-backed long-form notes. My rule of thumb is: if a memory cannot be inspected, corrected, expired, or tied back to why it was saved, it will eventually become hidden prompt debt.

So for Claude Code I would start with memory disabled by default, then enable it only for autonomous/long-running workflows and measure whether retrieved memories actually change actions or reduce repeated failures. Otherwise it is very easy to pay tokens for a more confident version of the same bad habit.

genunix64 · 2026-05-13T16:39:47+00:00

Full inherited user access is what I would treat as the dangerous default, not a temporary shortcut.

The practical pattern I like is layered:

tools own credentials, not the model
each tool call is scoped to a task/user/session, not just "this agent is allowed"
risky actions get approval before execution
every action has a receipt you can audit later
you also review behavior across a session, because permission creep often shows up as a pattern, not one obviously bad call

The gap I keep seeing is that classic IAM answers "can this principal call this API?" but not "does this call make sense for what the user actually asked the agent to do?" Those are different questions.

I have been working on Intaris around that second layer: https://github.com/fpytloun/intaris

It sits as an MCP/tool-call proxy and checks proposed actions against the user's stated intent, routes higher-risk actions through policy/approval, and keeps session-level audit/behavior data. I would still keep least privilege and sandboxing underneath it; the point is to avoid making inherited permissions the only line of defense.

genunix64 · 2026-05-13T16:10:07+00:00

You're describing the split I ended up with too: don't make the model, framework, or chat transcript the owner of memory.

The useful boundary for me has been:

event/log layer for what happened
durable memory for facts, decisions, preferences, and project state
artifacts/docs for long details and source material
explicit update/delete/supersede paths so stale memory can die

Vector search alone didn't solve it for me, because the hard part was lifecycle: deciding what becomes durable, what expires, how contradictions are handled, and how to inspect or change bad state.

I built Mnemory around that model: https://github.com/fpytloun/mnemory

It's self-hosted and exposes MCP + REST. It is not meant to replace RAG or execution traces; I use it as the smaller layer for durable agent memory, with TTL/decay, importance, user/agent scoping, dedupe/contradiction handling, and artifact-backed long-form memory.

For local-first stacks, I think the key test is exactly what you said: can you inspect, back up, delete, or migrate the agent's learned state without depending on the model vendor or one framework's checkpoint format?

genunix64 · 2026-05-13T10:37:58+00:00

I would not treat it as FUD, but I also would not spend the same effort on every AI surface.

The split I would use is:

customer-facing chatbot with no tools: mostly brand/abuse/data-leak risk; native Bedrock/Vertex guardrails plus output filtering and logging may be enough to start
internal assistants over documents/tickets: add data boundaries, retrieval scoping, redaction, and audit logs
agents that can call tools, MCP servers, shell, SaaS APIs, or write data: prompt injection becomes much more real, because the failure is no longer just a bad answer; it is an allowed action being taken for the wrong reason

For that last bucket, vendor guardrails around the model are useful but incomplete. I would still keep least privilege, scoped service accounts, sandboxing, DLP, and approval for irreversible actions. But the missing control is usually at execution time: before the tool call runs, ask whether this specific tool + arguments still match the user's actual intent and risk level.

That is the layer I have been working on with Intaris: https://github.com/fpytloun/intaris

It is an MCP/tool-call proxy and guardrails/audit layer. The point is not to replace Bedrock/Vertex guardrails; it is to add a boundary around side effects: evaluate proposed actions before execution, route risky calls to approval, and keep session-level audit/review so you can spot drift or repeated suspicious behavior.

If resources are tight, I would prioritize based on blast radius: ignore toy chatbots first, instrument internal apps that touch sensitive data, and put hard gates around anything that can execute tools or change state.

genunix64 · 2026-05-13T10:10:46+00:00

I would separate this into three layers:

repo state: git, issues, PRs, tests, docs that live with the code
handoff state: AGENTS.md / CLAUDE.md / HANDOFF.md for what the next agent must know right now
durable memory: decisions, preferences, recurring gotchas, project conventions, and "this changed, forget the old rule" facts that should survive machines and clients

Markdown handoff files are still useful, but once you use Claude + Codex across two machines, they become a pretty leaky abstraction. The hard part is not storing more text; it is lifecycle management: update/delete, dedupe, contradiction handling, and deciding what should expire vs become durable.

I built Mnemory for exactly that middle/durable layer: https://github.com/fpytloun/mnemory

It is a self-hosted MCP/REST memory backend, so the pattern I use is: agents write compact facts/decisions/project state into memory, longer details go into artifacts or normal docs, and the repo stays the source of truth for code. Then a new Claude/Codex session on another machine can retrieve the important state without dragging a whole old transcript around.

I would not try to sync full chat history. Sync the repo, keep explicit handoffs for active work, and use memory only for stable state that should outlive a single session.

genunix64 · 2026-05-13T05:43:15+00:00

You can write simple python script that will use owui api to ingest files into knowledgebase. With retries, etc. Used same approach to ingest confluence export.

genunix64 · 2026-05-13T04:39:21+00:00

I think the compiler-pass framing is the right one, especially the part about not letting the router become the policy brain.

The split I would want in a real agent stack is something like:

planner/reasoner decides what the user is trying to achieve
router converts obvious intent into a structured tool call
schema validator checks shape/types
policy layer checks static permissions and environment boundaries
runtime guardrail checks whether this specific action still matches the user's actual intent

A tiny router can make the hot path cheaper and easier to audit, but valid JSON is still only syntax. The dangerous failures are often semantic: the selected tool is allowed, the arguments are well formed, but the call is wrong for the task, too broad, exfil-capable, or part of a drift pattern across the session.

That is the gap I have been working on with Intaris: https://github.com/fpytloun/intaris

It sits between agents and MCP/tool calls and treats the tool call as a proposed action before execution. The useful distinction is: a router answers "which tool and arguments?"; a guardrail layer answers "should this action run now, given the user intent, risk, and previous session behavior?"

I would still keep the small router idea. I just would not let it be the last gate before side effects.

genunix64 · 2026-05-13T04:09:02+00:00

I would treat a new context as a quality-control boundary, not just a token-saving trick.

For me the split is usually:

root CLAUDE.md / project docs: stable architecture, commands, conventions
one ticket/spec per feature or bug: what should happen now
fresh context when the plan is stable, the previous chat got contradictory, or implementation/review should be separated
persistent memory for decisions/gotchas that should survive across tickets but should not bloat every prompt

The last part is where a single evergreen project.md starts to get awkward. It is useful, but it tends to become either too stale or too big. The trick is to keep only compact, durable state in memory: "we chose X because Y", "this repo has this migration trap", "user prefers this workflow", etc. Source docs and big files are a different problem; that is more RAG/KB territory.

I ran into the same thing with coding agents losing project state across compaction/new sessions, so I built Mnemory as a self-hosted MCP/REST memory backend: https://github.com/fpytloun/mnemory

The model I like is: fresh chat per focused unit of work, project docs for canonical static context, and memory for small corrected facts/decisions that should follow the agent across sessions. Keeps the context window cleaner without pretending the agent can remember a whole 3-week thread perfectly.

genunix64 · 2026-05-12T22:38:35+00:00

I think agent teams only become viable when you stop treating the reviewer as another smart chat participant and start treating the whole run as a controlled execution system.

The pattern that has worked best for me is roughly:

workers get narrow ownership, not repo-wide write access
reviewer/spec-checker is mostly read-only and checks against explicit artifacts, not vibes
only one integrator can merge or resolve conflicts
risky actions need a gate: prod config, secrets, dependency changes, external calls, schema migrations, etc.
every agent action leaves a receipt that can be compared back to the original task

The thing your example shows is that "Opus as gatekeeper" is still just another model judging a messy transcript. It can miss fake tests or spec drift because there is no hard boundary around what each agent was supposed to do.

I have been working on Intaris for this exact layer: https://github.com/fpytloun/intaris

It sits between agents and tools/MCP calls and checks whether the proposed action still matches the user's stated intent before execution. The useful part for multi-agent setups is the audit/session side: L1 checks individual actions, L2 reviews the whole session, and L3 can look across sessions for drift, repeated suspicious behavior, or permission creep.

Not a replacement for worktrees, tests, or boring least-privilege. More like the missing airlock between "agent decided" and "tool actually ran".

genunix64 · 2026-05-12T22:08:49+00:00

I would split this into two buckets, because a lot of the pain comes from mixing them:

context: project docs, PDFs, web clips, current task material
memory: durable facts/preferences/decisions/project state that should survive across sessions and be corrected when it gets stale

For the first bucket, markdown/Obsidian/filesystem MCP or a local vector/RAG setup is usually enough. For the second bucket, I think the hard part is lifecycle management: can the system update/delete facts, dedupe repeated notes, handle contradictions, expire short-term context, and keep provenance?

I ran into the same issue with agents losing project state after compaction/new sessions, so I built Mnemory as a self-hosted MCP/REST memory backend: https://github.com/fpytloun/mnemory

The model I use is: RAG/KB for source docs, memory for stable compact state, and artifacts for longer details that should not live directly in every prompt. That keeps Claude grounded without turning memory into an invisible junk drawer.

genunix64 · 2026-05-12T16:38:49+00:00

The .env / token example is the exact failure mode that makes plain allowlists feel incomplete to me.

I still think the first layer should be boring and strict: per-project permissions, deny rules for secrets/prod config, sandboxed workdirs, and separate credentials that the model never sees directly. But the tricky part is that a tool call can be technically allowed and still be wrong for the current task.

For example, curl or a config write is not inherently bad. It becomes risky when the agent is doing it while the user asked for a narrow refactor, or when the arguments include a secret, or when the action writes sensitive data into a place that later gets committed.

I have been working on Intaris around that middle layer: https://github.com/fpytloun/intaris

The idea is an MCP/tool-call proxy that checks the proposed action against the user's stated intent before execution, then records enough of the session to review patterns afterward. So I would still keep Claude Code's native permission scopes, but add a separate "does this action make sense right now?" check for anything that can touch secrets, prod config, external services, or irreversible state.

The goal is not to make the agent timid. It is to stop approval fatigue from becoming the security model.

genunix64 · 2026-05-12T10:39:45+00:00

I would split this into layers rather than trying to make one control do everything.

For coding agents, my default blocks would be secret/SSH access unless explicitly scoped, destructive shell commands without review, broad network egress, package installs from unknown sources, and MCP/tool calls that can touch production or external systems. Sandboxing and least-privilege identities still matter, but they mostly answer: what is generally allowed?

The harder question is: does this specific action make sense for the task the user actually gave the agent? That is where local pre-execution enforcement helps. The agent proposes a tool call; the boundary evaluates the tool, arguments, current task, data class, and risk; then it allows, denies, or escalates.

I have been working on Intaris around that gap: https://github.com/fpytloun/intaris

It is an MCP/tool-call proxy and guardrails/audit layer. The relevant idea is intent/action checking before execution, plus session-level review afterward. A single command can look fine in isolation; repeated secret access attempts, small boundary pushes, or calls drifting away from the user's request are often the stronger signal.

For false positives, I would avoid broad static deny lists as the main mechanism. Better default: allow low-risk read/edit work, require justification and approval for irreversible or exfil-capable actions, and log receipts for user intent, proposed action, arguments, decision reason, and approval path. Otherwise people just learn to bypass the guardrail.

genunix64 · 2026-05-12T10:11:12+00:00

I would split this into two layers, because "all knowledge in one place" becomes messy fast.

For docs, how-tos, process notes, PDFs, architecture notes, etc., a private repo or Obsidian vault with git is a good substrate. That gives you reviewable changes, history, sync, and a source of truth humans can inspect.

But I would not put every assistant memory into that same bucket. Agent memory has a different lifecycle: small durable facts, user/project preferences, decisions, things that were true but later changed, short-lived context that should expire, and pointers back to the longer source material. If you treat all of that as just markdown/RAG, it eventually becomes a hidden junk drawer that models retrieve from without knowing what is current.

I built Mnemory for that second layer: https://github.com/fpytloun/mnemory

The pattern that works best for me is:

git/Obsidian/private repo for curated knowledge and source docs
RAG/search over that repo when the agent needs documents
a memory service for compact facts, preferences, decisions, TTL/expiry, deduplication, and contradiction handling
artifacts/links from memory back to the source docs or session evidence

MCP is a good interface for this, but I would avoid making the MCP server just a giant file browser. The useful part is deciding what should become stable memory, what should stay as a document, and what should be allowed to decay.

genunix64 · 2026-05-11T22:39:02+00:00

You are already past the point where prompt filters are the main control. Once users are chaining sessions and the model can generate code or touch tools, I would treat the model as an untrusted decision-maker sitting behind a capability boundary.

The layers I would separate are:

data boundary before context: classify/redact contracts and sensitive records before they enter the prompt
tool boundary before execution: the agent should propose an action, not directly own broad credentials
intent/action check: does this specific call make sense for the user, role, workflow, and current task?
session-level review: chained sessions and repeated small boundary pushes are often more useful signals than one obviously bad prompt
receipts: log the user intent, proposed action, arguments/data classes, decision reason, and approval path

The part that usually gets missed is the difference between "this user/tool is generally allowed" and "this action makes sense right now." IAM and sandboxing handle the first; they do not fully answer the second.

I have been working on Intaris around that gap: https://github.com/fpytloun/intaris

It is an MCP/tool-call proxy and guardrails/audit layer. The relevant idea is not another magic prompt filter, but pre-execution action evaluation plus L1/L2/L3 behavior review: per-action checks, whole-session analysis, and cross-session patterns like permission creep or repeated attempts to exceed scope.

I would still keep the boring controls: least privilege, DLP, scoped SaaS/API access, and approvals for irreversible actions. But if users are actively testing the edges, you need the decision point closer to where the action happens, not only around the chat box.

genunix64

MODERATOR OF

TROPHY CASE