Back to articles

My Personal OpenClaw: How Claude Code Became My Agentic Orchestrator

AI Agents · April 2026 · Jacint Gauxachs Marin
My personal OpenClaw with Claude Code

I've been building at home what companies now charge a monthly fee for. This is the story — with architecture, configuration and real numbers — of how Claude Code has eaten a big chunk of my automation stack.

A few days ago, while scrolling through Google, I got served a sponsored ad: ClawBro, a managed version of OpenClaw, the open-source agentic assistant that automates workflows, reviews code, organizes files and executes tasks from the cloud. I looked at it for a couple of seconds — "from $30/month, get started in 5 minutes" — and I thought: "I've been doing exactly this at home with Claude Code for months."

And you probably can too. This article is my take on why I believe we're at the start of a paradigm shift in how we build software solutions, followed by a 100% functional case study you can adapt to your own infrastructure. No fluff, with the real snippets I use every day.

Three eras of automation (and why we're in the third)

Era 1 — Writing code directly

Python scripts, cron jobs, custom Flask/FastAPI services, Git repos full of utilities built from scratch. Maximum flexibility: if you can code, there's nothing you can't do. But every new automation costs hours, breaking it is easy, and maintaining it — documenting it, refactoring when a dependency changes, explaining it to the next person — is a cost you pay forever.

I've been in this world for years: I have scripts that took a weekend to write and which I've had to fix three times in the last year because an API changed, a library got deprecated, or a file format shifted.

Era 2 — Low-code tools (n8n, Flowise, Zapier, Make…)

They came to democratize automation: visual nodes, drag-and-drop, triggers, webhooks, ready-made connectors for hundreds of services. You build in an afternoon what used to take a full sprint. I use n8n daily and I'm not giving it up.

But there's a ceiling. The moment a flow moves beyond "receive this, send that" into "think about this and decide what to do", you find yourself writing custom JavaScript nodes which are, literally, code. The difference is that now it's code buried inside a 400-line JSON file only you understand, that breaks when you move a node, and that you can't version cleanly. You've paid the rigidity cost of code without gaining the flexibility.

Era 3 — Orchestrated agents

The fundamental difference: in the first two eras you program the flow; in the third you define capabilities and an agent decides how to combine them. The shift sounds small but it isn't.

When I tell Claude Code "I need documentation about X", I'm not triggering a predefined workflow. The orchestrator understands intent, decides which sub-agents to activate, in what order, with which model (cheap or expensive depending on the task), where to store artifacts, and what to do when something fails. It does all that without me having drawn a graph.

An agent doesn't execute a flow: it decides one.

Why Claude Code changes the rules

Claude Code isn't a chatbot in a terminal. It's a full agentic runtime with five primitives that turn it into something different:

And on top of everything: it's headless-capable. It runs just the same in an interactive terminal as executed remotely over SSH, triggered by a webhook, or launched by cron. That's what makes it a real automation engine, not just a pair-programming buddy.

Case study: a project orchestrator

What I'm about to show you is the skeleton I have running at home, adapted so you can replicate it. The use case is deliberately provocative: a single command creates a new project in a subfolder, a chain of specialist agents executes it, and the final deliverable lands in your Telegram.

Concrete example: I type "generate documentation about Claude as an agentic platform". The orchestrator creates ~/projects/claude-agentic-docs/, launches a researcher that searches, summarizes and saves sources, a writer that produces the Markdown draft, an editor that polishes, a pdf-generator that converts, and a delivery agent that sends the PDF to my Telegram. All while I'm doing something else.

Architecture of the Claude Code agentic project orchestrator
Full architecture. CLIPROXYAPI sits on the side because Claude Code's agents don't use it — they talk to Claude's API directly. It's n8n that uses it when a workflow needs to invoke an LLM (Gemini, Kimi, or an extra Claude slot without eating into your subscription).

The setup: folder structure

It all starts with a .claude/ folder at the root of your projects directory. Claude Code reads it automatically:

~/projects/
├── .claude/
│   ├── agents/
│   │   ├── project-orchestrator.md
│   │   ├── researcher.md
│   │   ├── writer.md
│   │   ├── editor.md
│   │   ├── pdf-generator.md
│   │   └── telegram-delivery.md
│   ├── skills/
│   │   └── new-project.md
│   └── settings.json
└── <filled in automatically with projects the agents create>

Three things happen here:

My minimal settings.json for this project:

{
  "permissions": {
    "allow": [
      "Bash(mkdir:*)",
      "Bash(pandoc:*)",
      "Bash(curl https://n8n.example.com/webhook/claude-notify)",
      "WebFetch"
    ]
  },
  "hooks": {
    "Stop": [
      {
        "matcher": ".*",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/notify-telegram.sh" }
        ]
      }
    ]
  }
}

