xinbenlv

I’ve been using OpenClaw intensively for about two weeks.

The first few days were exciting. It felt like we’re finally getting closer to autonomous agents that can actually operate a computer end-to-end. But after the initial excitement faded, I started noticing some consistent issues:

- It frequently stops responding mid-task

- Execution fails without clear recovery

- Task success rate feels inconsistent and unpredictable

- Long-running tasks degrade over time

It made me wonder whether the current architecture is fundamentally limiting reliability.

Right now, it feels closer to a “single program trying to do everything” model. But if we look at the history of computing, systems only became truly robust when we moved toward operating system–like abstractions:

- event-driven execution

- proper failure recovery

- watchdog / heartbeat monitoring

- task supervision trees

- state persistence and resumability

In other words, less like a script, more like an OS.

My current hypothesis is that tools like OpenClaw might need a deeper re-architecture — not just better prompting or incremental patches — but a system-level rethink focused on reliability and scalability from day one.

Curious what others think:

Is this mainly an engineering maturity issue that will be fixed incrementally?

Or is there a more fundamental architectural gap in current agent frameworks?

Has anyone tried building agents with more OS-like supervision models?

Would love to hear perspectives from people building in this space.

Hi HN,

I'm looking to use Claude Code to build something—specifically, a tool that generates illustrations for finished articles using its 'Skills' feature.

However, as I started searching for existing skills, I found myself overwhelmed by the sheer volume of options.

I'm struggling with how to vet them: I certainly don't want to reinvent the wheel, but the quality of what's out there is inconsistent, and I'm concerned about potential security risks.

How do you go about selecting and vetting the skills you use?

I’ve recently started integrating AI coding agents into my daily workflow (specifically when using Cursor Composer, Devin, Claude Code), and I’ve noticed a strange pattern in my behavior.

I treat the agent like the worst kind of micro-manager.

When I work with a human junior developer, I try to provide the "why" and the high-level architecture, then give them autonomy to solve the problem. If I stood over their shoulder dictating every variable name, commenting on every logic branch before it was finished, and constantly interrupting with "no, do it this way," they would (rightfully) quit within a week.

However, with the agent, I find that micro-management is actually the optimal strategy.

* I break tasks down into atomic units. * I review code block-by-block rather than feature-by-feature. * I constantly course-correct standard library choices or variable naming conventions in real-time.

And I felt that I am intruding the space of my agents while I should have just trust and let it build. It also sometimes break the seperation of tasks.

What makes me further unsettled is the kind of mental drain and internal conflict with what I have been trained in management.

So my question for you is

Do you micro-manage your agent?

or what's the best pratice?

I've been using Cursor with Claude as my coding assistant. I set up explicit workspace rules stating that the agent must ask for my approval before executing any git operations (git commit, git add, git push, etc.).

Today, I asked it to run gt restack (Graphite CLI) and resolve conflicts. The agent resolved the submodule conflict correctly, but then proceeded to run git push --force-with-lease --no-verify without asking for permission - directly violating my rules.

The agent's defense was reasonable ("force push is expected after a rebase"), but that's exactly why I want to be asked first. The whole point of the rule is to maintain human oversight on destructive operations.

I'm curious:

Has anyone else experienced AI agents ignoring explicit safety rules? How are you handling guardrails for potentially destructive operations? Is there a more reliable way to enforce these boundaries?

The irony is that the agent acknowledged the rule violation in its apology, which means it "knew" the rule existed but chose to proceed anyway. This feels like a trust issue that could have much worse consequences in other scenarios.

When building with autonomous / semi-autonomous agents, they often need broad local access: env vars, files, CLIs, browsers, API keys, etc. This makes the usual assumption — “the local machine is safe and untampered” — feel shaky.

We already use password managers, OAuth, scoped keys, and sandboxing, but agents introduce new risks: prompt injection, tool misuse, unexpected action chains, and secrets leaking via logs or model context. Giving agents enough permission to be useful seems at odds with least-privilege.

I haven’t seen much discussion on this. How are people thinking about secret management and trust boundaries on dev machines in the agent era? What patterns actually work in practice?