OpenClaw keeps task goals, history, and communication separate from the implementation details that workers need.
2
Parallel workers in separate work trees let one person manage several coding tasks while a manager reviews their output with different context.
3
Jeffrey Lee-Chan uses tmux, OpenClaw, and multiple models to move human review toward the start or end of a task.
Summary
Jeffrey Lee-Chan describes a development setup built around OpenClaw, parallel agents, tmux terminals, and separate work trees. He sends short messages because OpenClaw retains context about earlier requests, such as the meaning of his "skeptic agent." He prefers an orchestrator manager to make decisions from goals, specifications, and recent communication, while workers focus on code and implementation. This separation can reduce the bias that appears when a coding agent evaluates its own work. Jeffrey shows an AI RPG and a multi-model analysis site as examples of applications built with the setup. He also discusses staging and production OpenClaw instances, browser testing, sandboxing, and model costs. His practical position is that engineers should spend less time typing implementation instructions and more time reviewing notifications, test results, and competing proposals.
OpenClaw lets short requests carry the history of the task
Jeffrey says OpenClaw can retain context and memory about earlier conversations. A short Slack message such as "fix this thing" can refer to a project the agent already knows, including his custom "skeptic agent" for code review. He combines this with multiple agents, separate work trees, and CI. The result is that he can communicate briefly and still get a reasonable outcome, although he sometimes has to debug timeouts or other failures. He says his own responses to agents are ordinary enough that an agent could eventually replace much of his role.
The stack separates task direction from code implementation
Jeffrey describes OpenClaw as a concept built around frictionless communication and a central axis of control. At one end, he gives agents more autonomy through agent orchestrator managers. At the other, he uses tmux terminals when he wants more direct control. The workers run through a fork of the open-source Agent Orchestrator framework. A managed worker can run Claude Code, which can itself run agents and subagents. He says this lower part of the stack changes frequently, while the manager focuses on directing the overall work.
The manager should reason from goals instead of inheriting coding instructions
When asked why he uses OpenClaw rather than Claude directly, Jeffrey points to specialization. He wants the manager's context to contain the task specification, goals, and history of what he has asked for. Opening Claude can immediately load files such as CLAUDE.md, skills, and MCPs, which describe how to perform implementation work. Jeffrey estimates that implementation context can take up a quarter of the available context. His preferred arrangement lets the manager assemble a specification from recent messages and related work, then pass that specification to workers.
Agents can now handle more of the browser testing loop
Jeffrey describes a testing flow that includes ordinary checks and a final visual browser test. Some behavior can be covered with CSS or JavaScript tests, but the last step may require confirming what the interface looks like. He recommends examining which parts of a project truly need human involvement and revisiting that division as models improve. He says agents used to struggle with tasks such as finding a pop-up and entering a password. More recently, he has found them capable of handling many browser tests that previously required manual testing.
A manager with different context can challenge a worker's confidence
Jeffrey shows two applications built with his setup, including an AI role-playing game with custom worlds, character choices, and dice rolls. He also shows a multi-model analysis site that collects answers from several models instead of making him copy and paste them manually. In his terminal workflow, he acts more like a manager than a coder. He believes direct coding creates a bias toward declaring the work successful. He contrasts a worker that would recommend merging its own pull request with a manager that notices another pull request should replace it and recommends closing the first one.
Staging can improve reliability while increasing token use
Jeffrey distinguishes an isolated sandbox from a second staging or development instance. Running the same work through both instances could double token use, so that is not how he recommends using them. His preferred arrangement is local development followed by integration tests on the staging instance. After the code is working, he would merge it and deploy to production. He says this would increase usage, though not necessarily double it, and could provide more reliability. He presents the setup as an experiment for people comfortable debugging it.
Jeffrey says he uses Codex 5.3 as his default orchestrator model and finds GPT-5.4 uses more tokens. He says even Codex 5.3 can exhaust his budget quickly, so he switches to MiniMax when usage gets low. MiniMax is less capable in his view, but it can complete some work. He explains that this choice is driven more by cost than by a strong model preference. Some tasks can continue on the cheaper model while other work remains on the more capable option.
"I would do local development and then I would run integration tests on the sandbox or staging one."13:58
Who should watch
You are building a coding-agent setup and want a manager to retain project context while separate workers handle implementation.
Your current coding agents tend to approve their own work, and you want an independent context for review and pull-request decisions.
You need to balance local development, staging tests, model capability, and token costs in a multi-agent workflow.
