I create some agent from the main agent, but now i wonder how i should orchestrate those agents. | Friends of the Crustacean 🦞🤝 | Page 1

gentle zealot Apr 17, 2026, 5:17 PM

#

I create some agent from the main agent, but now i wonder how i should orchestrate those agents. Do i chat from the main agent to tell him to delegate the task to the other agent or what? i am confused. Note i have only telegram channel and i mostly use the Ui interface to interact with my claw.

Advise please

candid lintelBOT Apr 17, 2026, 5:17 PM

#

tired kindleBOT Apr 17, 2026, 5:17 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

candid lintelBOT Apr 17, 2026, 5:17 PM

#

modern plazaBOT Apr 17, 2026, 5:19 PM

#

Short version: yes, usually main should be the coordinator.

The key thing is that there are 2 different concepts:

Agents you created = separate brains/workspaces/profiles
Sub-agents / delegated runs = temporary work started by another agent

So the usual pattern is:

Talk to main for normal use
Let main delegate specialized or long-running work
Talk directly to a specialist agent only when you want an ongoing dedicated conversation with that specialist

For your setup, UI + Telegram, I’d recommend this simple model:

main = front door / orchestrator
specialist agents = coding, research, ops, etc.

#

If you know exactly who should handle it, open that agent directly in the UI
Otherwise just tell main something like:
“Delegate this to the research agent and give me the summary back.”

One important gotcha: cross-agent delegation is not automatic.
By default, sessions_spawn only targets the same agent unless you allow others with:

subagents.allowAgents
optionally subagents.requireAgentId: true for more predictable delegation

Also, for Telegram, I would keep orchestration simple at first:

either one main Telegram bot that delegates behind the scenes
or separate Telegram bots/accounts per top-level agent if you want to talk to each directly

Rule of thumb:

Direct chat with specialist = ongoing role/personality

#

Delegate from main = temporary task/workflow

Docs:

If you want, paste your agents + bindings config and I’ll tell you the best orchestration pattern for your exact setup.

gentle zealot Apr 17, 2026, 5:27 PM

#

sessions_spawn and subagents.requireAgentId? how to set this? dont tell me confused things. i want to know wher ethose setting is on my .openclaw folder?

anyway, those 2 agents were already created. and have the main agent . so 3 agents in total. now what? i told the main agent to give agent 1 a heartbeat that wake up 10min, will that work and wake up each 10min to do its work by default or not?

modern plazaBOT Apr 17, 2026, 5:28 PM

#

Clear version:

1) Where those settings live

Main config file:

~/.openclaw/openclaw.json

That is where you set things like:

subagents.requireAgentId
subagents.allowAgents
per-agent heartbeat

Agent workspace files are separate, usually here:

#

~/.openclaw/workspace-main/
~/.openclaw/workspace-agent1/
~/.openclaw/workspace-agent2/

If you want heartbeat instructions for agent1, put them in:

~/.openclaw/workspace-agent1/HEARTBEAT.md

Unless you changed the workspace path manually.

2) Important correction

#

sessions_spawn is not a config setting in a file.

It is a tool/action the agent uses at runtime to spawn another agent run.

The config setting is this one:

subagents.requireAgentId
and usually also subagents.allowAgents

3) What to put in `~/.openclaw/openclaw.json`

Example:

#

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        subagents: {
          allowAgents: ["agent1", "agent2"],
          requireAgentId: true
        }
      },
      {
        id: "agent1",
        heartbeat: {
          every: "10m",

#

          target: "none"
        }
      },
      {
        id: "agent2"
      }
    ]
  }
}

What this does:

main is allowed to delegate to agent1 and agent2
main must choose explicitly which agent to use
agent1 gets a heartbeat every 10 minutes

#

target: "none" means heartbeat runs silently unless you change delivery

4) Will “I told main agent to give agent1 a 10 min heartbeat” work by default?

No, not by default.

That only works if the agent actually edited the config and/or agent1’s HEARTBEAT.md.

Just telling it in chat does not magically create a permanent scheduler.

For agent1 to wake every 10 minutes, you need:

agent1.heartbeat.every: "10m" in ~/.openclaw/openclaw.json
optional instructions in ~/.openclaw/workspace-agent1/HEARTBEAT.md
restart the gateway after config changes

#

5) One more important thing

Heartbeat is for periodic checking, not perfect exact scheduling.

If you need:

“check things regularly” → heartbeat
“run exactly every 10 minutes and do this exact job” → cron is better

Docs:

#

If you paste your current ~/.openclaw/openclaw.json, I can tell you exactly what to add and where.

gentle zealot Apr 17, 2026, 5:35 PM

#

