how to make my agents automatically use lobster workflow to do tasks? | Friends of the Crustacean 🦞🤝 | Page 1

lusty spade Apr 19, 2026, 1:18 PM

#

how to make my agents automatically use lobster workflow to do tasks?
@zenith marsh

zenith marshBOT Apr 19, 2026, 1:20 PM

#

Short version: there isn’t a magic “always use Lobster for everything” switch.

What you want is:

Enable the Lobster tool for the agent

{
  tools: {
    alsoAllow: ["lobster"]
  }
}

Or per agent:

#

  agents: {
    list: [
      {
        id: "main",
        tools: {
          alsoAllow: ["lobster"]
        }
      }
    ]
  }
}

Teach the agent to prefer it in AGENTS.md / standing orders, for example:

#

When a repeatable multi-step task has a matching .lobster workflow, use Lobster instead of manually chaining tools.
If no workflow exists, suggest creating one.

Actually create .lobster workflows for the tasks you want automated, then the agent can run those by path.

If you use subagents/OpenProse, also make sure subagents can use it via tools.subagents.tools when needed.

Good docs:

If you want, paste your openclaw --version plus your current agent config, and I’ll turn it into the exact Lobster setup snippet for your case.

lusty spade Apr 19, 2026, 1:21 PM

#

give me the complete config suggestion

zenith marshBOT Apr 19, 2026, 1:23 PM

#

Yep, here’s the clean starter setup I’d recommend, in JSON5 (not YAML):

`~/.openclaw/openclaw.json5`

{
  tools: {
    // Let agents use the Lobster tool everywhere.
    alsoAllow: ["lobster"],

    // Only relevant if you already use restrictive subagent policies.
    // If you have tools.subagents.tools.allow elsewhere, make sure it includes "lobster".
  },

  plugins: {
    entries: {
      // Optional: only needed if your .lobster workflows call llm-task inside the pipeline.

#

      "llm-task": {
        enabled: true,
      },
    },
  },

  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace",
    },

    list: [
      {
        id: "main",
      },

#


      // Example extra agents
      {
        id: "research",
      },
      {
        id: "ops",
      },
    ],
  },
}

Then add this to each agent’s `AGENTS.md`

#

## Lobster workflow policy

- Prefer Lobster for repeatable multi-step tasks.
- Prefer Lobster when a task has approvals, resumable steps, or deterministic pipelines.
- If a matching `.lobster` workflow exists, run it instead of manually chaining tools.
- Use direct tool calls only for simple one-off tasks.
- If a task is likely to repeat and no workflow exists yet, suggest creating a `.lobster` workflow.

And keep your workflows somewhere predictable, for example

~/.openclaw/workspace/workflows/
  inbox-triage.lobster
  weekly-review.lobster
  deploy-checks.lobster

#

Important bit

There is no config-only “always route everything through Lobster” switch right now.

What makes it work is the combo of:

config → enables the lobster tool
AGENTS.md / standing orders → teaches the agent when to prefer it
actual .lobster files → gives it something real to run

Docs:

If you want, paste your current openclaw.json5 and I’ll merge this into your real config instead of giving you a generic starter.

lusty spade Apr 19, 2026, 1:29 PM

#

Hi Krill, a few sharper questions so I can implement this cleanly across multiple agents:

For a Lobster-first agent, is AGENTS.md the strongest practical place for the preference rule, or is there another runtime layer that tends to win more reliably?
If AGENTS.md says “prefer Lobster when a matching workflow exists,” but the user asks for something short that could also be done manually, what usually wins in practice?
For subagents, is enabling the lobster tool on the parent plus subagent tool access enough, or do subagents also need their own explicit standing-order style instruction to consistently prefer Lobster?
In a multi-agent setup, what workflow location tends to work best in practice:
• per-agent workspace,

• shared workspace root,
• or a structured shared folder like SOPv2/lobster/workflows/?

Do you recommend any specific pattern for making routing more deterministic, so the agent does not just “prefer” Lobster in theory, but actually picks the right workflow for known task families?
If legacy manuals/checklists still exist for reference, what is the best anti-regression pattern besides archiving them and adding standing orders?
What is the fastest reliable way to verify that a given agent, including its subagent path, really has Lobster tool access enabled?

If helpful, I can also paste my actual agent structure and workflow paths so you can suggest the cleanest enforcement pattern instead of a generic one.

zenith marshBOT Apr 19, 2026, 1:31 PM

#

Yep, these are the right questions.

1. Strongest practical place for the rule?

AGENTS.md is the best default place for behavior/routing rules.

Why:

it is auto-injected every session
subagents only get AGENTS.md + TOOLS.md anyway, so this is the main place they’ll actually see the rule

If you want something even more centralized across many agents, the next layer up is an agent:bootstrap hook that injects the same routing block everywhere.

Important nuance: tool policy is harder enforcement, but it only blocks/allows tools. It does not positively force “pick Lobster now”.

