#Subagent
1 messages · Page 1 of 1 (latest)
Yep — the clean way is to make the cron agent use the session/subagent tools.
Two common patterns:
-
One-off data fetch from another agent
Have the cron prompt tell Agent A to spawn Agent B as a sub-agent, e.g. “spawn theweatheragent to collect today’s data, then summarize it.” Under the hood that usessessions_spawnwithagentId: "weather". The child runs separately and its result is handed back to the cron/requester session.Config-wise, the cron/requester agent needs:
sessions_spawnavailable (tools.profile: "coding"or allowsessions_spawn/group:sessions)- permission to target the other agent via
subagents.allowAgents, e.g.
{
agents: {
list: [
{
id: "cron-agent",
subagents: {
allowAgents: ["data-agent"]
}
},
{ id: "data-agent" }
]
}
}
Then the cron message can be something like:
Ask the data-agent subagent to fetch X. Wait for its result, then produce the final report.
- Talk to an existing persistent session
If you want to message an already-existing session instead of spawning a fresh one, usesessions_send. For cross-agent/session visibility you’ll usually need broader session visibility, e.g.tools.sessions.visibility: "all", and for cross-agent targeting enabletools.agentToAgent.
For most cron workflows I’d recommend pattern 1: sessions_spawn + agentId. It’s cleaner, isolated, and cron/subagent completion delivery is designed for this.
Docs:
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/concepts/session-tool
https://docs.openclaw.ai/automation/cron-jobs