How Sharbel Runs His Business With Four OpenClaw AI Agents

The old page title implied a broad case study about AI agents running multiple businesses. Sharbel A.’s 13-minute video tells a narrower and more useful story: a single human operator, one AI chief-of-staff agent, and three specialist agents that handle repeatable work while the human keeps final judgment.

OpenClaw Academy did not operate Sharbel’s setup, and this analysis does not claim to have audited it. Cost, time-saving and performance numbers are Sharbel’s own reported figures. The architecture and security commentary is ours.

The setup at a glance

The useful lesson is not “four agents replace four people.” It is that a small, explicit operating model can turn repeated checks and first drafts into review queues.

What Sharbel says he built

In the video, Sharbel says he runs a marketing agency, a trading bot, a content pipeline, and a YouTube channel with one AI employee named Max. He says Max runs on a $600 Mac Mini on his desk and is the only agent he talks to directly on Telegram.

Sharbel describes four agents in the system:

• Max — the chief-of-staff layer that delegates work and reports back.
• Sage — the content specialist that drafts tweets, analyzes performance, studies competitors, and generates tweet ideas.
• Knox — the trading operations agent that monitors a crypto prediction-market bot, checks for errors, and reports health.
• Nova — the YouTube strategist that tracks metrics, researches trending topics, and pitches video ideas.

He says the system moved him from roughly eight hours of manual work per day to about two hours of review and approval. He also says the monthly spend is about $140, with roughly $100 for the core API usage, about $20 for electricity, and about $20 for other APIs; the Mac Mini itself was a one-time $600 purchase.

The video also includes a more important operational claim than the cost number: Sharbel says the setup improved because he trained it with feedback. He says he approves or rejects outputs, gives reasons for rejections, and lets the agents learn from those rejections over time. He also says he started with one general assistant first, then added specialist agents only after he noticed repeated patterns in his own work.

What matters most in the workflow

The strongest part of Sharbel’s story is not the headline number of agents. It is the management structure.

Sharbel says he does not task every specialist directly; he only talks to Max, who delegates downward and reports upward. That creates a simple control plane: one place for prioritization, one place for review, and one place to absorb the operator’s preferences.

He also says he gives each agent a personality file and a user profile file. In the video, he names SOUL.md as the agent persona file and USER.md as the place where he stores context about himself, his business, and his preferences. Those files are part of the current OpenClaw workspace model, but the documentation also says to keep the workspace private and keep credentials outside it.

Sharbel’s reported schedule is concrete:

OpenClaw’s current scheduler persists jobs and run history as automations. The schedule matters because it turns agents from chat tools into recurring operational processes; the persisted receipts matter because they let an operator distinguish work that ran from work that merely sounded plausible.

OpenClaw Academy analysis: architecture takeaways

Here is the design lesson we would draw from Sharbel’s setup.

1. Use a single coordinator when the work is cross-functional. A chief-of-staff agent reduces chaos when one operator is juggling content, research, monitoring, and approvals. It also reduces the number of places where the human needs to keep context.

2. Separate specialist work from approval authority. If the same agent that drafts content also auto-publishes it, you have less control and less accountability. Sharbel’s review-and-reject loop is the safer pattern: agent proposes, human approves.

3. Treat feedback as data, not drama. The useful part of rejection is not the rejection itself; it is the reason attached to it. That gives the system a training signal and gives the operator a way to encode taste, policy, and quality standards.

4. Keep secrets and high-risk actions out of generic memory. If you are using files like user.md, keep them limited to the context the agent genuinely needs. Do not dump credentials, private keys, or unrestricted production access into broad memory files just because the model can read them.

5. Make schedules explicit and auditable. A good agent system should tell you when it ran, what it tried, what it changed, and what it asked you to review. Without that, you get automation without custody.

6. Start small and add roles only when repetition proves the need. Sharbel’s own story says he began with one general assistant and added specialists after noticing repeated tasks. That is the right direction for most teams: identify a recurring bottleneck first, then automate that bottleneck. If you implement genuinely separate OpenClaw agents, the current multi-agent model gives each one its own workspace, state directory and session store; preserve those boundaries instead of casually sharing every credential and transcript.

Sharbel’s five-step method, translated for operators

1. Track one week of work. Separate creative judgment from repetitive, monitoring and research work.
2. Start with one coordinator. Add a specialist only when repeated requests prove a stable role exists.
3. Write explicit identity and user context. Keep SOUL.md and USER.md useful but private; do not turn either file into a secrets store.
4. Record approvals and rejection reasons. Sharbel reports that more than 110 rejected content suggestions became useful feedback. The exact count is his claim; the general principle is sound only if the feedback remains inspectable and reversible.
5. Automate the schedule after the task is reliable. A recurring bad task is not an employee—it is a faster incident generator.

For a first deployment, pair that sequence with the installation guide, multi-agent orchestration guide, and current security baseline.

Security and reliability cautions

Sharbel’s video is persuasive, but it is still a self-reported demo. We do not independently verify the trading results, the workload reduction, the monthly spend, or the operational claims beyond what he says in the video.

That matters because OpenClaw’s current security model assumes the model can be manipulated and recommends limiting the resulting blast radius. Any always-on agent stack has the same broad risks:

• prompt injection through scraped content or untrusted inputs;
• accidental overreach if the agent has write access to production systems;
• hidden cost growth when tasks are routed to expensive models by default;
• weak auditability if approvals are not logged;
• and brittle behavior if one coordinator becomes a single point of failure.

So the right reading of this case study is not “put all your businesses on autopilot.” It is “centralize the control plane, constrain specialist agents, and keep a human approval boundary where mistakes are expensive.”

Bottom line

Sharbel’s video is best understood as a report about delegation, not replacement. The pattern he describes is a small AI org chart: one manager agent, a few specialists, and a human operator who reviews the final output.

That is a much more defensible story than “AI runs my entire business.” It is also the version most teams should copy: start with one trusted coordinator, add specialists only when repeatable work justifies them, and never confuse automation speed with operational safety.