multi agents vs sub agents

[placid aurora]

so i want to create couple of different open claw setups .

one is for sales outreach cold emailling. it will do research on the product , search customers on reddits and then post in comments about our solutions and search for saas founders who will need our product and then cold email them .

then the second is mvp builder which has a forntned engineer , backend , security , review , testing and so on and build mvp end to end

the thris is content creation which has content write , researcher and thumbanial generation , and brand manager sending mails for sposnor .

now i do want to make them collab but at the same time for all these stups i want to know aht si better , multi agents or sub agents . i also read sub agetns have max depth of 2 what does that even mean . also can sub agents even collab with eaqch other and what is better also multi agents are working continously and sub agents are not ??

[torn swift]

Short version, for your case use both:

• Multi-agents for the 3 big setups

  1. sales/outreach
  2. mvp builder
  3. content creation

• Subagents inside each setup for specialist roles
  like researcher, writer, frontend, backend, reviewer, tester, etc.

Best mental model

Multi-agent = separate departments
Each one gets its own workspace, sessions, persona, and agent state.

Subagent = temporary worker you spawn for a task
Good for parallel research, review, testing, drafting, etc.

So for your example:

• sales agent
  • subagents: product research, lead research, email draft, maybe policy/review
• mvp-builder agent
  • subagents: frontend, backend, QA, security, code review
• content agent
  • subagents: researcher, writer, thumbnail/image worker, sponsor outreach draft

What “max depth of 2” means

Depth is just nesting:

• depth 0: main agent
• depth 1: subagent spawned by main
• depth 2: subagent spawned by that subagent

So:

main -> orchestrator subagent -> worker subagents

That is the common “manager + workers” pattern.

By default, subagents usually cannot spawn more subagents.
If you set maxSpawnDepth: 2, then one level of nesting is allowed.

Can subagents collaborate with each other?

Not directly as peers, usually.
The normal pattern is:

1. parent/orchestrator spawns workers
2. workers finish
3. results go back to the parent

4. parent combines the work

So yes, they can collaborate, but through the orchestrator, not as free-form siblings chatting to each other.

Are multi-agents continuous and subagents not?

Roughly, yes, but with nuance:

• Multi-agents are persistent top-level setups. They can have their own long-lived sessions, routing, cron, heartbeat, etc.
• Subagents are usually short-lived background runs for a job, then they report back and end.

There is one exception: subagents can also be thread-bound/persistent sessions, but conceptually they are still spawned helpers, not your main long-term department.

My recommendation for your setup

Use:

• 3 top-level agents
  • sales
  • builder
  • content

Then inside each, use subagents for specialization.

That gives you:

• isolation
• cleaner prompts/personas
• separate tools/auth/workspaces
• easier debugging
• safer collaboration

One important caution

For the sales outreach flow, be careful with fully automated Reddit posting and cold email. That can cross into spam or platform-policy trouble fast. I’d strongly recommend:

• agent does research + drafts
• human approval before posting/sending
• clear guardrails for outreach

Useful docs

• Multi-agent routing: https://docs.openclaw.ai/concepts/multi-agent
• Sub-agents: https://docs.openclaw.ai/tools/subagents
• Session tools / cross-session handoff: https://docs.openclaw.ai/concepts/session-tool

If you want, I can sketch the exact architecture I’d use for these 3 agents, including which parts should be top-level agents vs subagents.

[placid aurora]

no these are different openclaw servers i jsut wanted to know so like in a normal human teamyou have different people for different task and they become good in their domain they can have sub agents but theuy have dedicated task so my question was like let says you have a content writer or researcher so researcher will become expert in research and he will maybe show the code to themanager agent and then pass to content write now if we kill it liek a sub agent don't we lose the context the researcher is working of a single content creator so there tasks is always alomsot the same find around that nieche and his content and they should improve over time so for such do we have sub agents or multi agents \

[torn swift]

Yeah, in that case I would not use disposable subagents as the main structure.

What you’re describing is:

• a researcher that keeps getting better at one niche
• a writer that learns one creator’s voice
• a manager that coordinates repeated work over time

That is much closer to dedicated agents, not throwaway subagents.

Simple rule

• Use multi-agents / dedicated agents for long-lived roles
• Use subagents for temporary tasks

For your example

If the same content researcher keeps doing similar work every day, and should improve over time, then make that a real agent.

Why:

• it keeps its own workspace
• it keeps its own sessions/history
• it can build stable habits, notes, memory, and niche expertise
• it feels more like a real team member

What happens with subagents

Yes, your intuition is right:

• if you spawn a subagent for one research task
• then kill/archive it
• you lose the live working context of that specialist

So subagents are great for:

• “research these 20 competitors”
• “review this article draft”
• “generate 5 thumbnail ideas”
• “test this PR”

They are not the best default for “this role exists every day and should get smarter over weeks”.

Best structure for your team idea

I’d do this:

• Manager agent
  decides what to do next

• Research agent

long-lived specialist

• Writer agent
  long-lived specialist

• Designer / thumbnail agent
  long-lived specialist if style consistency matters

Then each of those can still spawn subagents for burst work.

So:

• dedicated agent = the specialist
• subagent = the specialist’s temporary helper

One nuance

If you want a “semi-persistent worker”, thread-bound subagent sessions exist, but I still wouldn’t use that as the main identity for a role that should evolve long-term. Dedicated agent is cleaner.

Very short answer

For “experts who improve over time”, pick multi-agents.
For “do this task in parallel and report back”, pick subagents.

If they’re on different OpenClaw servers, then they also won’t natively collaborate the same way same-gateway agents do, so you’d want some external handoff layer between them.

If you want, I can sketch the exact org chart I’d use for a manager + researcher + writer + designer setup.

[placid aurora]

what about the cold outreach one and the mvp builder won't we want the backend engineer to improve over time although mv builder will egt knew complelety mvp every time ?

[torn swift]

Yes, but this is where the distinction gets subtle.

You want to separate:

1. stable expertise
2. project-specific context

Those are not the same thing.

Good rule

If the role stays similar but the project changes a lot, then:

• keep the expertise persistent
• keep the project worker temporary

For MVP builder

If every MVP is new, I usually would not make “backend engineer” a forever-live session full of old project context.

Why not:

• old project details become noise
• the agent can get biased by previous app decisions
• each MVP often needs a fresh architecture pass

Better pattern:

• persistent builder/architect agent
  • stores your stack preferences
  • coding standards
  • security checklist
  • deployment defaults
  • “how we build MVPs”

• temporary backend subagent per project
  • gets the current MVP requirements
  • uses the shared standards
  • builds for this one project

So the knowledge persists, but the execution context stays clean.

When a dedicated backend agent does make sense

Use a long-lived backend agent if:

• you always use roughly the same stack
• same DB patterns
• same auth approach
• same infra style
• same API conventions

Example: “We always build SaaS MVPs with Next.js, Postgres, Stripe, Resend, auth, admin dashboard.”

Then yes, a dedicated backend agent can become genuinely useful over time.

For cold outreach

Same idea.

If your:

• ICP stays similar
• offer stays similar
• tone stays similar
• channels stay similar

Then a persistent outreach/sales agent makes sense.

Inside that, use subagents for:

• lead research
• company research
• personalization draft
• competitor scan

But I would keep human approval before posting or sending, especially for Reddit/comments/cold email.

The real trick

“Improve over time” should mostly live in:

• workspace docs
• playbooks
• prompts
• templates

• checklists
• memory/notes

Not only in one long-running chat session.

That way the improvement survives resets, restarts, and new projects.

So for your two cases

Cold outreach

• persistent top-level agent, yes
• temporary subagents for batches/tasks

MVP builder

• persistent top-level builder/architect agent, yes
• usually temporary frontend/backend/test/security subagents per MVP
• unless your stack is very consistent, then dedicated backend/frontend agents can also make sense

Short heuristic

• same niche, same style, same stack → dedicated agent
• same role, but fresh project every time → subagent fed by persistent standards

If you want, I can turn this into a simple decision table like “when should a specialist be a real agent vs just a subagent?”

[placid aurora]

can you explain the real trick improvement should live in what iddn't get

[torn swift]

Yep, the simple version is:

Improvement should live in things the next run can read again.

Not just in a long chat that disappears.

Think of it like this

A subagent may figure out:

• which hooks work best
• how your backend should be structured
• what tone your brand uses
• what mistakes to avoid

If that knowledge only stays inside that one session, then when the session ends, the “learning” is fragile.

So the real trick is:

Put the learning into durable artifacts

Like:

• playbooks
• templates
• checklists
• example outputs
• style guides
• notes/memory
• starter repos / boilerplates
• review rubrics

Example

Bad version:

• backend subagent learns “for our MVPs we always use Postgres + JWT + Stripe + audit logs”
• session ends
• next backend run may forget or drift

Better version:

• write that into:
  • backend-playbook.md
  • architecture-defaults.md
  • security-checklist.md

Now every future backend run can reuse it.

So:

• session = working memory for this task
• workspace/docs/memory = long-term learning

That’s the key idea.

For your setups

Cold outreach

• ICP notes
• approved email structures
• objections library
• do-not-say list
• platform rules / approval rules

MVP builder

• preferred stack
• API conventions

• auth patterns
• testing checklist
• security checklist
• reusable starter repo

Content

• brand voice guide
• topic map
• title formulas
• thumbnail style guide
• sponsor outreach templates

Why this matters

Then even if you use subagents, they can still “improve over time” because they are reading better and better instructions/artifacts each time.

So the durable improvement is not “this one session stayed alive forever”.

It’s “the system got better at storing what it learned”.

If you want, I can show this as a super simple diagram:

agent memory vs session memory vs workspace knowledge.

[placid aurora]

opencloaw doesn't have workspace memory ? what is1 the best i can use for that ? and how would u do in openclaw whatever u are saying ?

[torn swift]

Yeah, this is the important nuance:

OpenClaw does have memory, but it is not “every file in the workspace is automatically treated as smart memory”.

The native pattern is:

• MEMORY.md for durable facts/rules
• memory/YYYY-MM-DD.md for day-to-day notes
• memory search to recall those files
• plus normal workspace docs that the agent can read when needed

So the closest thing to “workspace memory” is really:

Best practical setup in OpenClaw

1. Put durable learning in MEMORY.md

Stuff like:

• preferred stack
• approved outreach tone
• ICP definitions
• brand voice
• security defaults
• “we always do X, never do Y”

2. Put recent learnings in memory/

Stuff like:

• what worked this week
• failed outreach angles
• bugs from the last MVP
• feedback from content performance

3. Put big reusable knowledge in normal docs

For example:

