Notes on Using OpenClaw

OpenClaw is an open-source AI agent automation framework. Its core goal is to take AI beyond mere "conversation" and let it plan tasks, call tools, execute operations, and keep iterating until a complex goal is done. After using it for a while, here is what I've gathered.

The reason for writing this is simple: after using chat-style AI long enough, you realize its ceiling isn't "how well it answers" but "what happens after the answer." It suggests the code, lists the commands—but actually running, verifying, and fixing things is still on you. Agent frameworks exist to close that last mile: turning "saying" into "doing." OpenClaw is one I've actually run for a stretch recently, so I'm writing down my observations and issues—partly for my own reference, partly for anyone evaluating options.

In short, you can think of OpenClaw as:

An AI engineering assistant that can write code, run commands, analyze projects, and iterate on tasks automatically.

Unlike plain ChatGPT or Claude, OpenClaw is designed to:

• Give AI the ability to execute tasks
• Break down complex goals
• Automatically call tools and run commands
• Keep iterating until the task is done

That makes it something closer to an AI software engineer.

OpenClaw — Personal AI Assistant

OpenClaw's Core Capabilities

OpenClaw's capabilities boil down to three things: task planning + autonomous execution + tool calling.

These map directly onto the classic agent loop: the model produces a plan from the goal (planning), acts on the real environment through tools (execution), then feeds the results—command output, error messages, test results—back to itself as observations (feedback) and adjusts its next move accordingly. The loop repeats until the model decides the task is complete. Once you understand this plan–execute–observe loop, OpenClaw's behavior becomes fairly predictable.

1) Task Planning

When you give OpenClaw a goal, for example:

"Add a Redis cache to this project"

OpenClaw automatically breaks the task down, for example:

1. Analyze the project structure
2. Locate the database access code
3. Design a caching strategy
4. Modify the code
5. Add tests
6. Run verification

The process is essentially an AI generating a development plan on its own.

Worth emphasizing: the plan isn't generated once and then executed blindly to the end. After each step, the model re-examines the remaining steps—say it analyzes the project structure and discovers it uses MyBatis rather than JPA, then the subsequent changes adapt accordingly. The plan is alive, and that is the essential difference between an agent and "asking the model to output a script in one shot."

2) Autonomous Task Execution

OpenClaw doesn't just give advice—it can:

• Modify code
• Create files
• Run shell commands
• Install dependencies
• Execute scripts

For example:

# Clone the target project locally
git clone project
# Install project dependencies
npm install
# Run the tests to verify the change didn't break anything
npm run test

The AI executes these operations directly.

The key to execution is result feedback: each command's stdout, stderr, and exit code flow into the next round of context. If tests fail, the model sees exactly which case broke and what the error was, then goes and fixes it itself—that is what "iterating until the task is done" looks like in practice.

3) Tool Calling

OpenClaw can invoke different capabilities through tools, such as:

• Filesystem
• Shell
• Git
• HTTP APIs
• Build tools
• Test frameworks

A tool is essentially a described interface exposed to the model; the model decides on its own which one to call and with what arguments, based on the task. The mechanism is extensible: wrap an internal system in an interface and register it, and the agent can operate it. The capability boundary isn't set by the framework itself but by how many tools you're willing to plug in—of course, the more you plug in, the more careful you need to be about access control.

OpenClaw's Weaknesses

As capable as OpenClaw is, it still has some obvious problems.

1) Heavily Dependent on the Model

OpenClaw's capability is highly dependent on the underlying model.

If the model isn't strong enough:

• Task planning degrades
• Code quality drops
• Execution goes wrong more often

So in many cases:

Agent capability ≈ model capability

With a weak model, OpenClaw becomes pretty dumb too.

This problem gets amplified in agent scenarios: in a normal conversation, if the model gets one answer wrong, a human glances at it and corrects it; in a multi-step execution loop, a mistake in the first planning step is inherited by every subsequent step—errors compound. Prompt engineering at the framework level can absorb some of this, but it can't paper over the model's own reasoning gaps.

2) Token Cost

Agent systems typically require:

• Multiple rounds of reasoning
• Many model calls
• Persistent context

Token consumption is very high—every call carries a large amount of context. Tuning only trims part of the overhead, and swapping in a cheaper model brings back the problem above: OpenClaw becomes completely unreliable and uncontrollable.

The reason isn't hard to see: every round of calls has to carry the task goal, action history, file contents, and command output, so context grows roughly linearly with the number of iterations, and each round is a full model call. A multi-step task can easily cost tens of times more than a single conversation. Cost and capability form an unavoidable tension here—save money with a weaker model, and the first problem comes knocking immediately.

Pitfalls and Caveats

Given the two weaknesses above, a few practical suggestions:

• Don't run it directly in production. The agent really does execute commands—deleted files and changed configs are deleted and changed for real. Run it in a container or an isolated working directory with minimal permissions.
• Keep tasks small. The bigger the goal, the more likely planning drifts off course, and the faster the context balloons. "Add a cache" is far more reliable than "refactor the entire data layer."
• Watch the execution. Given the opacity problem mentioned earlier, without a companion monitoring platform you should at least keep complete operation logs, so you can trace afterward what it actually touched.
• Cap the cost. Token consumption across multiple iterations can spiral easily, especially when the model keeps retrying the same mistake. Set a round limit or a budget cap so you don't wake up to an exploded bill.

Overall

OpenClaw is an AI agent framework with a lot of potential.

Strengths:

• Automatic task planning
• Autonomous execution
• An extensible agent architecture

Weaknesses:

• Heavily model-dependent
• High token cost (model calls are very frequent; capability on complex tasks depends entirely on the model)
• Opaque execution (a serious issue—the execution process is completely opaque and needs a control platform for monitoring)

For now it's a better fit for:

• AI-driven development automation
• DevOps automation
• AI agent experiments

But combined with:

• A strong model
• A visualization system
• An agent management platform

it could eventually become:

Core infrastructure for AI-automated teams.

Wrapping Up

The value of an agent framework is connecting model output to the real environment in a closed execution loop, and OpenClaw covers that path completely: planning, execution, and tool calling are all there. But its ceiling is locked by model capability, and its floor is dragged down by cost and opacity. My current usage pattern: small tasks, isolated environments, eyes on the logs. Once the monitoring and management ecosystem around it matures, I'll consider putting it into more important workflows.