Introduction
The following content is compiled by VIPSTAR in combination with X/social media public content and is for reading and research reference only.
focus
- OpenClaw poor students have too much stationery: you may not need 4 Workspaces
- Recently I have seen an interesting phenomenon in the OpenClaw community: many people are rushing to configure a bunch of workspaces when they first get started.
Remark
For parts involving rules, benefits or judgments, please refer to Mortal Xiaobei’s original expression and the latest official information.
OpenClaw poor students have too much stationery: you may not need 4 Workspaces
a counterintuitive observation
Recently I have seen an interesting phenomenon in the OpenClaw community: many people are rushing to configure a bunch of workspaces when they first get started.
The architecture is beautifully drawn:
There is a clear division of roles and clear boundaries of responsibilities. Then what?
Each workspace is empty, and the Coordinator can do everything by itself.
This reminds me of what my teacher said when I was a kid: Poor students have more stationery.
It’s not just newbies making mistakes
You may think this is a newbie question. But no.
Saw a post on Reddit r/n8n the other day. n8n is a no-code workflow platform, and its users are mostly experienced developers and automation experts. The post said:
“I have seen too many workflows where 5-6 specialized agents coordinate with each other. If I open it up, I can actually do it with 3 nodes + an agent.”
He gave an example: Someone created three agents, email drafting, email sending, and email followup tracking.
One agent + three tools can obviously solve the problem, but it has to be split into three agents.
Similar sounds also appeared in large factories. GitHub recently published a blog “Multi-agent workflows often fail”, reviewing the pitfalls they have encountered in Copilot and internal automation:
「Most multi-agent failures come down to missing structure, not model capability.」
Translation: The main reason for multi-agent failure is not insufficient model capabilities, but structural design problems.
What’s interesting is that n8n is a no-code community, and most of its users are pragmatists who “just use it”; GitHub is an engineering team of a major manufacturer that pays attention to architecture and best practices. People on both sides have completely different backgrounds, but they are making the same mistakes.
Why?
Because we naturally love to make simple things complicated.
Why do we love over-design?
Complex = professional?
Human beings have a deep-rooted intuition: complex things are more powerful.
The four agents have a clear division of labor, with arrows pointing back and forth, which looks much more “professional” than one agent working alone.
But this is an illusion.
Drawing architectural diagrams is great. You are creating, you are planning, and you feel that you are doing “correct engineering practice.”
It is very painful to make an agent truly run through. You have to deal with edge cases, you have to debug strange bugs, and you have to face the soul torture of “Why can’t it do such a simple thing well?”
Why do poor students have so much stationery? Because buying stationery is easier than doing homework, and organizing stationery is more enjoyable than solving problems.
The temptation of division of labor
In 1776, Adam Smith told the story of a needle factory in “The Wealth of Nations”: ten workers working together could produce 48,000 needles a day; one person working alone could not produce even 20 needles a day.
Specialization brings efficiency gains, which is the cornerstone of economics.
But what Smith didn’t tell you is: specialization also brings coordination costs.
Who is responsible for what? How to hand over? Who will take care of things if something goes wrong?
In 1937, economist Ronald Coase asked a question: If the market division of labor is so efficient, why are firms needed?
The answer is: transaction costs. The costs of finding people in the market, negotiating, signing contracts, and supervising implementation…these costs may add up to more than “hiring one person to do it all.”
The boundaries of an enterprise depend on the balance between coordination costs and division of labor benefits.
The same goes for AI Agents.
Tools have changed, and so have boundaries.
Interestingly, in recent years we have seen a trend: more and more one-person companies.
One person + Vercel + Supabase + Stripe + ChatGPT can make products that previously required 10 people.
Why? Because the tools have gotten better.
When one person + good tools can do the work of three people, you don’t need three people. Not because three people are bad, but because the cost of coordinating three people may be higher than the extra work.
OpenClaw’s Skill system has this logic:
- Skill is capability expansion: install a new tool on the agent
- Agent is a split role: develop an independent brain
Do I need a “weather agent” to check the weather? No, just install a weather skill.
Most of the “specialized requirements” can be solved using skills, and there is no need to dismantle the agent.
Coordination costs are severely underestimated
Hidden costs of multiple agents:
- Context is lost: What the coordinator knows, the researcher does not know
- Format alignment: pass JSON here, expect Markdown there
- Status synchronization: Who is doing what? Where have you been?
- Error propagation: If the Researcher makes an error, how do you tell the Coordinator?
Within an agent, these are all automatic. Split into multiple agents, each item must be processed explicitly.
The GitHub blog also mentioned that agents will make many implicit assumptions about status, order, and format. When these implicit assumptions go wrong, the entire system breaks down.
our lessons
Tell us about ourselves.
At the beginning, we excitedly set up multiple workspace configurations. Four characters, four sets of bots, the configuration took a day.
After running for two weeks, I found:
- Searching for information? Just use web_search directly in main
- In-depth analysis? Main can also be used to load analysis skills.
- On a mission? Main calls various tools and that’s it.
There is only one scenario that really requires an independent agent: writing code in parallel.
For example, if you are working on a website project, let Codex write the front-end and Claude Code write the back-end, and the two can run at the same time. This is “really need more agents”.
a concrete example
I recently built a website and had 8 front-end tasks.
Option A: One Codex sequence
- Time taken: 4 hours
- Coordination cost: 0
Option B: 8 Codex done in parallel
- Time taken: 30 minutes
- Coordination costs: merge conflicts, inconsistent styles, duplicate components
We chose option A.
When to use plan B? When backend + frontend are connected, it only makes sense for the two Agents to run in parallel, because waiting for each other is a waste.
Lesson: Early demolition = increased coordination costs + no benefits.
If it really needs to be demolished
That’s not to say never dismantle it, but to wait until it encounters a bottleneck before dismantling it.
When is it really needed?
- True parallelism: two tasks run at the same time, independent of each other
- Hard isolation requirements: different permissions, different contexts
- Context explosion: the context window of a single agent is really not enough
What to do after demolition
If you do decide to split, have these ready:
- Explicit handover checklist
Every handoff must be clear: output format, tone goals, context, completion criteria. Don’t assume the other person “should know.”
- Three logs
- Action log: what was done
- Rejection log: why not done (most easily ignored, but most valuable)
- Handover log: to whom and what
Rejection logs are particularly important. “Why it was not done” is often invisible work that no one sees, but if it is not done, the system will have problems.
- near-miss summary
Regular statistics of “almost accidents but being caught” incidents. These data allow the value of coordination to be quantified, preventing coordinators from being underestimated, resources being cut off, and the system from collapsing.
correct order
1. First let a workspace actually work
Able to complete daily tasks
Ability to handle edge cases
Able to produce stable output
1. Use Skills to expand capabilities
Need new capabilities? install skill
No new roles required
1. Consider dismantling when encountering bottlenecks
Single agent response is too slow → Consider parallelism
Context is too long → consider splitting
Permissions need to be isolated → consider independent workspace
Don’t skip 1 and 2, go straight to 3.
Coase’s problem
Back to Coase’s question: Where are the boundaries of the enterprise?
The answer is: when internal coordination costs = external transaction costs.
The same goes for the boundaries of AI Agents.
It is only worth splitting when “the benefits of splitting into multiple agents” > “coordination costs”.
Otherwise, there are too many stationery items for poor students.
Questions for you
Before you rush to provision a second workspace, ask yourself:
- Is it true that a workspace + skills can’t do it?
- After demolition, are you ready to coordinate the costs?
- Are you solving problems or enjoying the thrill of “designing complex systems”?
If you can’t dismantle it, don’t dismantle it. If you want to dismantle it, you have to wait until you encounter a real bottleneck.
source
author:Mortal Xiaobei
Release time: February 28, 2026 22:57
source:Original post link
Editorial comments
This article “X Import: Mortal Xiaobei – OpenClaw poor students have many stationery: you may not need 4 Workspaces” comes from the X social platform and is written by Mortal Xiaobei. Judging from the completeness of the content, the density of key information given in the original text is relatively high, especially in the core conclusions and action suggestions, which are highly implementable. OpenClaw students have a lot of stationery: you may not need 4 workspaces. A counter-intuitive observation. Recently, I saw an interesting phenomenon in the OpenClaw community: many people are rushing to configure a bunch of workspaces when they first get started. The architecture is beautifully drawn: clear division of roles and clear boundaries of responsibilities. Then what? Each workspace is empty, and the Coordinator can do everything by itself. This reminds me of what my teacher said when I was a kid:…. For readers, its most direct value is not “knowing a new point of view”, but being able to quickly see the conditions, boundaries and potential costs behind the point of view. If you break this content down into verifiable judgments, it would at least include the following levels: OpenClaw has a lot of bad students: you may not need 4 Workspaces; I recently saw an interesting phenomenon in the OpenClaw community: many people are rushing to configure a bunch of workspaces when they first get started. . Among these judgments, the conclusion part is often the easiest to disseminate, but what really determines the practicality is whether the premise assumptions are established, whether the sample is sufficient, and whether the time window matches. We recommend that readers, when quoting this type of information, give priority to checking the data source, release time and whether there are differences in platform environments, to avoid mistaking “scenario-based experience” for “universal rules.” From an industry impact perspective, this type of content usually has a short-term guiding effect on product strategy, operational rhythm, and resource investment, especially in topics such as AI, development tools, growth, and commercialization. From an editorial perspective, we pay more attention to “whether it can withstand subsequent fact testing”: first, whether the results can be reproduced, second, whether the method can be transferred, and third, whether the cost is affordable. The source is x.com, and readers are advised to use it as one of the inputs for decision-making, not the only basis. Finally, I would like to give a practical suggestion: If you are ready to take action based on this, you can first conduct a small-scale verification, and then gradually expand investment based on feedback; if the original article involves revenue, policy, compliance or platform rules, please refer to the latest official announcement and retain the rollback plan. The significance of reprinting is to improve the efficiency of information circulation, but the real value of content is formed in secondary judgment and localization practice. Based on this principle, the editorial comments accompanying this article will continue to emphasize verifiability, boundary awareness, and risk control to help you turn “visible information” into “implementable cognition.”