but i do have the heartbeat like below:
"Core Files
Bootstrap persona, identity, and tool guidance.
Refresh
Workspace: /home/openclaw/.openclaw/workspace-prospector
AGENTS
SOUL
TOOLS
IDENTITY
USER
HEARTBEAT
BOOTSTRAP missing
MEMORY
/home/openclaw/.openclaw/workspace-prospector/HEARTBEAT.md"

HEARTBEAT.md - Prospector

Wake-up every 10 minutes and do the following:

bla bla

But still it never get trigger, strange. does it need to be configured via cron job or what?

also in .openclaw/openclaw.json, there is no such settings:
"subagents.requireAgentId
subagents.allowAgents
per-agent heartbeat
"

modern plazaBOT Apr 17, 2026, 5:36 PM

#

Yep, this is the missing piece:

HEARTBEAT.md does not schedule anything by itself.
It is only the instructions for a heartbeat run.

So this line in your file:

“Wake-up every 10 minutes…”

is just text for the model. It does not create the 10 minute timer.

What you actually need

You must add a heartbeat config in:

#

~/.openclaw/openclaw.json

For example, for prospector:

{
  agents: {
    list: [
      { id: "main", default: true },
      {
        id: "prospector",
        heartbeat: {
          every: "10m",
          target: "last"

#

Meaning

every: "10m" = real scheduler
target: "last" = send heartbeat output to the last chat/contact
if you use target: "none", it may run silently

Why you don’t see those keys now

#

Because they are optional config keys.

OpenClaw does not write every possible default into openclaw.json.
If a key is missing, that just means “using default behavior”, not “feature does not exist”.

So yes, you add these manually.

Your case, specifically

If prospector is a non-default agent, I would add it explicitly like this:

{
  agents: {

#

    list: [
      {
        id: "main",
        default: true,
        subagents: {
          allowAgents: ["prospector", "agent2"],
          requireAgentId: true
        }
      },
      {
        id: "prospector",
        heartbeat: {
          every: "10m",
          target: "last"
        }

#

      },
      {
        id: "agent2"
      }
    ]
  }
}

Then restart the gateway.

Do you need cron?

Not for heartbeat.

#

But:

if you want “periodically check stuff” → heartbeat
if you want “run this exact job every 10 minutes no matter what” → cron is better

So no, cron is not required, but for strict scheduled work it’s usually the better tool.

Docs:

If you want, paste your current ~/.openclaw/openclaw.json and I’ll tell you the exact block to add, no guessing.

gentle zealot Apr 17, 2026, 5:43 PM

#

okay can i ask the main agent to do it?

ex:
"for 'prospector' agent, please create its heartbeat to run 1hour."

But also i want it to self update its heartbeat dynamically if needed since the prospector normally uses an endpoint to check /me/limits etc to know whether can proceed or not, the response will already be given when the next can be proceed so then the heartbeat can be updated dynamically based on that i think if its possible? idk, advuse and give me a prompt i can send to my MAIN agent to do it? also same for the 'closer' agent. this is another agent i want to have a heartbeat of 5hour instead without being dynamic

modern plazaBOT Apr 17, 2026, 5:44 PM

#

Yes, you can ask main to do it.

But my recommendation is:

Prospector: keep heartbeat fixed at 1h
Closer: keep heartbeat fixed at 5h
For Prospector, do not keep rewriting heartbeat.every dynamically. That gets messy fast.
Instead, let Prospector self-skip until the next allowed time based on /me/limits, by updating its own HEARTBEAT.md or a small local state file.

That is much more stable.

If you need exact “wake me at this exact next timestamp” behavior, use cron, not dynamic heartbeat.

Best prompt to send your MAIN agent

#

Please configure my multi-agent setup with minimal changes.

Agents:
- main
- prospector
- closer

What I want:

1) In ~/.openclaw/openclaw.json:
- allow main to delegate to prospector and closer
- require explicit target agent when delegating
- set prospector heartbeat to every 1 hour
- set closer heartbeat to every 5 hours

#

2) Update prospector’s workspace heartbeat instructions:
- file: /home/openclaw/.openclaw/workspace-prospector/HEARTBEAT.md
- prospector should check its /me/limits endpoint
- if the endpoint says work cannot proceed yet, record the next allowed time locally and skip until then
- do NOT keep rewriting heartbeat.every dynamically unless absolutely necessary
- prefer a fixed 1 hour heartbeat with self-skip logic
- if nothing needs attention, reply HEARTBEAT_OK

3) Update closer’s workspace heartbeat instructions:
- file: /home/openclaw/.openclaw/workspace-closer/HEARTBEAT.md
- fixed 5 hour heartbeat
- no dynamic scheduling
- if nothing needs attention, reply HEARTBEAT_OK

4) Keep changes minimal and show me:

#

- the exact openclaw.json changes
- the exact HEARTBEAT.md contents for prospector and closer

5) Do not change unrelated config.
6) If a gateway restart is required, tell me exactly what command I should run, but do not run it automatically.