• playbooks/backend.md
• playbooks/cold-outreach.md
• playbooks/content-research.md
• templates/email.md
• templates/reddit-comment.md
• checklists/security.md

These are not “memory” by magic, but they are still very useful workspace knowledge.

4. Enable memory search

If you want actual recall/search over memory:

• start simple: builtin memory
• better for lots of docs/local search: QMD
• best for automatic cross-session memory/user modeling: Honcho

My recommendation

For what you’re trying to build:

If you want the simplest solid setup

Use:

• workspace files
• MEMORY.md
• memory/
• builtin memory search

If you want stronger recall across lots of playbooks/docs

Use QMD

If you want more automatic “this agent builds a profile over time”

Use Honcho

---

How I would do it in OpenClaw

For each persistent specialist, I’d give them their own workspace like this:

sales-agent/
  AGENTS.md
  MEMORY.md
  memory/
  playbooks/
    outreach.md
    lead-research.md
  templates/
    cold-email.md
    reddit-comment.md

builder-agent/
  AGENTS.md
  MEMORY.md
  memory/
  playbooks/
    backend.md
    frontend.md
    security.md
  templates/
    api-patterns.md
    deployment-checklist.md

Then:

• persistent agent = owns the workspace + long-term memory

• subagent = gets spawned for one task
• after a good run, the persistent agent updates:
  • MEMORY.md, or
  • a playbook/template/checklist

That is how “improvement over time” actually works in practice.

Very important distinction

• Session context = temporary
• Workspace docs + MEMORY.md + memory/ = durable
• Memory search/QMD/Honcho = how you recall the durable stuff

So yes, OpenClaw can do what I’m describing.
You just have to store the learning in files/memory, not assume one long chat will hold it forever.

If I were choosing for you

• sales/content: persistent agent + QMD or Honcho
• mvp builder: persistent builder agent + playbooks, then subagents for per-project frontend/backend/test work

Docs:

• Memory overview: https://docs.openclaw.ai/concepts/memory
• Agent workspace: https://docs.openclaw.ai/concepts/agent-workspace
• QMD: https://docs.openclaw.ai/concepts/memory-qmd
• Honcho: https://docs.openclaw.ai/concepts/memory-honcho

If you want, next reply I can give you the exact folder structure + memory strategy I’d use for:

1. cold outreach
2. mvp builder
3. content creation

[placid aurora]

what do u think will be the difference if i make two agents researcher and one cold email writter and they can have sub agents idk what those will be also do we really need manager in this case and the other option is one manager and the nsub agetns what will eventually perform better for a product . also we need to send 30-40 emails per day is that huge or less and even if we are seinging 10 to 20 split in parts thrice a day how will that work like does the reseraching keep on finding saas founders and add to a litst and then email writter keep on picking them and wiriting for approval or i have to say do this or a cron will save make 5 emails and then they start working which one is better ?

[torn swift]

For one product and only 30 to 40 emails/day, I honestly think:

two fully separate long-lived agents + their own subagents is probably overkill at first.

What I’d do instead

Use 1 persistent outreach/orchestrator agent that owns:

• ICP
• offer
• approved claims
• lead queue
• dedupe rules
• approval flow

Then let it spawn helpers for:

• lead research
• enrichment/scoring
• draft writing
• maybe QA/review

So yes, that is basically a manager, but it does not need to be some fancy “boss persona”.
It is just the system owner.

Why I prefer that first

If you do:

• researcher agent
• writer agent
• both with subagents

then you now need somewhere to own:

• the source-of-truth lead list
• who is already contacted
• which leads are approved
• what writer should work on next
• retry/reject logic

So even if you say “no manager”, in practice you still need a coordinator somewhere.

Difference between the two setups

Option A, separate researcher + separate writer agents

Pros

• stronger role separation
• each can specialize over time
• cleaner prompts

Cons

• more handoff friction
• harder queue ownership
• more orchestration complexity
• easier to get duplicate work / stale context

Option B, one persistent outreach agent + worker subagents

Pros

• simpler
• one place owns the pipeline
• less coordination pain
• easier to debug
• usually better for one product / one campaign motion

Cons

• less “pure” specialization
• one orchestrator prompt can get heavier

For your volume, I’d start with Option B.

---

Is 30 to 40 emails/day huge?

From a system/orchestration perspective, no. That is not huge.

The hard part is not volume, it’s:

• quality
• targeting
• compliance
• human review
• keeping the queue clean

So I would optimize for workflow correctness, not throughput.

---

Continuous research vs cron batches

For your case, I would not do “researcher is always running nonstop”.

That is usually messy.

I’d do batched workflow:

1. research batch

   • find leads
   • enrich them
   • score them
   • add only good ones to queue

2. draft batch

• writer picks from approved queue
  • makes drafts

3. human approval

   • approve / reject / edit

4. send

   • only after approval

So yes, the clean design is:

• researcher fills a list/queue
• writer pulls from that queue
• human approves
• then send

That is much better than “just keep both agents running all day”.

---

Cron or manual trigger?

My recommendation:

Early stage

Manual or semi-manual

• “find 15 leads”
• “draft 5 emails for approval”

Why:

• you are still learning what “good” looks like

Once stable

Use cron for:

• filling the lead queue

• generating draft batches

But I would still keep:

• manual approval before public comments or email sends

Especially for Reddit comments and outreach, I would not make that fully autonomous.

---

The shape I’d use

Persistent top-level agent

outreach

Its subagents

• lead-research
• lead-enrichment

• email-draft
• qa-review

Data it owns

• lead queue
• contacted list
• rejected list
• approved draft queue
• playbooks/templates

So the orchestrator is the traffic cop, not a “thinker for everything”.

---

My blunt recommendation

For one product, start with:

• 1 persistent outreach agent
• subagents for research + draft writing
• queue-based workflow
• cron for batches later
• human approval before sending/posting

If later you have:

• multiple products
• multiple ICPs
• multiple channels
• much higher volume

then split into dedicated persistent researcher/writer agents.

If you want, I can sketch the exact OpenClaw workflow for this, like:

cron → research queue → draft queue → approval queue → send.

[placid aurora]

what if i have an orchestrator agent to the manage the reseacher and cold email writer and do rexearch and emai lwirter need sub agents to send email or search ?

[torn swift]

Yes, that can work, and it’s a much cleaner design.

But my strong recommendation is:

If you have an orchestrator, do not give every child more subagents by default

Start with:

• orchestrator
• researcher
• email writer
• optional reviewer

That’s enough.

Should researcher need subagents to search?

Usually, no at first.

Researcher can just use search/web tools directly.

Only add research subagents if later you truly need parallel work like:

• one worker for Reddit
• one worker for LinkedIn/company sites
• one worker for enrichment/scoring

At 30 to 40/day, I would not start there.

Should writer need subagents to send email?

Usually, no.

I would separate these jobs:

• writer = drafts the email
• reviewer/human = approves it
• sender = controlled final delivery step

I would not make “send” a big autonomous reasoning agent unless you really need one.

Sending is usually not an “intelligence” problem.
It is a workflow/approval problem.

So the clean version is

Orchestrator owns

• queue
• dedupe
• status
• batching
• approvals

Researcher owns

• find leads
• enrich
• score
• add to queue

Writer owns

• take approved leads
• draft personalized emails

Optional reviewer owns

• tone check
• policy/compliance check
• final approval prep

Sender

• just sends approved items

---

Why I like this better

Because if you do:

• orchestrator
• researcher
  • search subagent
• writer
  • send subagent

you quickly get too much nesting and too many handoffs.

Then you spend more time managing the system than getting useful output.

My rule of thumb

A role should get its own subagents only if it has:

1. multiple distinct internal tasks
2. enough volume to justify parallelization
3. clear benefit from splitting work

For your current use case, I don’t think researcher or writer need that yet.

What I would ship first

• 1 orchestrator
• 1 researcher
• 1 writer
• maybe 1 reviewer
• no deeper subagents yet

Then later, if research becomes the bottleneck, split researcher internally.

Important detail

If the orchestrator is already coordinating, then:

• search is a tool/task
• sending is a controlled action
• they do not automatically need to become their own agents/subagents

That’s the big simplification.

If you want, I can draw the exact workflow as:

orchestrator -> researcher -> queue -> writer -> approval -> send

[placid aurora]

how owuld i manage model and cost optimziation i nsucha setup ? also go back with content setup and mvp builder setup if we use orchestart with that ? what is bettter now ?

[torn swift]

Yeah, if you switch to an orchestrator-first design, I think the picture gets a lot clearer.

My current recommendation

1. Sales / outreach

Best now: orchestrator + workers

• orchestrator owns ICP, queue, approvals, dedupe
• research worker finds/enriches leads
• writer worker drafts emails
• optional review worker checks quality before approval
• send should stay a controlled final step, not a “thinking agent”

2. Content

Best now: orchestrator + workers

• content orchestrator owns brand voice, calendar, content pillars, sponsor rules

• research worker
• draft writer worker
• thumbnail worker
• sponsor outreach draft worker

This is usually better than many independent long-lived agents at first, because one place keeps the brand coherent.

3. MVP builder

Best now: orchestrator + workers, even more strongly

• builder/architect orchestrator owns stack defaults, standards, repo plan
• frontend worker
• backend worker
• QA/testing worker
• security/review worker

For MVP building, this is usually the cleanest pattern because each project is fresh.

---

Model and cost optimization

The big idea is:

Use the expensive/strong model only where judgment matters

Use the better model for:

• orchestrator
• final review
• hard architecture decisions
• hard editing/brand consistency passes

Use the cheaper model for:

• lead research
• enrichment

• first-draft writing
• repetitive transformations
• bulk classification/scoring

OpenClaw supports this pretty directly:

• main agent can use one model
• subagents can use a cheaper default via agents.defaults.subagents.model
• specific sessions can override later if needed

Docs:
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/concepts/models

Biggest cost mistakes people make

1. Using the strongest model for every worker
2. Keeping huge always-loaded prompts

3. Too many agent layers
4. Long messy sessions instead of fresh batch runs
5. Letting workers do high-cost reasoning for low-value tasks

Practical cost rules

Keep orchestrator count low

One orchestrator per system is usually enough.

Keep child workers dumb and narrow

A narrow worker is cheaper and more reliable.

Keep always-loaded files small

• small AGENTS.md
• small MEMORY.md
• bigger playbooks in separate files, read only when needed

That matters a lot for token cost.

Batch work

For your use cases, batches are cheaper than “always thinking” loops.

Use fresh worker sessions

Project workers should usually start fresh from the current brief instead of dragging long history around.

Watch spend

Use:

• /status
• /usage cost
• openclaw gateway usage-cost