With that Stop hook, every time a task finishes I get a Telegram ping with the summary, without asking.

The agents, one by one

project-orchestrator.md — the director

The only agent that talks directly to me. It understands the request, decides the project slug, creates the folder and delegates. It runs on Opus because reasoning quality is what matters most here.

---
name: project-orchestrator
description: Orchestrates multi-agent projects. Use PROACTIVELY when the user asks to create, research, write or deliver any multi-step deliverable (documentation, report, study, summary).
model: opus
tools: Bash, Read, Write, Agent
---

You are the project orchestrator. For every request:

1. Derive a kebab-case project slug from the user's request.
2. Create ~/projects/<slug>/ and ~/projects/<slug>/research/
3. Produce a short plan (3-7 bullet points) — save it to ~/projects/<slug>/PLAN.md
4. Invoke sub-agents in sequence:
   - researcher   → populates research/
   - writer       → produces draft.md
   - editor       → produces final.md
   - pdf-generator → produces output.pdf
   - telegram-delivery → sends the PDF
5. Report back the absolute path of output.pdf and a 2-line summary.

Never write the content yourself. Delegate. Your job is coordination.

researcher.md — the fact-finder

Haiku. Doesn't need literary brilliance, needs to search, read and summarize well. Cheap, fast, good enough.

---
name: researcher
description: Given a topic, performs web research and produces a structured research/ folder with notes and sources.
model: haiku
tools: WebFetch, WebSearch, Write, Read
---

You research. Given a topic:
1. Identify 5-8 authoritative sources (official docs, reputable blogs, academic).
2. For each, save a markdown file in research/ with: URL, 5-bullet summary, 2-3 verbatim quotes.
3. Write research/_index.md with a table of all sources and one-line descriptions.

Do not write the final document. Do not interpret. Be faithful to the sources.

writer.md — the pen

Opus. Here you do want the best model: it's building the deliverable.

---
name: writer
description: Given a research/ folder, produces a coherent draft.md in the target language.
model: opus
tools: Read, Write
---

You are a technical writer. Read research/_index.md and the individual source files, then:

1. Produce draft.md with a clear structure (introduction, 3-5 sections, conclusion).
2. Cite sources inline using [^n] footnotes pointing to research/.
3. Aim for 2000-3000 words, unless the orchestrator specified otherwise.

Voice: informed, direct, no filler. No AI disclaimers, no meta-commentary.

editor.md — the style proofreader

Sonnet. Middle ground: smart enough to catch real improvements, without Opus pricing.

---
name: editor
description: Polishes draft.md into final.md — fixes style, consistency, redundancies, and ensures citations resolve.
model: sonnet
tools: Read, Write
---

Read draft.md and produce final.md applying:

1. Tighten prose (cut 10-15% without losing meaning).
2. Fix inconsistencies in tone, terminology, capitalization.
3. Verify every [^n] citation maps to a file in research/; flag orphans.
4. Add a 2-sentence executive summary at the top.

Do not rewrite structure unless clearly broken.

pdf-generator.md — the printer

Haiku. It just converts Markdown to PDF with pandoc. No heavy reasoning needed.

---
name: pdf-generator
description: Converts final.md to output.pdf using pandoc + a clean template.
model: haiku
tools: Bash, Read
---

Run:

pandoc final.md \
  --from markdown \
  --pdf-engine=xelatex \
  --template=~/.claude/assets/article.latex \
  -V geometry:margin=2cm \
  -V mainfont="Inter" \
  -V monofont="JetBrains Mono" \
  -o output.pdf

Verify the file exists and report its size.

telegram-delivery.md — the messenger

Haiku. Does a POST to the n8n webhook with the PDF. The n8n workflow talks to the bot.