One practical tip

For testing, tell it to set heartbeat target: "last" first, so you can actually see it fire.
Once it works, you can switch to target: "none" if you want it quiet.

If you want, I can also give you the exact JSON block and exact HEARTBEAT.md text for Prospector and Closer, ready to paste.

gentle zealot Apr 17, 2026, 6:10 PM

#

thanks.. now i also want to include a 4.55mb file which is around 800k token. do u think its a good idea? because it has all endpoints on it and it is the main documentation to get the job done and see if there are any other endpoints can be used instead of the fixed one i provided. how can i make it do that? i mean, what would u advise we can achive this?

modern plazaBOT Apr 17, 2026, 6:11 PM

#

I would not inject an 800k token file directly into the agent’s regular context.
That’s usually a bad idea, especially for heartbeat-based agents.

My advice

Good idea

Use the big file as a reference source in the workspace.

Bad idea

Make the agent re-read the whole 800k-token file every run.

That will be:

expensive
slow
noisy
and pretty unreliable for repeated heartbeats

#

Best setup

For prospector, I’d do this:

Put the raw file in its workspace, for example:
```
/home/openclaw/.openclaw/workspace-prospector/docs/api-reference.json
```
or .md / .txt / whatever it is
Create a small index file, for example:
```
/home/openclaw/.openclaw/workspace-prospector/docs/API_INDEX.md
```
That file should list:
- endpoint groups
- auth rules

#

limits-related endpoints
- important alternative endpoints
- where each section lives

Update prospector instructions so it:
- does not read the whole file by default
- searches the docs only when needed
- records useful discoveries in a small notes file like:
```
DISCOVERED_ENDPOINTS.md
```
Keep heartbeat small:
- check /me/limits
- if blocked, consult the index / relevant docs section
- if a better endpoint is found, save it to notes
- do not reload the whole manual every hour

#

What you can achieve with this

Yes, this can work well if structured properly.

You can make the agent:

discover better endpoints over time
keep a curated shortlist of useful endpoints
avoid depending on only one fixed endpoint
stay cheap enough to run regularly

What I would not do

I would not tell it:

“Always include this 800k token document in your prompt”

That will hurt more than help.

#

Best prompt to send your MAIN agent

Please set up Prospector so it can use my large API documentation efficiently without bloating context.

Goals:
1) Add the raw API documentation file into Prospector’s workspace under a docs/ folder.
2) Create a small API_INDEX.md that summarizes:
   - endpoint groups
   - limits-related endpoints
   - important auth/usage notes
   - promising alternative endpoints
   - where to find each section in the raw docs
3) Update Prospector’s instructions so it does NOT load the full API document by default.
4) Prospector should search/read only the relevant sections when needed.
5) Create a small DISCOVERED_ENDPOINTS.md file where Prospector can save useful endpoints and alternatives it finds.

#

6) Update Prospector heartbeat instructions so each run:
   - checks /me/limits first
   - if blocked, checks whether another endpoint can be used
   - consults API_INDEX.md and only the relevant doc sections
   - updates DISCOVERED_ENDPOINTS.md when it finds something better
   - avoids reading the entire API reference unless absolutely necessary
7) Keep all changes minimal and show me exactly what files were created or edited.

If you want, I can also give you a better folder/file structure for this, like exactly what files to create under workspace-prospector/docs/.

gentle zealot Apr 17, 2026, 7:59 PM

#

thanks. does each agent auto self improve themselve when they make mistake etc?

modern plazaBOT Apr 17, 2026, 8:00 PM

#

Not really, not by default.

What they do improve from

Current session history: yes, they can correct themselves during the same ongoing session
Files they can update: yes, if you tell them to maintain notes like:
- DISCOVERED_ENDPOINTS.md
- LESSONS.md
- HEARTBEAT.md

What they do not do automatically

they do not auto-train their model
they do not reliably rewrite themselves into a better agent on their own
they do not persist “wisdom” forever unless you give them a place to store it

Best pattern

Give each agent a small writable memory file, for example:

#I create some agent from the main agent, but now i wonder how i should orchestrate those agents.

1) Where those settings live

2) Important correction

3) What to put in ~/.openclaw/openclaw.json

4) Will “I told main agent to give agent1 a 10 min heartbeat” work by default?

5) One more important thing

What you actually need

Meaning

Why you don’t see those keys now

Your case, specifically

Do you need cron?

Best prompt to send your MAIN agent

One practical tip

My advice

Good idea

Bad idea

Best setup

What you can achieve with this

What I would not do

Best prompt to send your MAIN agent

What they do improve from

What they do not do automatically

Best pattern

3) What to put in `~/.openclaw/openclaw.json`