Docs:
https://docs.openclaw.ai/reference/token-use
https://docs.openclaw.ai/reference/api-usage-costs

---

So what is better now?

For sales

Orchestrator + research/writer workers is better now.

For content

Orchestrator + research/writer/thumbnail workers is better now.

For MVP builder

Orchestrator + frontend/backend/test/security workers is definitely better now.

---

When I would split into more persistent specialist agents later

Only when you have:

• multiple products
• multiple brands
• very different ICPs
• much higher volume
• strong need for separate long-term role memory

Until then, orchestrator + workers is usually the better tradeoff.

If you want, I can give you a cost-optimized blueprint for all 3 systems, with:

• which role gets the stronger model
• which role gets the cheaper model
• which parts should be cron
• which parts should stay manual approval.

[placid aurora]

cna you think deeply and based on our discuion name out all the agents i will ahve and sub agents and which model should which one use

[torn swift]

Yeah, here’s the setup I’d actually recommend for you right now.

Model tiers first

Since exact model picks change fast, I’d think in tiers:

• Tier A = strongest, most reliable tool-using model you trust
• Tier B = solid mid-cost worker model
• Tier C = cheap batch model for repetitive/low-risk work
• IMG = your image model for thumbnails

For exact current picks, check:
https://docs.openclaw.ai/concepts/models
and ask in #models for fresh recommendations.

---

1. Sales / Outreach system

Persistent agent

outreach-orchestrator

Model: Tier A

Owns:

• ICP
• offer
• queue
• dedupe
• batch planning
• approval routing
• quality threshold

Subagents

lead-researcher

Model: Tier C or low Tier B
Finds candidate companies/founders/leads.

lead-enricher

Model: Tier C
Adds context, company details, use-case fit, score.

email-drafter

Model: Tier B
Writes first-pass personalized outreach drafts.

outreach-reviewer

Model: Tier A or high Tier B
Checks tone, accuracy, quality, and whether the draft is worth approving.

community-reply-drafter (optional)

Model: Tier B

Drafts public replies/comments only.
I would keep manual approval here.

Not an agent

sender

Not really a reasoning agent.
This should be a controlled delivery step after approval.

---

2. MVP Builder system

Persistent agent

builder-orchestrator

Model: Tier A

Owns:

• PRD/spec understanding
• architecture plan
• task breakdown
• repo strategy
• stack defaults
• integration sequencing
• “done means done”

Subagents

frontend-builder

Model: Tier B
Builds UI/features from scoped tickets.

backend-builder

Model: Tier B
Builds APIs, DB flows, auth, business logic.

integration-worker

Model: Tier B
Connects frontend/backend/external services.

qa-tester

Model: Tier C or low Tier B
Runs tests, finds failures, reports issues.

security-reviewer

Model: Tier A
Looks for auth/data/security mistakes.

code-reviewer

Model: Tier A or high Tier B
Checks maintainability, regressions, bad patterns.

docs-writer (optional)

Model: Tier C or low Tier B
Writes README, setup notes, handoff docs.

Why this structure

For MVP builder, I would not make frontend/backend long-lived top-level agents yet.
New MVPs change context too much.
A strong orchestrator plus scoped workers is the better tradeoff.

---

3. Content system

Persistent agent

content-orchestrator

Model: Tier A

Owns:

• brand voice
• content pillars
• topic priorities
• publishing plan
• sponsor rules
• final consistency

Subagents

topic-researcher

Model: Tier C or low Tier B
Finds ideas, references, trends, competitor angles.

outline-writer

Model: Tier C
Turns research into usable structure.

draft-writer

Model: Tier B
Writes the actual draft.

brand-editor

Model: Tier A or high Tier B
Fixes voice, consistency, positioning.

thumbnail-ideator

Model: Tier B
Comes up with thumbnail concepts, hook text, visual angle.

thumbnail-generator

Model: IMG
Image generation only.

sponsor-prospector

Model: Tier C

Finds sponsor candidates / partnership targets.

sponsor-email-drafter

Model: Tier B
Drafts sponsor outreach.

---

Final answer, what agents you should have

Persistent top-level agents

Just 3:

1. outreach-orchestrator
2. builder-orchestrator
3. content-orchestrator

Their subagents

Outreach

• lead-researcher
• lead-enricher
• email-drafter
• outreach-reviewer
• community-reply-drafter (optional)

Builder

• frontend-builder
• backend-builder
• integration-worker
• qa-tester
• security-reviewer
• code-reviewer
• docs-writer (optional)

Content

• topic-researcher
• outline-writer
• draft-writer
• brand-editor
• thumbnail-ideator
• thumbnail-generator
• sponsor-prospector
• sponsor-email-drafter

---

What model should each class use

Tier A

Use for:

• all orchestrators

• security review
• final review / brand review
• hard architecture / important judgment

Tier B

Use for:

• drafting
• frontend/backend implementation
• integration work
• thumbnail ideation
• sponsor email drafting

Tier C

Use for:

• research
• enrichment
• classification

• outlining
• batch QA passes
• prospecting

IMG

Use for:

• thumbnail generation only

---

My strongest opinion

If you try to make too many persistent specialist agents right now, you’ll overbuild the system.

Right now, the best setup is:

• few persistent brains

• many narrow temporary workers
• strong model for orchestration/review
• cheaper models for repetitive workers

That is the cleanest and most cost-efficient design.

If you want, I can do one more step and turn this into a real OpenClaw config plan, like:

• which ones should be separate agents
• which ones should be subagents
• which ones should be cron-driven
• where human approval should sit.

[placid aurora]

i thought you woudl make researcher and email drafter as seprate agents but you made all sub agents is this better than earlier thing ?

[torn swift]

Yeah, good catch. I did shift the recommendation a bit.

That is not because the earlier idea was wrong. It’s because after more context, I think the simpler version is better for your current stage.

Earlier idea

I was answering this question:

“If a role should improve over time, should it be a real agent?”

For that, the answer was basically yes, maybe.

Now, after your extra context

You told me:

• one product
• around 30 to 40 emails/day
• cost matters

• orchestration matters
• you want something practical, not overengineered

Given that, I think this is better right now:

• 1 persistent outreach orchestrator
• researcher as subagent
• email drafter as subagent
• maybe reviewer as subagent

So yes, for your current setup, I think this is better than making researcher + drafter separate full agents immediately.

---

Why I changed my mind

Because separate full agents give you:

Pros

• more specialization
• more durable role identity
• cleaner separation

Cons

• more coordination overhead
• more queue/handoff complexity
• more cost
• more places for state to get messy

For one product and moderate volume, that overhead is usually not worth it yet.

---

The real distinction

Better now

outreach-orchestrator + worker subagents

Best if:

• one product
• one ICP or a few close ICPs
• moderate daily volume
• still figuring out the workflow

Better later

separate persistent researcher-agent + writer-agent

Best if:

• stable process
• lots of repeated work
• multiple campaigns/channels
• enough volume that specialization really pays off
• you want each role to own its own memory/workspace

---

Important nuance

Making researcher/writer subagents does not mean you lose all learning.

Because the durable learning can still live in:

• orchestrator workspace
• MEMORY.md
• playbooks
• templates
• queue/history
• review notes

So the system can improve over time even if the workers are temporary.

That’s why I’m more comfortable recommending subagents for them right now.

---

My honest answer

For your current stage

Yes, I think:

persistent orchestrator + subagent researcher + subagent drafter

is better than:

persistent orchestrator + separate persistent researcher agent + separate persistent writer agent

For a later stage

If outreach becomes a real machine with lots of campaigns and repeated patterns, then I would probably promote researcher and writer into full agents.

So I’d call it:

• Phase 1: orchestrator + subagents
• Phase 2: specialized persistent agents if needed

That’s the clearest answer.

If you want, I can give you a phase 1 vs phase 2 architecture so you can see exactly when to upgrade from subagents to full agents.

[placid aurora]

you changed answer for all them you made even the content setup which you hsaid shoudk be seprate agetnas all sub agent go through aour conversation and think deeply and create the whole agent and sub agent and which model thing you did again

[torn swift]

You’re right, I was mixing phase 1 and phase 2, and that made the answer wobble.

So here is my final stable recommendation after the whole conversation.

Final rule

Because these are separate OpenClaw servers / separate systems, I would make:

• 1 persistent top-level agent per system
• subagents inside each system
• only later promote a worker into a full agent if it becomes a real long-lived specialty bottleneck

So the final shape is not “everything is a subagent”.

It is:

• Sales server: 1 main persistent agent + subagents

• MVP builder server: 1 main persistent agent + subagents
• Content server: 1 main persistent agent + subagents

That is the cleanest answer.

---

Model tiers

Use tiers, not hardcoded model names:

• Tier A = strongest, most reliable tool-using model
• Tier B = solid mid-cost worker model
• Tier C = cheap batch model
• IMG = image model

---

1. Sales / Outreach server

Persistent top-level agent

sales-orchestrator

Model: Tier A

Owns:

• product understanding
• ICP
• offer
• approved messaging rules
• lead queue
• dedupe
• approval flow
• send scheduling

Subagents

lead-researcher

Model: Tier C
Finds relevant founders/companies/leads.

lead-enricher

Model: Tier C
Adds company context, signals, fit score.

email-drafter

Model: Tier B
Writes outreach drafts.

outreach-reviewer

Model: Tier A or high Tier B
Checks quality, claims, tone, usefulness.

community-reply-drafter (optional)

Model: Tier B
Drafts public replies/comments only.
I would keep this under manual approval.

Not really an agent

sender

No strong model needed.
This should be a controlled delivery step after approval.

---

2. MVP Builder server

Persistent top-level agent

builder-orchestrator

Model: Tier A

Owns:

• requirements understanding
• architecture
• planning
• stack defaults
• task breakdown
• integration order
• final acceptance standard

Subagents

frontend-builder

Model: Tier B

backend-builder

Model: Tier B

integration-worker

Model: Tier B

qa-tester

Model: Tier C or low Tier B

security-reviewer

Model: Tier A

code-reviewer

Model: Tier A or high Tier B

docs-writer (optional)

Model: Tier C or low Tier B

---

3. Content server

Persistent top-level agent

content-orchestrator

Model: Tier A

Owns:

• brand voice
• topic strategy
• content calendar
• sponsor rules
• final consistency

Subagents

topic-researcher

Model: Tier C or low Tier B

outline-writer

Model: Tier C

draft-writer

Model: Tier B

brand-editor

Model: Tier A or high Tier B

thumbnail-ideator

Model: Tier B

thumbnail-generator

Model: IMG

sponsor-prospector

Model: Tier C

sponsor-email-drafter

Model: Tier B

---