2. If the task is short, what wins?

If your rule says “prefer Lobster”, the model may still do the short/manual version.

So for known task families, use stronger wording like:

#

If a request matches a known Lobster workflow, always use that workflow.
Do not manually substitute unless:
1. the workflow fails, or
2. the user explicitly asks to bypass Lobster.

That is much more reliable than “prefer”.

3. For subagents, is tool access alone enough?

No, not for consistency.

You need:

Lobster tool accessible in the parent path
Lobster allowed through any tools.subagents.tools policy
and the subagent needs the routing instruction in the context it actually sees

#

Since subagents only inject AGENTS.md + TOOLS.md, give them the Lobster rule there too, or inject it via bootstrap hook.

4. Best workflow location?

For multi-agent setups, I’d usually recommend a structured shared folder, not workspace root.

Best default:

SOPv2/lobster/workflows/

Why:

cleaner routing
easier reuse across agents
easier to version and review
avoids every agent inventing its own copy

Use per-agent workspace only for truly agent-specific workflows.

#

5. How to make routing more deterministic?

Use a routing table, not vague prose.

Example in AGENTS.md:

## Lobster routing

Known workflows:
- invoice triage -> /path/to/SOPv2/lobster/workflows/invoice-triage.lobster
- weekly review -> /path/to/SOPv2/lobster/workflows/weekly-review.lobster
- support digest -> /path/to/SOPv2/lobster/workflows/support-digest.lobster

Routing rule:
- If a request matches one of the workflows above, use that workflow.
- Do not execute the task manually unless the workflow fails or the user explicitly says to bypass Lobster.

#

- If no workflow matches, handle normally and suggest creating a workflow if the task repeats.

That pattern works much better than “prefer Lobster in theory”.

6. Best anti-regression pattern for legacy manuals/checklists?

I’d do all of these:

keep legacy manuals as reference-only
add a header like:
Superseded by: /path/to/.../workflow.lobster
add a standing order:
“When a Lobster workflow exists, manuals/checklists are reference only, not the execution source.”
keep one canonical workflow per task family

That prevents drift.

#

7. Fastest reliable verification?

Best combo:

Check effective tool policy

openclaw sandbox explain --agent <agentId>

For a live child session

openclaw sandbox explain --session <childSessionKey>

Confirm the instruction is actually injected

/context list
/context detail

#

Do a smoke test

run a tiny known-good .lobster workflow with the main agent
then through the spawned subagent path

That gives you both policy verification and real end-to-end proof.

My practical recommendation

If you want this clean across many agents:

shared workflow folder like SOPv2/lobster/workflows/
per-agent AGENTS.md routing table
strong wording: “always use mapped workflow”, not “prefer”
optional agent:bootstrap hook if you want one central rule injected everywhere

Docs:

#

If you paste your actual agent IDs, workspace layout, and workflow folder paths, I can sketch the exact enforcement pattern I’d use for your setup.

lusty spade Apr 19, 2026, 1:32 PM

#

can u give me a shorter answer so it can be fit in a telegram bubble chat?

zenith marshBOT Apr 19, 2026, 1:33 PM

#

Yep, short version:

Put the rule in AGENTS.md. That’s the main practical place, and subagents see AGENTS.md too.
Don’t say “prefer Lobster”. Say: “If a task matches a known workflow, always use that .lobster file unless it fails or the user asks to bypass it.”
Keep workflows in a shared structured folder like SOPv2/lobster/workflows/, not loose in workspace root.
Add a small routing table in AGENTS.md mapping task family → workflow path.
If you use subagents, make sure lobster is allowed there too, not just on the parent.
Fast check: openclaw sandbox explain --agent <agentId> and /context list.

Docs:
https://docs.openclaw.ai/tools/lobster
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/automation/standing-orders

lusty spade Apr 19, 2026, 1:39 PM

#

Hi Krill, we now have enough to start implementation. I only have 3 optimization questions left:

For a setup with multiple agents, would you recommend keeping the Lobster routing rule purely in each agent’s AGENTS.md, or using an agent:bootstrap hook as the primary shared enforcement layer?
For legacy manuals that must remain in the repo as historical/reference material, is there a best-practice header format that most reliably makes the model treat them as reference-only rather than execution source?
For verifying real Lobster adoption, what is your preferred minimal smoke-test pattern for both the parent agent path and the spawned subagent path?

If helpful, I can also share my actual

agent/workflow layout so you can comment on the cleanest enforcement structure.

zenith marshBOT Apr 19, 2026, 1:39 PM

#

Yep, my take:

Many agents: use agent:bootstrap as the shared base layer, then keep a small per-agent note in AGENTS.md for local overrides.
If it’s only a couple agents, AGENTS.md alone is simpler.
For legacy manuals, add a loud header like:

# REFERENCE ONLY - DO NOT EXECUTE DIRECTLY

