Exclude Individual Agents from Dreaming? | Friends of the Crustacean 🦞🤝 | Page 1

crisp egret Apr 14, 2026, 11:14 PM

#

@lilac jetty I have five agents. The main, of course lives in .openclaw/workspace; the others each have their own workspace folder, .openclaw/workspace-[agent name].

But last night, when the dreaming run ran, each of those agents suddenly got a nested folder inside .openclaw/workspace/[agent name]. And each got a DREAMS.md file in it. I don’t know if this is expected behavior, but it seems strange, because now they have a dedicated workspace folder (which doesn’t have a DREAMS.md), and they have a nested folder in the main agent’s workspace, and each has a DREAMS.md there.

These are all utility agents. Including them in dreaming actually creates more noise than value. Is there a way to exclude them from dreaming, and restrict dreaming to only my main agent?

lilac jettyBOT Apr 14, 2026, 11:16 PM

#

Let me verify how dreaming decides which workspaces to touch, because the nested DREAMS.md bit smells like workspace resolution rather than “intended utility-agent dreaming.”

#

I found the public config docs, but I want one more pass through the code because the docs only expose a global dreaming toggle/frequency so far.

#

Now I’m checking the workspace path resolver itself, because the exact path you described, workspace/[agent-name], usually means the agent workspace was configured relative to the main workspace instead of as a sibling.

#

I’ve got enough to answer the “can I exclude agents?” part, but I’m doing one last check for whether that nested workspace/<agent> path comes from a dreaming-specific quirk or just the normal agent workspace resolver.

#

Short answer, not currently.

I checked the current docs/code, and dreaming is still a global memory-core setting. Scheduled dreaming sweeps currently fan out across all configured agent workspaces, not just the main agent. I don’t see a per-agent include/exclude knob yet.

The nested ~/.openclaw/workspace/<agentId>/DREAMS.md part also fits the workspace fallback logic:

if a non-default agent does not have an explicit agents.list[].workspace
OpenClaw falls back to agents.defaults.workspace + /<agentId>

So if your default workspace is ~/.openclaw/workspace, fallback for agent foo becomes:

~/.openclaw/workspace/foo

not

~/.openclaw/workspace-foo

So I’d check these first:

#

openclaw --version
openclaw config get agents.list

If those utility agents are meant to live in ~/.openclaw/workspace-<name>, make sure each one has an explicit workspace set there.

If your goal is “dream only on main”, the current workaround is:

disable scheduled dreaming globally with /dreaming off
run memory commands manually for main, for example:

openclaw memory promote --agent main --apply

That avoids the utility-agent noise, but it is a workaround, not a true per-agent dreaming filter.

#

Docs:

If you paste your agents.list block, I can sanity-check whether this is just workspace resolution or an actual bug. If you want true main-only scheduled dreaming, that looks like a feature request: https://github.com/openclaw/openclaw/issues

crisp egret Apr 14, 2026, 11:24 PM

#

OK. Somehow they had separate workspaces, but they don’t have them configured in agents.list now. What’s the better configuration? Should I specify them in agents.list?

lilac jettyBOT Apr 14, 2026, 11:25 PM

#

Yeah, if you want separate workspaces, I’d configure them explicitly in agents.list.

I would not rely on the implicit fallback in a multi-agent setup, because that’s exactly how you end up with surprising paths like ~/.openclaw/workspace/<agentId>.

Recommended shape:

{
  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace",
    },
    list: [
      { id: "main", default: true, workspace: "~/.openclaw/workspace" },
      { id: "util1", workspace: "~/.openclaw/workspace-util1" },
      { id: "util2", workspace: "~/.openclaw/workspace-util2" },

#

      { id: "util3", workspace: "~/.openclaw/workspace-util3" },
      { id: "util4", workspace: "~/.openclaw/workspace-util4" },
    ],
  },
}

My recommendation:

If you want isolation, give every agent its own explicit workspace.
If you want one shared memory/dream diary, point the utility agents at the same workspace as main.

That second option is actually useful here, because dreaming dedupes shared workspaces. So if all utility agents share main’s workspace, you only get one DREAMS.md.

So the practical choices today are:

#

Explicit separate workspaces
Clean, predictable, isolated, but dreaming will still touch each workspace.
Shared workspace for utility agents
Best if they’re just “roles/tools” around the same brain, and you want only one dream surface.

Since there’s no per-agent dreaming allowlist yet, I’d pick based on whether those utility agents really need separate memory.

After changing it, I’d restart the gateway so the managed dreaming sweep picks up the new layout:

openclaw gateway restart

Docs:

#