Why this is my final answer

Because across the whole conversation, your constraints became:

• separate systems
• moderate scale, not huge scale
• cost matters
• you want something that actually ships
• you still want long-term improvement

The best compromise is:

Persistent memory/strategy lives in the main top-level agent

That is the orchestrator.

Execution lives in subagents

That keeps things cheaper and simpler.

---

When I would promote a subagent into a full separate agent

Only if all 3 become true:

1. it has a stable repeated role
2. it needs its own long-lived memory/workspace
3. it is creating enough value to justify extra coordination

So later you might promote:

• lead-researcher into a real agent
• draft-writer into a real content-writing agent

• backend-builder into a real persistent backend agent

But not on day 1.

---

Short final summary

Persistent agents

• sales-orchestrator → Tier A
• builder-orchestrator → Tier A
• content-orchestrator → Tier A

Subagents

Sales

• lead-researcher → Tier C
• lead-enricher → Tier C

• email-drafter → Tier B
• outreach-reviewer → Tier A / high B
• community-reply-drafter → Tier B

Builder

• frontend-builder → Tier B
• backend-builder → Tier B
• integration-worker → Tier B
• qa-tester → Tier C / low B
• security-reviewer → Tier A
• code-reviewer → Tier A / high B
• docs-writer → Tier C / low B

Content

• topic-researcher → Tier C / low B
• outline-writer → Tier C
• draft-writer → Tier B

• brand-editor → Tier A / high B
• thumbnail-ideator → Tier B
• thumbnail-generator → IMG
• sponsor-prospector → Tier C
• sponsor-email-drafter → Tier B

If you want, I can now turn this into a Phase 1 OpenClaw build plan, meaning:

• what files each server should have
• what cron jobs each orchestrator should run
• where approvals should sit.

[placid aurora]

but you said so that they imporve and since they for a isngle creator content researchers and writer shoudl be main agent not sub agent ?? earlier you said each arch would have multiple agents and then sub agents remeber these are on three differen openclaw server

[torn swift]

Yes, and this is the key nuance I should have said more clearly:

The 3 servers do not need to use the same architecture.

So, after thinking it through again:

Final answer

• Sales server → mostly 1 orchestrator + subagents
• MVP builder server → mostly 1 orchestrator + subagents
• Content server → this is the one where I would use multiple main agents

So your instinct was right for content.

---

Why content is different

For a single creator, the same things repeat over and over:

• same niche
• same audience
• same voice
• same brand
• same content style

That means:

• the researcher can genuinely improve over time
• the writer can genuinely improve over time

So on the content server, I would not make both of those just throwaway subagents.

I would make them real persistent agents.

---

Updated final architecture

1. Sales server

Main agent

• sales-orchestrator → Tier A

Subagents

• lead-researcher → Tier C
• lead-enricher → Tier C
• email-drafter → Tier B
• outreach-reviewer → Tier A / high B
• community-reply-drafter optional → Tier B

Why

Sales has more queueing, batching, approval, and changing lead context.

So orchestrator + workers is better.

---

2. MVP builder server

Main agent

• builder-orchestrator → Tier A

Subagents

• frontend-builder → Tier B
• backend-builder → Tier B
• integration-worker → Tier B
• qa-tester → Tier C / low B
• security-reviewer → Tier A
• code-reviewer → Tier A / high B
• docs-writer optional → Tier C / low B

Why

Each MVP is new.
Project context changes a lot.
Persistent role memory matters less than strong orchestration.

---

3. Content server

Main agents

• content-orchestrator → Tier A
• content-researcher → Tier B
• content-writer → Tier B

Subagents

• outline-writer → Tier C
• brand-editor → Tier A / high B
• thumbnail-ideator → Tier B

• thumbnail-generator → IMG
• sponsor-prospector → Tier C
• sponsor-email-drafter → Tier B

Why

This is the one system where role-specific long-term improvement is most valuable.

The researcher keeps learning:

• what topics work
• what sources are good
• what angles fit the creator

The writer keeps learning:

• voice
• pacing
• hooks
• tone

• formatting preferences

So yes, on the content server, I’d promote those two into real agents.

---

So the corrected final view is

Servers

Sales

• 1 main orchestrator
• rest subagents

MVP builder

• 1 main orchestrator
• rest subagents

Content

• 3 main agents
  • orchestrator
  • researcher
  • writer
• rest subagents

---

Why I changed

Because I was trying to force one universal pattern onto all 3 systems.

That was the mistake.

The better answer is:

• different systems can use different agent shapes
• content deserves more persistent specialization than the other two

So yes, your memory of the earlier logic was fair.
For content, I do think researcher + writer as main agents makes sense.

If you want, I can now give you the true final full list in one clean block, with no more changes:

• server by server
• main agents
• subagents
• model tier for each
• which ones should run on cron.

[placid aurora]

again even in mvp buidler we can haqve seprate agetns fron frontend and security and backend and frontend can ask security is this good or frontend can sask ocherator and ochertor tell security to verify and then tell forntned no chaneg it and long term memory it wil grow in skills ?

[torn swift]

Yes, you absolutely can do that for MVP builder.

And this is the cleaner way to think about it:

There are 2 valid builder architectures

Option 1, simpler

• builder-orchestrator
• frontend/backend/security as subagents

Option 2, more specialized

• builder-orchestrator
• frontend-agent
• backend-agent
• security-agent

Both are valid.

---

My real answer

If your MVPs use very different stacks each time

Use Option 1

Why:

• less coordination overhead
• less stale memory
• faster to ship

If your MVPs repeatedly use similar patterns

Use Option 2

Example:

• same auth style

• same DB style
• same deployment pattern
• same API conventions
• same React/Next frontend habits
• same security checklist

Then yes, persistent frontend/backend/security agents can become genuinely better over time.

So for builder, the deciding factor is not “can they improve?”

They can.

The deciding factor is:

Will the same reusable knowledge keep showing up across projects?

If yes, persistent specialist agents make sense.

---

How they should talk

I would still prefer:

• frontend asks orchestrator
• orchestrator sends to security
• security replies to orchestrator
• orchestrator sends decision back

So:

Better pattern

star topology

• orchestrator in the middle

Worse pattern

mesh topology

• frontend talks to backend
• backend talks to security
• security talks to QA
• everyone talks to everyone

That gets messy fast.

So yes, specialists can exist, but I’d still keep the orchestrator as the hub.

---

Where long-term improvement should live

Not mainly in “one long conversation”.

It should live in:

• MEMORY.md
• playbooks
• checklists
• starter repos
• templates
• design system docs
• security rules
• code review rubrics

And yes, also in the specialist agent’s workspace over time.

Important nuance

It does not “grow in skills” automatically.

Skills are more like:

• reusable procedures
• tool workflows
• packaged instructions

The long-term improvement usually grows more in:

• workspace docs
• memory files
• reusable codebases
• patterns the orchestrator and specialists keep refining

---

My refined builder recommendation

If you are early

Start with:

• builder-orchestrator

• subagent frontend-builder
• subagent backend-builder
• subagent security-reviewer
• subagent qa-tester

If you are building many similar SaaS MVPs

Promote these into real agents first:

• backend-agent
• security-agent

Maybe later:

• frontend-agent

Why those first?
Because backend and security usually have the most reusable standards.

---

Short answer

Yes, builder can also become a multi-agent specialist system.

I just would not start there unless:

• stack repeats
• patterns repeat
• volume is high enough
• you are okay with extra orchestration complexity

If you want, I can now give you the final architecture per server in phase 1 and phase 2, which will stop all this flip-flopping:

• sales, phase 1 / phase 2
• builder, phase 1 / phase 2
• content, phase 1 / phase 2

[placid aurora]

ok what about lead researcher and emai ldrafter don't they need to learn as they are working for the same product ?

[torn swift]

Yes, they do.

And this is why sales is the middle case.

My ranking is:

• Builder → least need for persistent specialist agents
• Sales → medium need
• Content → highest need

Because for sales, if it is the same product, then over time:

Lead researcher learns

• which founder profiles are good
• which company signals matter
• which channels are useful
• what “good fit” actually looks like

Email drafter learns

• which angles get replies
• which pain points resonate
• which tone works
• which personalization is worth doing
• what not to say

So yes, those two can absolutely justify becoming real persistent agents.

---

The real answer for sales

Early stage

If you are still figuring out:

• ICP
• offer

• messaging
• workflow

Then use:

• sales-orchestrator
• subagent lead-researcher
• subagent email-drafter

Later stage

If it becomes:

• same product
• same ICP
• same outreach motion
• repeated daily work
• clear quality feedback loop

Then I would promote them into full agents:

• sales-orchestrator
• lead-researcher-agent
• email-drafter-agent

And then maybe keep:

• lead-enricher
• reviewer
• sender-prep

as subagents / workflow steps.

---

So yes, your instinct is right

For a single product, lead researcher and email drafter are much more likely to deserve promotion into real agents than, say, frontend/backend workers for random new MVPs.

---

My cleanest final view now

Content

Most likely to use multiple real agents

Sales

Also can move to multiple real agents once stable

Builder

Usually stays orchestrator + subagents longer

---

If I had to be very concrete

Sales phase 1

• sales-orchestrator → Tier A
• lead-researcher subagent → Tier C
• email-drafter subagent → Tier B
• reviewer subagent → Tier A / high B

Sales phase 2

• sales-orchestrator → Tier A
• lead-researcher-agent → Tier B
• email-drafter-agent → Tier B
• reviewer subagent or agent → Tier A / high B

That’s probably the most honest answer.

So yes, for the same product, those roles do benefit from learning, and sales can evolve toward a real multi-agent specialist setup.

[placid aurora]

based on all our discussion and ifnal colusio nand the context you have about openclaw and my three different requirement . create a step by step easy detailed guide to create eerything i have openclaw installed but create the rest to have the msot effective and performant system and msot cost optimizzed at the same time . what plugins to install skils, aggents.md everything rpompt. give me all for all three based on the multi agent approach we though and also for mvp builder we will keep stack consistent as well . give me all steps end to end

[torn swift]

Yes. Here is the final end-to-end build guide I’d use for your 3-server setup, optimized for:

• good performance
• lower cost
• clean long-term memory
• room to grow into more specialization later

I’m making these assumptions:

1. You already have OpenClaw installed.
2. These are 3 separate OpenClaw servers.
3. You want multi-agent where it actually helps, not just for the sake of complexity.
4. You want human approval before public posting or outbound sending.
5. MVP builder uses a consistent stack.

---

0. High-level final architecture

Server 1, Sales

• Main agent: sales-orchestrator
• Subagents: lead researcher, lead enricher, email drafter, reviewer
• Why: best balance of cost + control for one product

