tool built upon coding agents such as Claude Code. It allows you to have a coding agent running 24×7, working proactively and reactively to solve tasks. I’ve set up multiple OpenClaw instances already and have learned a fair few things through active usage. I’ve also discussed it a lot with colleagues who work with OpenClaw agents on a daily basis, and in this article, I’ll share some of the tips and tricks I’ve learned on how to get the most out of OpenClaw and some mistakes that I’ve made, which I’ll tell you how to avoid.
Why set up OpenClaw
The main reason you should set up OpenClaw is that it can make you more effective as an engineer. Where you previously had to run everything in Claude Code and be on your computer and ready to work at all times, OpenClaude can be run from a separate computer and accessed from anywhere through applications like Telegram or Slack. This makes it incredibly easy to interact with a coding agent such as Claude Code, and you can interact with it from anywhere.
Furthermore, you can easily set up cron jobs and skills, which make the agent run code at specific intervals and always remember to do that. And it can have skills that it loads on demand to better perform specific tasks.
All in all, OpenClaw simply makes your coding agents a better assistant. It makes it more available and better able to perform tasks.
Mistake 1: Not running in Docker
The first mistake I made was not running OpenClaw in Docker containers. There are many reasons you should run OpenClaw agents in Docker containers, and I’ll list a few of them here.
- It’s more secure. Your agent can’t access everything on your computer; it can only access what’s available in the Docker image.
- It’s super easy to make safety copies of your agent and move them anywhere, since you can simply download a Docker image and use it somewhere else. This works because a Docker image is a completely separate container that can be run entirely on its own.
- If you run multiple agents on the same computer, it separates them better so that there’s no overlap between your agents.
Overall, there’s no real reason not to run in Docker. It’s also super simple to set up running OpenClaw in Docker since you can simply ask your coding agent to set everything up for you. In reality, you don’t have to do anything yourself, and the coding agents are extremely proficient at setting up the Docker system for you. When I did this myself, I basically didn’t have to do anything except prompt the model to set up OpenClaw in Docker, and it implemented it with no problem.
Mistake 2: Not give agent proper training
Mistake number two is not giving your agent the proper training and setup help that it needs to perform well. When I set up my first agent, I spent a maximum of ten minutes explaining what it was supposed to do, gave it the necessary permissions, and hoped that that would be enough.
It turned out that’s not how you do it at all. What ended up happening is that my agent wasn’t really able to do any of the tasks it was supposed to do because it hadn’t received specific training on how to execute those tasks. I, for example, gave my agent access to AWS without telling it how to access AWS, how to use it, how to interact with people through Slack, and so on.
What ended up happening specifically for me was that the agent started interacting with people on Slack in messages it shouldn’t have replied to. And when it was specifically tagged, it didn’t know exactly what to do in those situations.
To solve this problem, you need to give your agent super-specific training and tell it what it is supposed to do, what it’s not supposed to do, and how it’s supposed to do the tasks you ask it to do.
For example, if you give it AWS access and let it interact with people through Slack, you should:
- Explain to it the AWS docs so that it knows exactly how to use it and doesn’t make incorrect API calls or SDK calls.
- Explain to the agent which messages it should reply to and which messages it shouldn’t reply to, which ones are relevant, basically.
- Explain to it the different questions people might ask and how it should approach answering those questions. For example, if someone asks about a specific customer, it should look up that customer in the customer table, look at the different instances that are relevant to this customer, and ask the user clarifying questions.
Mistake 3: Not giving your agent enough permissions
Mistake number three is when you set up your agent correctly but you haven’t given it enough permissions to do what it’s supposed to do. For example, if you have asked your agent to perform a bunch of AWS tasks but not given it enough access, for example, it can only access DynamoDB but not S3 completely, it’s very hard for the agent to perform a task.
When you set up an agent, you should think of it as though it’s a human. If you gave an intern a bunch of tasks to perform, but you didn’t give the AWS permissions the intern needed to perform the task, it would be very hard for the intern to know what to do.
The intern wouldn’t know to ask for permissions, for example, or might not know because they’ve never dealt with this situation before. Or it might think it’s supposed to figure that stuff out itself, while in reality, you have to give it the permissions it needs.
Thus, you should do the following when setting up an agent.
- Think thoroughly through everything the agent is supposed to do and make sure it has access to all relevant resources. And if you don’t give it access to specific resources, make sure to inform the agent that it doesn’t have access to this and how to reply to people if they ask questions that require such access.
- Give the agent access to everything it might need, of course, within security concerns. This likely includes read access to almost everything you have, simply because read access is non-destructive.
- Monitor the agent’s performance, especially at the beginning of its setup. If you notice the agent struggling with specific tasks, you should help the agent by telling it how to resolve such tasks. And you should either provide or revoke access that the agent needs or doesn’t need.
Overall, it all comes down to monitoring your agent and making sure that it works as expected.
Conclusion
In this article, I’ve discussed three common mistakes that are made when setting up OpenClaw and that I’ve made specifically myself when I’ve set up OpenClaw agents. These mistakes severely limit the effectiveness of OpenClaw, so I highly recommend following all of the tips I’ve provided in this article and avoiding the three mistakes I’ve listed. Overall, however, it all comes down to monitoring your OpenFlow agent and helping it where you can notice the agent is struggling. If the agent is struggling with specific tasks, it’s most likely not an agent problem, but rather a setup problem or a user error. Thus, you should monitor your agent and make sure it is effective at the tasks you ask it to do.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
💌 Substack