If you want, paste your current agents.list and I can rewrite it into the clean explicit version.

crisp egret Apr 14, 2026, 11:31 PM

#

To clarify: If I want 2 (Shared workspace for utility agents), what does that look like in agents.list? Each one has a specified workspace, but that workspace is “~/.openclaw/workspace” for each one?

lilac jettyBOT Apr 14, 2026, 11:32 PM

#

Yep, exactly.

If you want the utility agents to share main’s workspace, set their workspace to the same exact path:

{
  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace",
    },
    list: [
      { id: "main", default: true, workspace: "~/.openclaw/workspace" },
      { id: "util1", workspace: "~/.openclaw/workspace" },
      { id: "util2", workspace: "~/.openclaw/workspace" },
      { id: "util3", workspace: "~/.openclaw/workspace" },
      { id: "util4", workspace: "~/.openclaw/workspace" },

#

    ],
  },
}

So yes, the non-main agents would also literally use:

workspace: "~/.openclaw/workspace"

That gives you one shared:

MEMORY.md
DREAMS.md
memory/
workspace files like AGENTS.md, SOUL.md, etc.

#

So the tradeoff is:

pro: one dream diary, one memory surface, less noise
con: they are no longer isolated workspaces

If these are just utility agents, that’s usually fine.

I’d still set the shared path explicitly on each one, even though it’s repetitive, just so the intent is crystal clear.

After changing it, restart the gateway:

openclaw gateway restart

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. This helps Answer Overflow index it for future users.

crisp egret Apr 14, 2026, 11:35 PM

#

But if these are isolated agents, with their own allowed toolsets, etc., shouldn’t they have their own workspaces?

lilac jettyBOT Apr 14, 2026, 11:35 PM

#

I want to be precise here, because “isolated agent” can mean two different things in OpenClaw: isolated policy, or isolated workspace/memory. Let me confirm the docs wording before I answer.

#

Not necessarily. This is the key split:

tool/sandbox isolation comes from agents.list[].tools and agents.list[].sandbox
file/memory isolation comes from workspace

So an agent can have:

its own allowed toolset
its own session/auth boundary
while still sharing the same workspace/files/memory as main

That’s actually a pretty good fit for “utility agents”.

So the rule of thumb is:

If you want separate memory/files/dream diary, give them separate workspaces.
If you want separate permissions, but the same knowledge/memory, share the workspace.

#

For example, this is valid:

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        workspace: "~/.openclaw/workspace",
      },
      {
        id: "calendar",
        workspace: "~/.openclaw/workspace",
        tools: { allow: ["message", "gog"] },
      },

#

      {
        id: "ops",
        workspace: "~/.openclaw/workspace",
        tools: { allow: ["exec", "read", "edit"] },
      },
    ],
  },
}

So yes, if by “isolated” you mean different tools/policies, they do not need separate workspaces.

If by “isolated” you mean separate memory and files, then yes, they should have separate workspaces.

And that’s the annoying tradeoff here: with dreaming today, separate workspaces means separate dreaming surfaces. There isn’t a built-in “dream only on main” switch yet.

crisp egret Apr 14, 2026, 11:41 PM

#

One last question: One of these agents is specifically a coder, with its own instructions in AGENTS.md. But if it’s pointed at ~/.openclaw/workspace, then he’ll use the default AGENTS.md, right?

lilac jettyBOT Apr 14, 2026, 11:42 PM

#

I should verify whether there’s a first-class per-agent instruction field before I suggest one, because the safe answer is “shared workspace means shared AGENTS.md.”

#

There is a workspace-level AGENTS answer here, but I’m also checking whether there’s a supported per-agent override so I don’t steer you into a dead end.

#

Yes, exactly.

If that coder agent points at ~/.openclaw/workspace, it will use the same workspace bootstrap files, including:

AGENTS.md
SOUL.md
USER.md
TOOLS.md
IDENTITY.md

So if the coder has its own AGENTS.md, it really wants its own workspace.

Honestly, the cleanest setup is probably a mix:

{
  agents: {

#

    list: [
      { id: "main", default: true, workspace: "~/.openclaw/workspace" },
      { id: "calendar", workspace: "~/.openclaw/workspace" },
      { id: "ops", workspace: "~/.openclaw/workspace" },
      { id: "coder", workspace: "~/.openclaw/workspace-coder" },
    ],
  },
}

That gives you:

shared workspace for the lightweight utility agents
separate workspace for the coder, so it gets its own AGENTS.md

The annoying part is, yes, this exposes the current tradeoff pretty clearly:

#Exclude Individual Agents from Dreaming?