---
name: telegram-delivery
description: Uploads output.pdf and notifies the user via the claude-notify n8n webhook.
model: haiku
tools: Bash
---

1. Upload output.pdf to Telegram via the bot API using the document multipart endpoint.
2. POST a notification to https://n8n.example.com/webhook/claude-notify with:
   { "emoji": "📄", "title": "Project ready", "message": "<project>: output.pdf (<size> MB)" }

Be silent otherwise.

The skill that fires it: /new-project

To avoid typing the same prompt every time, a skill wraps the orchestrator invocation:

---
name: new-project
description: Creates and executes a new multi-agent project based on the user's request.
---

When invoked, pass the entire argument string to the `project-orchestrator` agent. Do not ask clarifying questions unless the request is clearly ambiguous (less than 3 words).

Then inside Claude Code I simply type:

/new-project documentation about Claude as an agentic platform

In motion — a real request, step by step

  1. I type /new-project … into Claude Code (terminal or remotely via Telegram through the listener).
  2. The skill fires the orchestrator (Opus). It creates ~/projects/claude-agentic-platform/, writes PLAN.md, and delegates to the researcher.
  3. The researcher (Haiku) finds 7 authoritative sources. For each it saves a .md with summary and quotes. Generates research/_index.md. Reports back.
  4. The orchestrator delegates to the writer (Opus). 2500-word draft.md with footnotes comes out.
  5. The editor (Sonnet) picks up the draft and produces a polished final.md with exec summary. Flags an orphan citation; the orchestrator asks the writer to fix it.
  6. The pdf-generator (Haiku) runs pandoc. Verifies the 412 KB output.pdf.
  7. The delivery agent (Haiku) uploads the PDF to the Telegram chat and calls the claude-notify webhook with the summary. My phone buzzes.
  8. The Stop hook sends an extra ping with the token usage log. Total: ~95,000 tokens, ~12 minutes wall clock.

Real cost optimization

This is what separates a demo from a system you actually use daily. The trick isn't "use the cheapest model everywhere", it's use the right model at each step.

AgentModelTokens (approx.)Why
project-orchestratorOpus 4.78,000Few calls but critical reasoning; if this agent slips up, it cascades downstream.
researcherHaiku 4.535,000High volume but simple tasks: summarize, extract quotes.
writerOpus 4.730,000It's the deliverable; model quality shows in the prose.
editorSonnet 4.618,000Catches real improvements without Opus pricing.
pdf-generatorHaiku 4.52,000Just invokes pandoc, doesn't think.
telegram-deliveryHaiku 4.52,000Two HTTP calls, nothing else.

If I ran every agent on Opus, the same project would cost roughly 4× more. With this split, a full project of ~95,000 tokens fits comfortably inside my Max subscription without hitting limits.

So where does CLIPROXYAPI fit then? In my setup, I use it from n8n, not from Claude Code. When an n8n workflow needs to call an LLM — for instance to preprocess an incoming message or to respond to a user who pings the Telegram bot without going through Claude Code — instead of consuming my Anthropic quota, the workflow points to http://llm-proxy.internal:8317/v1 and the proxy round-robins across 5 OAuth accounts (Gemini, Kimi, and a secondary Claude). Those calls are free within each provider's free tier. Clean separation: Claude Code talks to Claude directly, n8n uses the proxy for its own needs.

What else you can do with this

Once you have the orchestrator + sub-agents + storage + delivery pattern running, use cases multiply:

Closing thought

What fascinates me about all this isn't so much the outcome — making a PDF isn't rocket science — but the fact that I can describe a new capability in a 40-line text file and the system absorbs it without me touching anything else. I don't rewrite a flow, I don't reconfigure nodes, I don't deploy a service: I write a .md, and the next day the orchestrator uses it when it makes sense.

ClawBro and similar services are perfectly fine for people who don't want to build anything; but if you already have your own infrastructure, some technical discipline and curiosity about how the layer below works, Claude Code gives you exactly the same thing, with full control, at the cost of a subscription. It's not the future: it's now, and it's ridiculously accessible.

If you decide to build something similar and get stuck along the way, reach out. I'm genuinely curious about what use cases others come up with for this pattern.

Back to articles