Status: Superseded
Canonical workflow: /path/to/foo.lobster
Execution rule: If a matching Lobster workflow exists, use that workflow instead of this document.
Purpose: Historical/reference context only.

Minimal smoke test:

#

make one tiny workflow, e.g. lobster-smoke.lobster, that returns a unique token like LOBSTER_SMOKE_OK
ask the parent agent to run it
ask the parent to spawn a subagent and run the same workflow
verify both outputs show the workflow token/path, not a manual imitation
if needed, confirm policy/context with:
- openclaw sandbox explain --agent <agentId>
- /context list

If you paste your real agent/workflow layout, I can tell you whether to go bootstrap-first or AGENTS-only for your exact setup.

Docs:
https://docs.openclaw.ai/tools/lobster
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/automation/hooks

lusty spade Apr 19, 2026, 2:55 PM

#

btw why the spawned subagent session, that spawned from telegram topic, failed to send message (message tool) to whatsapp?

zenith marshBOT Apr 19, 2026, 2:56 PM

#

First thing, can you share openclaw --version and the exact message-tool error? That’ll narrow it down fast.

Most likely causes here:

The subagent kept the Telegram requester route, but the outbound WhatsApp send still needed an explicit message call with:
- channel: "whatsapp"
- explicit target
- and accountId if you have multi-account WhatsApp
A spawned subagent does not magically switch its outbound default to WhatsApp just because it came from Telegram.
Subagent tool policy blocked message (or provider-specific policy narrowed it).
WhatsApp account/routing config is missing or ambiguous, especially in multi-account setups. If there’s no clear default, you often need accountId explicitly.

Quick checks:

openclaw status --all

#

openclaw channels logs --channel whatsapp
if multi-account: verify channels.whatsapp.defaultAccount or pass accountId in the message tool call

If you paste:

the message tool call you used
the error text
and openclaw --version

…I can probably tell you the exact reason.

Docs:
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/concepts/multi-agent
https://docs.openclaw.ai/channels/whatsapp

lusty spade Apr 19, 2026, 2:59 PM

#

OpenClaw version: 2026.4.15 (041266a)

Exact errors:

Cross-context messaging denied: action=send target provider "whatsapp" while bound to "telegram".
Unknown target "agent:eve:whatsapp:eve-whatsapp:direct:redacted" for Telegram. Hint: <chatId>

What I found:

• The Eve subagent stayed bound to the Telegram requester context, so message.send to WhatsApp was denied.
• I then tried a fallback by using sessions_send directly into Eve’s WhatsApp-bound session.
• That did inject the payload into the WA session thread, but Eve responded with NO_REPLY instead of actually dispatching an outbound WhatsApp message.

So this looks like a two-layer issue:

Cross-context routing denial when trying to send WhatsApp from a Telegram-bound

subagent.
2. Incorrect WA-session behavior, because the injected outbound instruction is being treated like an internal prompt and ends in NO_REPLY instead of performing delivery.

So I don’t think this is only a missing default account/config issue. There is also a behavior problem in how the WhatsApp-bound Eve session interprets injected send instructions.

zenith marshBOT Apr 19, 2026, 3:00 PM

#

Yep, this looks like two different mechanisms colliding, and your read is mostly right.

What’s happening

Cross-context messaging denied... while bound to "telegram"

This is intentional policy in 2026.4.15.
Cross-provider sends are blocked unless you enable:

{
  tools: {
    message: {
      crossContext: {
        allowAcrossProviders: true,
        marker: { enabled: true, prefix: "[from {channel}] " },
      },
    },

#

     },
   }

Unknown target "agent:eve:whatsapp:..." for Telegram
- That string is a session key, not a Telegram chatId.
- So if it hits message.send, Telegram tries to treat it like a Telegram target and rejects it.
- In other words: session key != channel target.
Why sessions_send to Eve’s WA session ended in NO_REPLY
- This is the important bit: sessions_send is inter-session injection, not a transport/delivery primitive.
- It can wake Eve’s session, but it does not mean “send a WhatsApp message because this session is WA-bound”.
- If Eve returns NO_REPLY, that usually means the internal handoff ended silently, not that WhatsApp delivery happened.

So the clean mental model is

#

message tool = actual channel delivery
sessions_send = talk to another session
WhatsApp-bound session ≠ automatic WhatsApp transport bridge for injected inter-session messages

Best fix

If you want the Telegram-originated subagent to send to WhatsApp, the clean path is:

enable cross-provider message sends on the sending agent
then use the message tool directly with explicit:
- channel: "whatsapp"
- target: "+628..."
- accountId if multi-account

If you keep the Eve handoff pattern

Then Eve must explicitly do a real message(action=send, channel:"whatsapp", target:...) call.
Do not expect sessions_send by itself to post into WhatsApp.

#how to make my agents automatically use lobster workflow to do tasks?

~/.openclaw/openclaw.json5

Then add this to each agent’s AGENTS.md