- The best way to write openclaw agents that work is to write them outside of openclaw. LLM automation is only as good as the feedback mechanisms you give it as you’re formulating the automation, and there are limits to the chat system interface. I use claude and codex simultaneously while building agents with what I call the pingpong strategy. I give them a guideline on what I want to accomplish, then I ask one of them to write a design document. They argue with each other about that document until they reach broad agreement, then I just review, correct if they’re off course, and let them write the software.
#Can you explain this advice given about setting up agents for someone new to openclaw?
copper wolf
fathom hornetBOT
nocturne ermineBOT
What they mean by “write agents outside of OpenClaw” is basically: treat OpenClaw as the runtime/launcher, not as your IDE.
Why that’s good advice (especially for beginners)
The in-chat interface is convenient, but it’s a rough place to build automation because:
- Weak feedback loops: in chat you can’t easily run tight “edit → test → diff → repeat” cycles.
- Hard to review changes: prompts/config/scripts evolve, but chat doesn’t give you good diffs, history, or versioning.
- Multi-file work is painful: real agents usually need instructions + config + helper scripts + sample inputs/outputs.
- You want reproducibility: if it worked once in chat, that’s not the same as “it works reliably every time”.
So “outside OpenClaw” usually means: a normal folder/repo on your machine, with files you can edit, diff, and test (VS Code, git, unit tests, sample data, etc.).
What “pingpong strategy” means
They’re describing a workflow like:
- Write a short goal statement (“I want an agent that does X, success looks like Y, constraints are Z”).
- Ask Model A to draft a design doc (approach, edge cases, tool usage, failure modes).