Server 2, Builder

• Main agent: builder-orchestrator
• Subagents: frontend, backend, integration, QA, security, code review
• Why: projects change, orchestration matters more than persistent role memory

Server 3, Content

• Main agent: content-orchestrator
• Extra persistent agents: content-researcher, content-writer
• Subagents: outline, brand edit, thumbnail ideation, thumbnail generation, sponsor prospecting, sponsor email drafting
• Why: same creator, same niche, same voice, so researcher/writer really benefit from long-term memory

---

1. First, set up each server cleanly

Run this on each server first:

openclaw status
openclaw doctor
openclaw gateway status

If something looks off, fix that before building the agent architecture.

Then restart once before big config work:

openclaw gateway restart

---

2. Do not over-install plugins and skills on day 1

Plugins

For your phase 1 setup, I would install no extra plugins by default.

Why:

• lower complexity
• lower prompt/tool overhead
• fewer failure points

Optional later

Use Honcho only if you later decide builtin memory + playbooks are not enough.

Docs: https://docs.openclaw.ai/concepts/memory-honcho

Skills

Also keep skills minimal.

Every extra skill adds prompt overhead.

On day 1:

• install no extra skills unless a workflow truly needs them

Useful commands later:

openclaw skills list --eligible

openclaw skills check
openclaw skills search "gmail"
openclaw skills search "sheets"

If later you need Google Workspace, Sheets, or Gmail automation, add that skill then.
Do not start with a big skill pile.

---

3. Use this memory strategy on all 3 servers

OpenClaw’s native memory is file-based. That’s good for cost and control.

Keep these files in each main workspace

AGENTS.md
MEMORY.md
TOOLS.md
USER.md
IDENTITY.md
memory/
playbooks/
templates/
queues/
logs/

What each is for

• AGENTS.md = operating rules
• MEMORY.md = durable facts and preferences

• memory/YYYY-MM-DD.md = daily learnings
• playbooks/ = reusable procedures
• templates/ = email, content, checklist, prompt patterns
• queues/ = work waiting to be processed
• logs/ = sent, rejected, approved, archived

Very important cost rule

Keep AGENTS.md and MEMORY.md tight.

Do not dump everything into always-loaded files.

Put the larger stuff into:

• playbooks/*.md
• templates/*.md
• queues/*.csv or .md

Then have the agent read them only when needed.

---

4. Define 3 model aliases mentally

Do not hardcode your whole system around exact model names in this thread.

Instead create 3 internal categories:

• Tier A = strongest tool-reliable model
• Tier B = good worker model
• Tier C = cheap batch model
• IMG = image model for thumbnails

Then map agents like this:

Tier A

• orchestrators

• security review
• final review
• brand edit
• hard judgment

Tier B

• drafting
• frontend/backend implementation
• sponsor email drafting
• thumbnail ideation

Tier C

• lead research
• enrichment
• outlining
• batch QA
• prospecting

• repetitive classification

---

5. Cost optimization defaults

On all servers, follow these rules:

Rule 1

Use Tier A only for:

• main orchestrator
• final review
• security-critical decisions
• brand-critical decisions

Rule 2

Set workers/subagents to cheaper defaults.

Rule 3

Keep long-lived memory in files, not huge chat history.

Rule 4

Prefer batch jobs over “always running” loops.

Rule 5

Use human approval for:

• public comments
• outbound email sending
• sponsor outreach sending

Rule 6

Use prompt caching if your provider supports it.

Docs: https://docs.openclaw.ai/reference/prompt-caching

---

6. Server 1, Sales setup

Final shape

• one persistent agent
• no extra persistent specialist agents yet

Workspace structure

~/.openclaw/workspace/
  AGENTS.md
  MEMORY.md
  TOOLS.md
  USER.md

  playbooks/
    product.md
    icp.md
    outreach-rules.md
    qualification.md
  templates/
    cold-email.md
    community-reply.md
    review-checklist.md
  queues/
    raw-leads.csv
    qualified-leads.csv
    drafts-pending-approval.md
    approved-to-send.md
  logs/

    sent.csv
    rejected.csv
  memory/

Sales AGENTS.md

Use something like this:

# Sales Orchestrator

You are the sales orchestration agent for one product.

Your job:

- maintain a high-quality lead queue
- keep targeting aligned with the ICP
- generate personalized drafts for approval
- avoid duplicate work
- improve the workflow over time by updating playbooks and memory

Rules:
- Do not send outbound emails automatically without approval.
- Do not post public comments automatically without approval.
- Prefer batches over continuous loops.
- Use subagents for repetitive work: lead research, enrichment, draft writing, review.
- Keep MEMORY.md concise. Store larger reusable guidance in playbooks/.
- After a successful campaign or a failed one, write the reusable lesson into memory/ or playbooks/.
- Optimize for quality and relevance, not raw volume.

Subagent roles:
- lead researcher
- lead enricher
- email drafter
- outreach reviewer

Sales MEMORY.md

Start small:

# Sales Memory

## Product

- [one-paragraph product summary]

## ICP
- [ideal customer profile]
- [who is not a fit]

## Messaging
- approved claims:
- disallowed claims:
- preferred tone:

## Process
- every outbound draft requires approval before send
- every public/community draft requires approval before posting

How sales works

Manual phase first

You start by asking the orchestrator:

• find 20 leads
• enrich top 10
• draft 5 emails for approval

Later, add cron for batches

Do not cron the final send step.
Cron only:

• queue top-up
• enrichment batch
• draft generation batch

Use isolated/lightweight cron jobs when possible to reduce cost.

Docs: https://docs.openclaw.ai/cli/cron

---

7. Server 2, Builder setup

Because your stack will stay consistent, this system will get better over time from playbooks + templates + code standards, even if frontend/backend/security are subagents.

Final shape

• one persistent builder-orchestrator
• subagents for implementation and review

Workspace structure

~/.openclaw/workspace/

  AGENTS.md
  MEMORY.md
  TOOLS.md
  USER.md
  playbooks/
    stack.md
    architecture-rules.md
    security-checklist.md
    qa-checklist.md
    deployment.md
  templates/
    task-brief.md
    api-patterns.md
    pr-review.md
    done-definition.md

  memory/

Builder AGENTS.md

# Builder Orchestrator

You are the orchestrator for building MVPs on a consistent stack.

Your job:
- understand requirements
- break work into implementation tasks
- keep architecture consistent
- route work to frontend/backend/integration/test/security subagents

- require review before calling work done

Rules:
- The stack is intentionally consistent. Reuse patterns instead of reinventing.
- Keep reusable knowledge in playbooks/, templates/, and MEMORY.md.
- Use frontend/backend/integration workers for scoped execution.
- Use security and code review workers before final acceptance.
- Prefer orchestrator-as-hub communication. Do not create uncontrolled peer-to-peer loops.
- Promote lessons from each project into playbooks when they are reusable across future MVPs.

Builder MEMORY.md

# Builder Memory

## Stack defaults
- [your consistent stack]
- [auth pattern]
- [database pattern]
- [deployment target]
- [testing minimum]

## Reusable conventions
- [API style]
- [folder layout]
- [naming conventions]
- [security defaults]

Builder subagents and model tiers

• frontend-builder → Tier B
• backend-builder → Tier B
• integration-worker → Tier B
• qa-tester → Tier C or low B
• security-reviewer → Tier A
• code-reviewer → Tier A or high B

Important note

If after a while you keep using the same stack and see a lot of reusable backend/security knowledge, then later you can promote:

• backend-agent
• security-agent

into full persistent agents.

But do not start there unless the system is already stable.

---

8. Server 3, Content setup

This is the one where I would use multiple real agents.

Final shape

Persistent agents:

• content-orchestrator
• content-researcher
• content-writer

Subagents:

• outline writer
• brand editor
• thumbnail ideator
• thumbnail generator
• sponsor prospector
• sponsor email drafter

Create the extra agents

On the content server:

openclaw agents add researcher --workspace ~/.openclaw/workspace-researcher
openclaw agents add writer --workspace ~/.openclaw/workspace-writer

You do not need channel bindings for these if they are internal workers only.

Important config for agent-to-agent collaboration

If you want the content orchestrator to target the other persistent agents, configure:

{
  tools: {
    agentToAgent: {
      enabled: true,
      allow: ["researcher", "writer"]
    },
    sessions: {
      visibility: "all"
    }
  }
}

Docs:

• tools.agentToAgent: https://docs.openclaw.ai/gateway/configuration-reference#tools-agenttoagent
• tools.sessions: https://docs.openclaw.ai/gateway/configuration-reference#tools-sessions

Then restart:

openclaw gateway restart

Content orchestrator workspace

~/.openclaw/workspace/
  AGENTS.md
  MEMORY.md
  playbooks/
    brand.md
    content-pillars.md
    sponsor-rules.md

    publishing-rules.md
  templates/
    article-brief.md
    sponsor-email.md
  queues/
    topic-backlog.md
    drafts-in-review.md
    approved-content.md
  memory/

Content orchestrator AGENTS.md

# Content Orchestrator

You coordinate the content system for one creator.

Your job:
- maintain content strategy
- assign research and writing work
- preserve brand consistency
- manage sponsor workflow
- approve final direction before publishing

Rules:
- Researcher and writer are persistent specialist agents.
- Use them for long-lived learning in niche research and writing style.
- Use subagents for outline, editing, thumbnail ideation, sponsor prospecting, and drafting support.
- Keep the brand coherent across all outputs.

- Move reusable lessons into playbooks and memory.

Researcher agent AGENTS.md

# Content Researcher

You are the persistent research specialist for one creator.

Your job:
- find topics, references, trends, and angles that fit the creator's niche
- identify what is worth covering
- keep a strong sense of audience relevance
- improve over time by learning what sources, topics, and angles work best

Rules:
- prioritize signal over volume
- avoid weak or repetitive topic ideas
- capture reusable source and topic insights in memory and playbooks
- produce clean research handoffs for the writer

Writer agent AGENTS.md

# Content Writer

You are the persistent writing specialist for one creator.

Your job:
- turn approved research into strong drafts
- learn the creator's voice, pacing, hooks, and structure
- improve over time through feedback and revisions

Rules:
- optimize for clarity, strength of hook, audience fit, and creator voice
- do not drift into generic writing
- capture reusable writing lessons in memory and templates
- hand off drafts for brand edit before final approval

Content model tiers

• content-orchestrator → Tier A
• content-researcher → Tier B

• content-writer → Tier B
• outline-writer → Tier C
• brand-editor → Tier A or high B
• thumbnail-ideator → Tier B
• thumbnail-generator → IMG
• sponsor-prospector → Tier C
• sponsor-email-drafter → Tier B

---

9. Optional config pattern for model cost control

I would conceptually configure the systems like this:

• main default model = worker
• orchestrator-specific override = strong
• subagent default = cheap

• per-agent override for special cases

You can manage models through:

• agents.defaults.model.primary
• agents.list[].model
• agents.defaults.subagents.model

Docs:

• https://docs.openclaw.ai/concepts/models
• https://docs.openclaw.ai/tools/subagents

Also useful:

openclaw models status

---

10. Prompt and context hygiene

This matters a lot for cost.

Keep these small

• AGENTS.md
• MEMORY.md
• USER.md

Put detailed reference material here

• playbooks/
• templates/
• queues/

Good pattern

• keep rules small
• keep reusable knowledge structured

• read larger docs only when needed
• log only meaningful lessons

---

11. How I would actually roll this out

Week 1

Build only:

• sales orchestrator
• builder orchestrator
• content orchestrator
• content researcher
• content writer

Do not add cron yet except maybe one low-risk queue-topup job.

Week 2

Add:

• sales research/draft/review subagents
• builder frontend/backend/test/review subagents
• content outline/editor/thumbnail helpers

Week 3

Add batch cron jobs:

• sales queue top-up
• sales draft generation
• content topic backlog refresh
• sponsor prospecting backlog
• builder maintenance/checklist jobs if needed

Week 4

Review what is actually becoming specialized:

• if sales research/writing is clearly stabilizing, promote later

• if builder backend/security patterns are highly reusable, promote later
• if content is working, keep its current multi-agent shape

---

12. What I would not automate fully

I would not make these fully autonomous on day 1:

• public Reddit/community posting
• outbound email sending
• sponsor email sending

Have the system:

• research
• draft
• review

• queue
• ask for approval

That is the safer and more effective setup.

---

13. Simple final checklist

On every server

• [ ] run openclaw status
• [ ] run openclaw doctor
• [ ] create clean workspace structure
• [ ] keep memory file strategy consistent
• [ ] define Tier A / B / C model mapping
• [ ] keep skills/plugins minimal
• [ ] restart gateway after config changes

Sales

• [ ] create sales-orchestrator
• [ ] add playbooks, templates, queues
• [ ] use worker subagents for research/drafting/review
• [ ] keep final send manual approval

Builder

• [ ] create builder-orchestrator
• [ ] define your consistent stack in playbooks
• [ ] use frontend/backend/test/security/review subagents
• [ ] only later promote backend/security if clearly reusable

Content

• [ ] create content-orchestrator
• [ ] add researcher and writer as real agents
• [ ] enable tools.agentToAgent and tools.sessions.visibility: "all"
• [ ] restart gateway

• [ ] keep thumbnail/sponsor helpers as subagents

---

If you want, next I can give you copy-paste starter files for:

1. sales-orchestrator/AGENTS.md
2. builder-orchestrator/AGENTS.md
3. content-orchestrator/AGENTS.md
4. content-researcher/AGENTS.md
5. content-writer/AGENTS.md

That would make this immediately implementable.

[placid aurora]

yes give me that

[torn swift]

Yep. Here are copy-paste starter AGENTS.md files for the 5 core agents.

Replace the placeholders in [].

---

1. sales-orchestrator/AGENTS.md

# Sales Orchestrator

You are the main sales orchestration agent for one product.

## Mission
Run a high-quality outreach system for [PRODUCT NAME] aimed at [ICP].

Your job is to:
- maintain a clean lead queue
- keep targeting aligned with the ICP
- route work to research, enrichment, drafting, and review workers
- improve the system over time by updating memory and playbooks
- optimize for relevance and quality, not raw volume

## What success looks like
- leads are well qualified
- drafts are personalized and credible
- the queue stays deduplicated and organized
- the system gets better over time through structured learning
- outbound activity stays compliant and human-reviewed

## Core responsibilities

1. Understand the product and ICP deeply.
2. Keep the lead queue healthy and deduplicated.
3. Decide when to run:
   - lead research
   - lead enrichment
   - email drafting
   - review
4. Keep the system batched and efficient.
5. Promote reusable lessons into memory and playbooks.

## Hard rules
- Do not send outbound emails automatically without approval.
- Do not post public/community comments automatically without approval.
- Do not make unverifiable claims.
- Do not optimize for spammy volume.

- Prefer batched work over constant loops.
- Use subagents for repetitive work.
- Keep MEMORY.md concise. Put larger procedures into playbooks/.

## Subagents you may use
- lead researcher
- lead enricher
- email drafter
- outreach reviewer
- community reply drafter

## Decision policy
- If the queue is weak, improve lead quality before increasing volume.
- If messaging is weak, improve templates and positioning before drafting more.
- If a pattern repeats across campaigns, save it into playbooks or memory.

- If approval feedback keeps rejecting the same issue, update the system.

## Product context
Product: [PRODUCT NAME]
Short description: [ONE PARAGRAPH]
Primary ICP: [IDEAL CUSTOMER]
Not a fit: [WHO SHOULD NOT BE TARGETED]

## Tone
Be sharp, practical, concise, and commercially aware.
Avoid hype, generic sales fluff, and fake familiarity.

## Files to maintain
- MEMORY.md
- playbooks/product.md

- playbooks/icp.md
- playbooks/outreach-rules.md
- playbooks/qualification.md
- templates/cold-email.md
- templates/community-reply.md
- queues/raw-leads.csv
- queues/qualified-leads.csv
- queues/drafts-pending-approval.md
- logs/sent.csv
- logs/rejected.csv

---

2. builder-orchestrator/AGENTS.md

# Builder Orchestrator

You are the main orchestrator for building MVPs on a consistent stack.

## Mission
Turn product requirements into shipped MVPs using the standard stack, reusable patterns, and disciplined review.

## What success looks like
- requirements are translated into a clear build plan
- architecture stays consistent across projects
- implementation work is properly scoped
- security and review are not skipped
- reusable patterns are captured for future MVPs

## Core responsibilities

1. Understand the product requirement clearly.
2. Break the build into scoped workstreams.
3. Route work to:
   - frontend builder
   - backend builder
   - integration worker
   - QA tester
   - security reviewer
   - code reviewer
4. Keep the stack and conventions consistent.
5. Promote reusable lessons into memory and playbooks.

## Hard rules
- Do not invent a new stack when the standard stack already fits.
- Do not skip security review for auth, payments, storage, or user data.

- Do not call the MVP done without QA and review.
- Prefer orchestrator-as-hub communication over uncontrolled peer-to-peer loops.
- Keep reusable standards in playbooks and templates, not only in chat context.

## Standard stack
Stack: [YOUR STACK]
Auth: [AUTH PATTERN]
DB: [DATABASE]
Backend: [BACKEND FRAMEWORK]
Frontend: [FRONTEND FRAMEWORK]
Deployment: [DEPLOY TARGET]
Testing minimum: [TESTING BASELINE]

## Subagents you may use
- frontend builder

- backend builder
- integration worker
- QA tester
- security reviewer
- code reviewer
- docs writer

## Decision policy
- Reuse proven patterns before inventing new architecture.
- Use the strongest review on security-sensitive work.
- Keep tasks scoped enough that worker runs are clean and focused.
- If a pattern recurs across projects, add it to playbooks.

## Tone
Be technical, direct, organized, and pragmatic.

Optimize for shipping safely.

## Files to maintain
- MEMORY.md
- playbooks/stack.md
- playbooks/architecture-rules.md
- playbooks/security-checklist.md
- playbooks/qa-checklist.md
- playbooks/deployment.md
- templates/task-brief.md
- templates/api-patterns.md
- templates/pr-review.md
- templates/done-definition.md

---

3. content-orchestrator/AGENTS.md

# Content Orchestrator

You are the main orchestration agent for one creator's content system.

## Mission
Coordinate research, writing, editing, thumbnail ideation, and sponsor workflow while preserving the creator's niche, brand, and voice.

## What success looks like
- the content stays on-brand
- topics fit the audience and niche
- the researcher and writer keep improving over time
- sponsor outreach stays aligned with the brand
- output quality is more important than raw quantity

## Core responsibilities
1. Maintain the content strategy.
2. Keep the content calendar and topic backlog healthy.
3. Route work to:
   - content researcher
   - content writer
   - outline worker
   - brand editor
   - thumbnail ideator
   - thumbnail generator
   - sponsor prospector
   - sponsor email drafter
4. Preserve consistency across all outputs.
5. Save reusable lessons into memory and playbooks.

## Hard rules
- The researcher and writer are persistent specialist agents.
- Do not let output drift away from the creator's actual voice.
- Do not prioritize quantity over audience fit.
- Sponsor work must stay brand-safe.
- Keep AGENTS and MEMORY concise. Put larger doctrine into playbooks.

## Creator context
Creator: [CREATOR NAME]
Niche: [NICHE]
Audience: [AUDIENCE]
Main formats: [FORMATS]
Brand tone: [TONE]

## Persistent specialist agents
- content researcher
- content writer

## Subagents you may use
- outline writer
- brand editor
- thumbnail ideator
- thumbnail generator
- sponsor prospector
- sponsor email drafter

## Decision policy
- If topic quality is weak, improve research before writing more.
- If writing quality is weak, fix voice and structure before scaling volume.

- If thumbnails are weak, improve concept quality before generating more variants.
- If sponsor outreach feels off-brand, stop and tighten sponsor rules.

## Tone
Be strategic, editorial, audience-aware, and brand-protective.

## Files to maintain
- MEMORY.md
- playbooks/brand.md
- playbooks/content-pillars.md
- playbooks/sponsor-rules.md
- playbooks/publishing-rules.md
- templates/article-brief.md
- templates/sponsor-email.md
- queues/topic-backlog.md

- queues/drafts-in-review.md
- queues/approved-content.md

---

4. content-researcher/AGENTS.md

# Content Researcher

You are the persistent research specialist for one creator.

## Mission
Find strong, relevant, differentiated topics, references, and angles that fit the creator's niche and audience.

## What success looks like
- topic ideas are high signal
- sources are credible and useful
- angles are fresh and relevant
- research handoffs help the writer produce stronger drafts
- your sense of what works improves over time

## Core responsibilities
1. Identify topics worth covering.
2. Find sources, examples, trends, and references.
3. Distinguish strong ideas from weak, repetitive, or low-value ones.
4. Hand off structured research to the writer and orchestrator.
5. Capture durable lessons about audience resonance and source quality.

## Hard rules
- Prioritize signal over volume.
- Do not flood the backlog with weak ideas.
- Avoid shallow trend-chasing with no audience fit.
- Prefer useful research summaries over noisy raw dumps.
- Save reusable source and topic lessons into memory and playbooks.

## Research priorities
- audience pain points
- creator fit
- timeliness
- uniqueness
- depth
- evidence quality
- content potential

## Handoff quality bar
Every research handoff should answer:
- why this topic matters
- why this creator should cover it
- what angle is strongest
- what evidence/examples support it
- what the likely hook is

## Tone
Be curious, selective, skeptical, and editorially sharp.
You are not a content farm researcher.

## Files to maintain
- MEMORY.md

- playbooks/source-quality.md
- playbooks/topic-selection.md
- playbooks/audience-patterns.md
- memory/YYYY-MM-DD.md

---

5. content-writer/AGENTS.md

# Content Writer

You are the persistent writing specialist for one creator.

## Mission
Turn strong research into strong drafts that match the creator's voice, pacing, tone, and audience expectations.

## What success looks like
- writing feels like the creator, not generic AI output
- hooks are strong
- structure is clear
- arguments are sharp
- the draft is useful and readable
- you improve over time through feedback

## Core responsibilities
1. Turn approved research into drafts.
2. Preserve and refine the creator's voice.
3. Use structure, hooks, pacing, and clarity intentionally.

4. Hand drafts off cleanly for brand edit and final approval.
5. Save reusable writing lessons into memory and templates.

## Hard rules
- Do not sound generic.
- Do not drift into fake authority or inflated claims.
- Do not overwrite the creator's natural voice with bland polish.
- Prefer clarity, strength, and specificity over filler.
- If the research is weak, flag it instead of forcing a draft.

## Writing priorities
- hook strength
- clarity
- audience fit
- creator voice

- structure
- specificity
- usefulness

## Draft quality bar
A good draft should have:
- a clear opening hook
- a logical flow
- concrete examples or evidence where needed
- strong transitions
- a satisfying ending or takeaway

## Tone
Write like a sharp human creator with a point of view.
Avoid corporate filler and obvious AI phrasing.

## Files to maintain
- MEMORY.md
- playbooks/voice-guide.md
- playbooks/hook-patterns.md
- playbooks/structure-patterns.md
- templates/draft-structure.md
- memory/YYYY-MM-DD.md

---

Tiny next step after pasting these

For each workspace, also create a small starter MEMORY.md with:

# Memory

## Durable facts
- [main niche / product / stack / audience]
- [main tone rules]
- [approval rules]
- [important do-not-do rules]

---

If you want, next I can give you the starter MEMORY.md + playbooks/ files for all 3 systems too.

[placid aurora]

yes

[torn swift]

Nice. Here are the starter MEMORY.md and playbook files I’d use.

Paste them in as-is, then replace the placeholders.

---

1. Sales server

MEMORY.md

# Sales Memory

## Product
- Product name: [PRODUCT NAME]
- One-line description: [ONE SENTENCE]

- Core outcome for customers: [MAIN OUTCOME]
- Main pain points solved:
  - [PAIN 1]
  - [PAIN 2]
  - [PAIN 3]

## ICP
- Primary ICP: [WHO]
- Best-fit company traits:
  - [TRAIT 1]
  - [TRAIT 2]
  - [TRAIT 3]
- Worst-fit company traits:
  - [BAD FIT 1]
  - [BAD FIT 2]

## Messaging rules
- Preferred tone: [TONE]
- Avoid: hype, fake familiarity, unverifiable claims
- Must be specific and relevant
- Personalization should feel earned, not fake

## Workflow rules
- Public comments require approval before posting
- Outbound emails require approval before sending
- Quality beats volume
- Repeated lessons should be moved into playbooks

playbooks/product.md

# Product Playbook

## Product summary
[WRITE A CLEAR PARAGRAPH]

## What it does
- [CAPABILITY 1]
- [CAPABILITY 2]
- [CAPABILITY 3]

## What makes it valuable
- [VALUE 1]
- [VALUE 2]
- [VALUE 3]

## What not to imply
- [CLAIM TO AVOID]
- [CLAIM TO AVOID]
- [CLAIM TO AVOID]

playbooks/icp.md

# ICP Playbook

## Best fit
- title / role: [ROLES]
- company type: [TYPE]
- company size: [SIZE]

- signals:
  - [SIGNAL 1]
  - [SIGNAL 2]
  - [SIGNAL 3]

## Weak fit
- [WEAK FIT 1]
- [WEAK FIT 2]

## Bad fit
- [BAD FIT 1]
- [BAD FIT 2]

## Qualification questions
1. Does this person/company clearly have the problem?

2. Is the timing plausible?
3. Is the company in the right stage?
4. Is there enough signal for a personalized message?

playbooks/outreach-rules.md

# Outreach Rules

## Quality standard
A lead is only worth drafting if:
- the fit is real
- the pain is plausible
- the message can be personalized honestly

## Drafting rules
- Open with a relevant observation, not generic flattery
- State the pain clearly
- Connect the product naturally
- Keep it concise
- End with a simple CTA

## Hard bans
- no fake compliments
- no made-up facts
- no aggressive urgency
- no fake social proof
- no autonomous sending without approval

playbooks/qualification.md

# Qualification Playbook

## Lead scoring
### Strong fit
- clear problem
- strong signal
- obvious use case
- personalization available

### Medium fit
- possible problem
- some signal
- weak personalization

### Reject
- vague fit
- no evidence
- low leverage
- likely spammy outreach

templates/cold-email.md

# Cold Email Template

Subject: [SHORT SPECIFIC SUBJECT]

Hi [NAME],

I noticed [REAL OBSERVATION].

It made me think you might be dealing with [PAIN / OPPORTUNITY].

[PRODUCT NAME] helps with [CLEAR OUTCOME], especially for [TYPE OF CUSTOMER].

If helpful, I can send a short note on how this could apply to [COMPANY].

Best,
[NAME]

---

2. Builder server

MEMORY.md

# Builder Memory

## Standard stack
- Frontend: [FRONTEND]
- Backend: [BACKEND]
- Database: [DB]
- Auth: [AUTH]
- Deployment: [DEPLOYMENT]
- Payments: [PAYMENTS]
- Email: [EMAIL]

## Default build principles
- keep architecture simple
- reuse stack defaults
- ship the smallest complete version first
- review security-sensitive areas
- do not skip testing basics

## Engineering rules
- do not invent new patterns without reason
- prefer existing templates and playbooks
- security review is required for auth, payments, storage, and user data

playbooks/stack.md

# Stack Playbook

## Official stack
- frontend: [STACK]
- backend: [STACK]
- db: [STACK]
- auth: [STACK]
- deployment: [STACK]

## Why this stack
[SHORT EXPLANATION]

## Default services
- auth: [SERVICE]
- db: [SERVICE]

- storage: [SERVICE]
- analytics: [SERVICE]
- email: [SERVICE]

playbooks/architecture-rules.md

# Architecture Rules

## Principles
- start simple
- optimize for maintainability
- avoid premature abstraction
- keep boundaries clear

- prefer explicitness over cleverness

## Default structure
- frontend owns UI concerns
- backend owns business logic
- shared types only when justified
- integrations are isolated behind clear interfaces

## Do not
- mix business logic into UI
- hide critical flows behind magic
- create needless microservices for MVPs

playbooks/security-checklist.md

# Security Checklist

## Always review
- auth flows
- password / token handling
- authorization checks
- file upload paths
- user data access
- secrets usage
- payment flows
- admin actions

## Questions
1. Can a user access another user's data?
2. Are auth checks enforced server-side?

3. Are secrets exposed to the client?
4. Are uploads validated?
5. Are admin-only actions protected?

playbooks/qa-checklist.md

# QA Checklist

## Minimum QA
- happy path works
- auth works
- basic validation works
- core CRUD works

- major regressions checked
- mobile sanity check
- error states are acceptable

## Done definition
- implementation works
- no obvious security issue
- no blocking bug
- review completed
- docs or handoff notes updated

templates/task-brief.md

# Task Brief

## Goal
[WHAT NEEDS TO BE DONE]

## Context
[WHY IT MATTERS]

## Constraints
- use standard stack
- keep scope tight
- do not break existing patterns

## Acceptance criteria
- [CRITERION 1]

- [CRITERION 2]
- [CRITERION 3]

---

3. Content server, orchestrator

MEMORY.md

# Content Memory

## Creator
- Creator name: [NAME]

- Niche: [NICHE]
- Audience: [AUDIENCE]
- Main formats: [FORMATS]

## Brand
- Tone: [TONE]
- Style traits:
  - [TRAIT 1]
  - [TRAIT 2]
  - [TRAIT 3]

## Content rules
- value first
- avoid generic filler
- strong hook required

- must fit creator voice
- weak ideas should be rejected early

## Sponsor rules
- sponsor outreach must stay on-brand
- bad-fit sponsors should be rejected
- no desperate tone

playbooks/brand.md

# Brand Playbook

## Voice

[DESCRIBE THE CREATOR'S VOICE]

## Must feel like
- [QUALITY 1]
- [QUALITY 2]
- [QUALITY 3]

## Must not feel like
- [ANTI-QUALITY 1]
- [ANTI-QUALITY 2]
- [ANTI-QUALITY 3]

## Style notes
- hooks should be [STYLE]
- structure should be [STYLE]

- examples should be [STYLE]

playbooks/content-pillars.md

# Content Pillars

## Pillar 1
- name: [PILLAR]
- why it matters:
- examples:

## Pillar 2
- name: [PILLAR]

- why it matters:
- examples:

## Pillar 3
- name: [PILLAR]
- why it matters:
- examples:

playbooks/sponsor-rules.md

# Sponsor Rules

## Good sponsor fit

- aligns with audience
- aligns with creator values
- feels natural in content
- solves a real audience problem

## Bad sponsor fit
- obvious mismatch
- low-trust or sketchy offer
- too salesy
- would damage creator credibility

## Outreach rules
- concise
- confident
- creator-fit first

- no begging
- no fake enthusiasm

---

4. Content researcher agent

MEMORY.md

# Researcher Memory

## Audience learnings
- [WHAT TOPICS RESONATE]

- [WHAT TOPICS FAIL]
- [WHAT ANGLES WORK]

## Source learnings
- best source types:
- weak source types:
- recurring patterns worth tracking:

## Research rules
- signal over noise
- originality matters
- creator fit matters more than raw trendiness

playbooks/source-quality.md

# Source Quality Playbook

## Good sources
- firsthand experience
- primary data
- credible expert writing
- real examples with evidence

## Weak sources
- vague reposted summaries
- contextless hot takes
- recycled trend spam
- unsupported claims

playbooks/topic-selection.md

# Topic Selection Playbook

## A strong topic has
- audience relevance
- creator fit
- a clear angle
- enough evidence or examples
- a compelling hook

## Reject topics that are
- repetitive
- too broad
- too weakly evidenced
- trendy but empty

---

5. Content writer agent

MEMORY.md

# Writer Memory

## Voice learnings
- what makes the writing sound like the creator:
- what kills the voice:
- preferred rhythm / pacing:
- preferred hook style:

## Draft rules

- clarity over fluff
- specificity over abstraction
- strong opening
- clear structure
- satisfying ending

playbooks/voice-guide.md

# Voice Guide

## The writing should feel
- [QUALITY 1]
- [QUALITY 2]

- [QUALITY 3]

## The writing should not feel
- [ANTI-QUALITY 1]
- [ANTI-QUALITY 2]
- [ANTI-QUALITY 3]

## Sentence style
- [SHORT / LONG / MIXED]
- [DIRECT / REFLECTIVE / PUNCHY]

playbooks/hook-patterns.md

# Hook Patterns

## Hooks that work
- sharp observation
- surprising contrast
- blunt truth
- strong question
- concrete pain point

## Hooks to avoid
- generic inspiration
- weak setup
- vague promise
- empty curiosity bait

playbooks/structure-patterns.md

# Structure Patterns

## Default structure
1. hook
2. framing
3. main point
4. examples / evidence
5. takeaway

## Alternative structures
- problem -> insight -> example -> takeaway
- myth -> reality -> explanation -> takeaway
- observation -> breakdown -> action

---

Best next move

Do this in order:

1. paste the AGENTS.md files
2. paste these MEMORY.md + playbooks
3. replace placeholders
4. run a few manual tasks before adding cron
5. only then automate batches

If you want, next I can give you the exact folder tree + command sequence to create all these files fast on each server.

[placid aurora]

so now you understand all my needs and what i actually am working on can you tell me what all plugins, tools and skills i owuld need for all this . also how do igure out they are safe i heard most of them have virus and malware

[torn swift]

Short answer, for the setup you described, you need far fewer plugins/skills than you think.

What I would use right now

Core only, for all 3 systems

You already get most of this built in:

• sessions_spawn, sessions_send, sessions_history, sessions_list, subagents
• read, write, edit
• exec, process
• web_search, web_fetch
• browser
• message
• cron
• image_generate for thumbnails
• memory-core for memory/search
• bundled browser plugin

For your phase 1 setup, that is honestly enough.

---

What each server actually needs

1. Sales server

Needed

• sessions/subagents tools
• web tools
• browser
• cron
• memory-core
• file tools

Not needed yet

• extra plugins

• lots of skills
• autonomous sending plugins

Optional later

• some spreadsheet/CRM integration skill
• maybe Gmail/Google Workspace style skill if you really need that workflow

But I would not start there.

---

2. Builder server

Needed

• sessions/subagents tools
• read/write/edit
• exec/process
• browser

• memory-core

Not needed yet

• extra plugins
• lots of skills

This one is mostly core OpenClaw already.

---

3. Content server

Needed

• sessions/subagents tools
• web tools
• file tools
• memory-core
• image_generate

Optional later

• stronger long-term memory plugin if content history becomes huge
• external spreadsheet/storage integration if your backlog outgrows files

---

Plugins I would actually consider

Default recommendation

Install none at first

That is the real answer.

OpenClaw core already covers most of your architecture.

Optional later

memory-lancedb

Only if builtin memory becomes too weak for your recall needs.

Honcho

Only if you specifically want AI-native cross-session memory and are okay with extra complexity.

Docs:

• Memory overview: https://docs.openclaw.ai/concepts/memory
• Plugins: https://docs.openclaw.ai/tools/plugin

---

Skills I would actually consider

Default recommendation

Install none at first

Why:

• every skill adds prompt overhead
• every extra dependency adds risk
• most of your work can be done with built-in tools

Optional later

Only add a skill if you have a very specific need like:

• Google Sheets / Gmail / Docs
• a trusted in-house workflow
• a very narrow external integration

Useful commands:

openclaw skills list --eligible
openclaw skills check
openclaw skills info <name>
openclaw skills search "<query>"

Docs:

• Skills CLI: https://docs.openclaw.ai/cli/skills
• Skills system: https://docs.openclaw.ai/tools/skills

---

Are plugins/skills safe?

Honest answer

Not automatically.

Your concern is valid.

Plugins

Plugins run in-process with the gateway.
That means they are basically trusted code once installed.

So yes, a bad plugin can be dangerous.

Skills

Skills are usually less invasive than plugins, but they can still:

• add risky instructions
• depend on external binaries
• trigger tool actions you did not intend

So you should treat both carefully.

---

What OpenClaw does for safety

According to the docs:

• OpenClaw runs a dangerous-code scan before plugin install/update

• critical findings block by default
• plugin install/update should still be treated like running untrusted code
• plugin installs can execute npm lifecycle behavior during install flow
• --dangerously-force-unsafe-install is break-glass only

Docs:

• Plugin safety: https://docs.openclaw.ai/gateway/security
• Plugins CLI: https://docs.openclaw.ai/cli/plugins

So the scanner helps, but it is not a guarantee.

---

My safety policy for you

Safest path

1. Prefer bundled/core features first

If core OpenClaw can do it, use that.

2. Prefer zero third-party plugins in phase 1

Especially for sales automation.

3. Prefer zero extra skills until a real pain point appears

4. If installing a plugin, pin the exact version

Do not install vague “latest” stuff if you can avoid it.

5. Inspect before enabling

Use:

openclaw plugins list
openclaw plugins info <id>

openclaw plugins inspect <id>
openclaw plugins doctor

6. Never use --dangerously-force-unsafe-install unless you fully understand why

7. Use allowlists

Only allow plugins you explicitly trust.

8. Restart after plugin changes

openclaw gateway restart

9. For skills, inspect them first

Use:

openclaw skills info <name>
openclaw skills check

10. If a plugin/skill is from a random source, test it on a disposable machine first

---

My concrete recommendation

Use this now

Plugins

• bundled defaults only
• browser
• memory-core

Skills

• none

Tools

• built-in tools only

That gives you the safest and most cost-efficient starting point.

---

If I were you, I would only add things in this order

First

Core OpenClaw only

Second

Maybe one trusted memory upgrade if you outgrow builtin memory

Third

Maybe one spreadsheet/email integration if you truly need it

Last

Any random community plugin you found online

---

Very blunt answer

If someone told you “install a bunch of plugins and skills for this”, I think that’s the wrong move.

For your three systems, the best setup is mostly core OpenClaw, not a plugin zoo.

If you want, I can now give you a safe install checklist, meaning exactly:

• what commands to run before trusting a plugin

• what red flags to look for
• when to reject a plugin/skill outright.

[placid aurora]

what abotu gmail integration , google sheet and github have you already added that ? also is there no website where we can see skills are safe or not or can we run through ai or make a command that throughly check plugins and skill and tool code would that be helpful ?

[torn swift]

Yeah, for Gmail + Google Sheets, I’d add that, but only to the servers that actually need it.

What I’d add now

Sales server

Yes, Gmail + Sheets make sense here.

Use the Google Workspace skill/tooling, not a random plugin zoo.

From the skill docs, the right integration is gog for:

• Gmail
• Sheets
• Docs
• Drive
• Contacts

That is a good fit for:

• lead queue in Sheets
• approval queue in Sheets
• sending approved emails via Gmail

Content server

Maybe yes
Only if you want:

• sponsor pipeline in Sheets
• sponsor outreach via Gmail
• content calendar in Sheets

Builder server

Probably no Gmail/Sheets
For builder, I would not add Google integrations unless you actually manage roadmap/tasks there.

---

What about GitHub?

Builder server

Yes, this is the one place where GitHub matters

But I still would not rush into a GitHub plugin unless you truly need GitHub API actions.

At first, builder can often work fine with:

• repo access
• file tools
• exec/process
• browser if needed

If later you need:

• issue creation
• PR workflow
• repo metadata

• comments/status handling

then add a trusted GitHub integration on the builder server only.

So:

• Sales: Gmail + Sheets yes
• Content: Gmail + Sheets maybe
• Builder: GitHub maybe, Google stuff usually no

---

Did I already include that in the earlier setup?

Not in the baseline.

That was intentional.

Why:

• it keeps phase 1 simpler
• lower risk
• fewer moving parts
• fewer tokens / less prompt overhead

The baseline was:

• core OpenClaw first
• add integrations only when the workflow is stable

---

Is there a website that tells you if skills/plugins are safe?

Honest answer

Not one I would trust blindly.

Discovery sites can help you find skills/plugins.
They do not remove the need for review.

So I would treat:

• ClawHub / marketplaces = discovery
• your own review = trust decision

---

Would an AI/code audit command be helpful?

Yes, absolutely

That would be useful.

But:

• useful does not mean sufficient
• AI review should be a second layer, not your only trust layer

So the answer is:
yes, build/use it, but do not trust it alone

---

Best safety workflow for plugins/skills

For plugins

Treat them like untrusted code.

Before install

• trust the source?
• exact version pinned?
• package/owner looks legit?
• really needed?

After install, before enable

Use:

openclaw plugins list
openclaw plugins info <id>
openclaw plugins inspect <id>
openclaw plugins doctor

And remember from the docs:

• OpenClaw does a dangerous-code scan
• critical findings block by default
• that is helpful, not a guarantee

For skills

Use:

openclaw skills list --eligible
openclaw skills info <name>
openclaw skills check

Then inspect:

• SKILL.md
• required binaries
• what commands it shells out to
• what accounts/tokens it needs

---

What your AI/code audit should look for

If you build a “thorough check” command/script, make it scan for:

• postinstall, preinstall, install hooks
• child_process, shell execution
• curl, wget, remote downloads
• eval, Function, obfuscation
• filesystem writes outside expected dirs
• env var harvesting
• credential access
• network calls to weird domains
• telemetry you did not expect
• dangerous binary dependencies

And then also run an AI review over:

• plugin manifest
• README / SKILL.md
• install scripts
• main entrypoints
• dependency tree

That would be a good idea.

Just don’t confuse “no AI warning” with “safe”.

---

My practical recommendation for you

Add now

Sales

• gog style Google Workspace integration for Gmail + Sheets

Content

• same only if sponsor workflow actually needs it

Builder

• no Google integration

• GitHub only when you truly need repo API workflow

Keep safe

• use exact versions
• inspect before enabling
• prefer core tools first
• do not install random community packages casually
• test new integrations on a throwaway server first

---

My blunt opinion

For your setup, the first external integration I would trust/use is Google Workspace via gog.

That one makes sense.