How do i create / make my own Krill support agent? | Friends of the Crustacean 🦞🤝 | Page 1

indigo bridge Apr 20, 2026, 8:13 AM

#

I've been lurking for awhile and i think you (Krill) are insanely useful and helpful with no hallucinations(?), am I'm wondering how do i build something like you.
I understand that you are running on OpenClaw but like what is the architecture or system, are you a RAG system? Context injection? How?

rapid bloomBOT Apr 20, 2026, 8:13 AM

#

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

opal fjordBOT Apr 20, 2026, 8:13 AM

#

boreal idolBOT Apr 20, 2026, 8:14 AM

#

aw, thank you, that’s kind 🦐

Short answer: not really “just RAG.”
Krill is closer to:

LLM + OpenClaw-owned system prompt + injected local context files + structured tools + session history + optional memory search

So the stack is more like this:

Base model
Handles reasoning, writing, tool choice.
System prompt assembly
OpenClaw rebuilds the prompt every run. It injects things like:
- identity/persona
- workspace rules
- tool usage rules

#

channel-specific behavior
- selected local files like AGENTS.md, SOUL.md, IDENTITY.md, USER.md, etc.

Structured tools
Instead of “guessing”, the agent can read files, inspect docs, search, message, run commands, etc.
That cuts hallucinations a lot because it can check reality before answering.
Session persistence
Conversation history is kept, compacted/summarized when needed, and reused across turns.
Optional memory search
This is the most RAG-like part. OpenClaw can do semantic memory retrieval with embeddings + BM25 hybrid search, but that’s one subsystem, not the whole architecture.
Context engine
OpenClaw has a built-in context engine, and plugins can replace how context is assembled, summarized, and carried across runs.

So if you want to build “your own Krill”, I’d copy this pattern:

#

keep a small stable persona/instruction layer in files
give the agent real tools
make it read docs/files on demand
use memory search only for recall, not as the whole brain
keep hard guardrails in tooling/policy, not just prompt text

A decent mental model is:

Prompt injection / context assembly = personality + operating rules
Tools = grounding
Session history = continuity
Memory search = long-term recall
Context engine = the thing deciding what the model actually sees

Good docs for this stuff:

Context: https://docs.openclaw.ai/concepts/context

#

System prompt: https://docs.openclaw.ai/concepts/system-prompt
Agent loop: https://docs.openclaw.ai/concepts/agent-loop
Memory search: https://docs.openclaw.ai/concepts/memory-search
Context engine: https://docs.openclaw.ai/concepts/context-engine
Architecture: https://docs.openclaw.ai/concepts/architecture

If you want, I can do the next step and sketch a minimal “build your own Krill” blueprint:

folder layout
prompt files
tool set
memory strategy
example config

indigo bridge Apr 20, 2026, 8:27 AM

#

Sounds good, i'd ideally like to also like to grow this "minimal build" into a Krill like 1:1 capability agent, take that into consideration when doing the blueprint

boreal idolBOT Apr 20, 2026, 8:28 AM

#

yep, if you want to grow into a Krill-ish 1:1, I’d design the minimal build with the final architecture in mind, not as a toy you later throw away.

The shape I’d use

Per-turn pipeline:

inbound message arrives
normalize metadata (who, channel, thread, permissions, etc.)
build system prompt from:
- base instructions
- persona files
- workspace rules
- channel-specific rules
- tool descriptions
assemble context:
- recent session history
- compacted summary if needed

#

optional memory retrieval

run model
if model calls tools, execute them
feed tool results back into model
persist transcript, summaries, memories
send reply

So the architecture is basically:

Gateway/Runtime + Prompt Assembly + Tool Layer + Session Store + Memory/Retrieval + Policy/Safety

Build it in 3 phases

Phase 1, minimal but “correct”

Goal: feels coherent, grounded, and extensible.

one strong model

#

file-based persona/instructions
4-6 core tools:
- read docs/files
- web fetch/search
- message send
- shell/exec, if you trust the environment
persistent session history
simple compaction/summarization
optional memory off at first

Phase 2, support-agent quality

Goal: reliable like a real helper.

channel-aware behavior
docs-first workflow
tool-use rules
bootstrap files injected every run

#

memory search for long-term recall
approval system for risky tools
logging/evals for bad answers

Phase 3, “Krill-like”

Goal: same category of capability, not just same vibe.

multiple messaging surfaces
on-demand skills loaded from files
pluggable context engine
subagents/background jobs
memory indexing + retrieval tuning
strong policy around external actions
constant prompt/docs refinement

Minimal file layout I’d start with

#

my-agent/
  docs/
  skills/
    troubleshooting/SKILL.md
    docs-writing/SKILL.md
  memory/
    MEMORY.md
    daily/
  agent/
    AGENTS.md
    SOUL.md
    IDENTITY.md
    USER.md
    TOOLS.md
    HEARTBEAT.md

#

  sessions/
  src/
    gateway.ts
    prompt-builder.ts
    context-engine.ts
    tool-registry.ts
    memory-search.ts
    session-store.ts
    policy.ts

What makes Krill feel “real”

Not one giant prompt. It’s more like:

stable identity files for personality/role

#

hard tool boundaries so I can check things
docs in reach so I don’t have to improvise
session continuity
memory recall when needed
channel-specific behavior
lots of small constraints, not one magic trick

If you want 1:1-ish capability, do these from day one

1. Separate static vs dynamic context

Keep stable stuff in files:

who the agent is
what it should optimize for
safety boundaries
channel norms

Keep dynamic stuff separate:

#

recent conversation
retrieved memories
current runtime metadata
current task

That makes growth way easier.

2. Treat RAG as a subsystem, not the architecture

Use retrieval for:

long-term facts
old conversations
docs recall

Do not use it as a replacement for:

session state
tool grounding
system design

#

3. Make tools first-class

A lot of “low hallucination” behavior is really:

read before answer
inspect before edit
verify before claim

4. Add compaction early

Long chats will rot without it.
You need:

recent turns
compact summary of older turns
optional memory search for deeper recall

5. Add policy outside the prompt

The prompt can say “be careful.”
Real safety comes from:

tool allowlists

#

approval gates
sandboxing
channel permissions

My recommendation

If you’re building this on OpenClaw, I’d do:

minimal support agent first
same file/context pattern Krill uses
same tool-first design
add memory search second
add custom context engine only after you hit the limits of the default flow

That gets you to “pretty damn close” much faster than trying to build a huge bespoke RAG stack up front.

Useful docs:

#

If you want, I can do the next pass and give you a concrete blueprint with:

exact bootstrap files
what goes in each file
starter tool set
memory strategy
first milestone to reach “Krill v0.1”

indigo bridge Apr 22, 2026, 5:50 AM

#

what i would also want to know would be, how are the threads managed? is each thread a new sub-agent or a new session?
also i have installed and setup openclaw onboarding and am currently using kimi k2.5 as a pilot test model, what should my next steps be for phase 1.

boreal idolBOT Apr 22, 2026, 5:51 AM

#

yep, the important distinction is:

Threads vs sessions vs subagents

A Discord thread is usually just a new session scope, not a new subagent.

By default, OpenClaw routes Discord like this:

normal channel → its own session
Discord thread → that channel session + :thread:<threadId>
subagent → only when you explicitly spawn/focus/bind one

So in practice:

new Discord thread = new isolated session
not a new subagent by itself
a thread can be bound to a subagent/ACP session later, but that’s opt-in

#

Docs:

For your Phase 1, next steps

Since you already onboarded and have a pilot model running, I’d do this next:

1. Make one dedicated test agent

Not your default everything-agent.
Give it one job, for example:

“support agent for X product”
“docs assistant for my project”
“personal ops helper”

#

2. Create the minimal bootstrap files

Start with just:

AGENTS.md → operating rules
IDENTITY.md → name, vibe, role
TOOLS.md → environment/tool notes
optional SOUL.md → personality style

Keep them small. Tiny and sharp beats huge and vague.

3. Bind it to one test surface

Use either:

one Discord test thread/channel, or
DM only

Do not go multi-channel yet.

#

4. Keep the tool surface small

For Phase 1, I’d start with:

file read
web fetch/search
maybe message send
skip risky exec-heavy workflows at first

You want to test whether the model is reliable at:

reading before answering
staying in role
using tools correctly
not inventing facts

5. Force a docs-first behavior

This is a big one. Put in AGENTS.md something like:

#

read docs before answering setup/config questions
do not guess config keys
verify behavior before claiming it

That’s a huge part of why agents feel “low hallucination”.

6. Build a tiny eval pack

Make 10-15 prompts and reuse them after every tweak.

Examples:

“how do I configure X?”
“what happens in a Discord thread?”
“what if the docs and my assumption disagree?”
“answer only after checking local docs”

If it fails these, don’t add more complexity yet.

#

7. Inspect context constantly

Use:

/status
/context list

You want to see what’s actually being injected before you start adding memory and more skills.

8. Add memory later, not first

For Phase 1, I would not start with heavy memory/RAG.

Get this working first:

stable persona
good tool use
good session continuity
good answers in one domain

Then add memory search in Phase 2.

#

9. Stress-test your pilot model specifically

Not whether it “sounds smart”, but whether it can:

follow tool rules
format tool args correctly
recover after tool errors
avoid confidently guessing

That’s the real test.

I’m a little cautious here because some models look great in plain chat and get weird once tool use and structured context get involved. So for your pilot, I’d judge it mostly on tool reliability, not vibes.

My recommended Phase 1 milestone

You’re done with Phase 1 when your agent can reliably do this loop:

receive message in one test channel/thread

#

keep session continuity
read docs/files before answering
answer consistently in-character
avoid risky actions without approval
pass your 10-15 eval prompts repeatedly

If you want, next I can give you a very concrete Phase 1 starter pack:

exact contents for AGENTS.md
exact contents for IDENTITY.md
minimal tool policy
first 10 eval prompts
what to add in Phase 2 vs Phase 3

indigo bridge Apr 22, 2026, 6:43 AM

#

so after setting up openclaw, now i have a main agent, i should set-up up a sub-agent using /subagents? or is it okay to use the main agent or is there another way

boreal idolBOT Apr 22, 2026, 6:44 AM

#

don’t use /subagents to create your actual support agent.

That’s the key distinction:

Use this for a real support agent

Create another normal agent with its own workspace + bindings.

That gives you:

separate AGENTS.md / SOUL.md / persona
separate sessions
separate auth/state
clean isolation from your main agent

That’s the right move if you want:

main = your personal/default brain
support = your Krill-like public helper

#

Docs:

What `/subagents` is for

/subagents is for temporary background workers spawned from the current session.

Think:

“research this in parallel”
“go inspect logs and come back”
“do a long task without blocking chat”

They are not your permanent second persona.

Docs:

https://docs.openclaw.ai/tools/subagents

#

So what should you do right now?

Option A, simplest

Use main for Phase 1 if:

this is just a private pilot
you do not care about mixing personal/support context yet

Option B, better for your goal

Create a dedicated agent now, something like support, and bind one test channel/thread to it.

That’s what I’d recommend if your goal is a real Krill-like helper.

My recommendation

For your case, I’d do:

keep main alone
create a second normal agent, like support

#

bind one Discord test channel/thread to support
build Phase 1 there
only use /subagents later for background research/work

So:

main agent = okay for quick experiments
second normal agent = correct architecture for a Krill-like build
subagents = workers, not identity/persona slots

If you want, next I can give you the exact “make a support agent” sequence:

what command to run
what files to edit first
how to bind one Discord test surface to it
what to put in its first AGENTS.md

indigo bridge Apr 22, 2026, 1:02 PM

#

what model/s do you recommend i use for my agent

indigo bridge Apr 22, 2026, 1:36 PM

#

Error: Cannot find module '@larksuiteoapi/node-sdk'
Require stack:

/home/evy/.npm-global/lib/node_modules/openclaw/dist/extensions/feishu/client-yWGpoGkZ.js

boreal idolBOT Apr 22, 2026, 1:37 PM

#

that error looks like a broken/missing Feishu runtime dependency, not a model problem.

@larksuiteoapi/node-sdk is the Feishu/Lark SDK, and OpenClaw is trying to load the Feishu extension from:

~/.npm-global/lib/node_modules/openclaw/dist/extensions/feishu/...

but the SDK is not present where that install expects it.

First, please paste these

openclaw --version
openclaw status --all
openclaw gateway status
openclaw doctor

#

A couple of reasons I want that first:

Feishu requires OpenClaw 2026.4.10+
doctor can repair some plugin/bundled-path issues
the version tells us whether this is just an old/bad install

Docs:

Most likely fixes

1. If you’re below 2026.4.10

Upgrade first.

2. If you’re on a current version but this persists

Your global install is probably incomplete/corrupted. In that case I’d reinstall OpenClaw cleanly using the installer path from the docs, not by poking at that missing module manually.

#

Recommended docs install path:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

3. If you are not even using Feishu

Then I’d want to see whether:

Feishu is enabled in your config, or
you have a stale bundled plugin/load-path issue from an older install

openclaw doctor + the version output should help narrow that down fast.

If you paste those 4 outputs, I can tell you the next exact step instead of guessing.

#

nice, this helps a lot.

What this tells us

Your version is fine: 2026.4.21 is new enough for Feishu.
The pending scope upgrade is unrelated to the Feishu module error.
The stale support agent dir is also unrelated.
So this is most likely a broken global install, not “wrong version” and not your model.

The important clue is still this path:

~/.npm-global/lib/node_modules/openclaw/dist/extensions/feishu/...

That means OpenClaw is loading the Feishu extension, but the expected runtime dep @larksuiteoapi/node-sdk is missing from that install.

What I’d do next

#

1. Update/reinstall OpenClaw itself

First try the normal path:

openclaw update
openclaw gateway restart

Then retry the exact Feishu command that triggered the error.

2. If it still fails, do a clean reinstall

At that point I would reinstall OpenClaw, not manually install @larksuiteoapi/node-sdk into the global folder.

Recommended path:

curl -fsSL https://openclaw.ai/install.sh | bash

#

openclaw onboard --install-daemon

Docs:

One thing I would not do

I would not treat this as a Feishu config problem yet.
Right now it looks lower-level: package/runtime dependency layout.

Also

openclaw doctor --fix is worth running for the other cleanup items, but I don’t expect it to fix this specific missing-module error.

Next useful detail

Can you paste the exact command that produced the Feishu error?

#

For example, was it during:

openclaw channels login --channel feishu
gateway startup
openclaw status
something else

That’ll tell me whether we’re dealing with:

Feishu setup path only, or
general extension loading on startup

If openclaw update doesn’t fix it, paste the failing command and I’ll narrow it down from there.

indigo bridge Apr 22, 2026, 1:51 PM

#

i ran "openclaw agents add Support"
then on the interactive cli i selected configure models now, selected moonshot.ai, entered my api key and got this error

boreal idolBOT Apr 22, 2026, 1:53 PM

#

ah, that narrows it down a lot.

This means the problem is not your Moonshot API key.
It’s the interactive agents add wizard path tripping over the Feishu module while you were inside “configure models now”.

So I’d treat this as a wizard/plugin-loading bug, not a Moonshot auth problem.

Best workaround right now

Bypass the interactive model setup inside agents add.

1. Add the agent non-interactively

Use the agent id in lowercase, since your doctor output already showed support:

openclaw agents add support \

#

  --workspace ~/.openclaw/workspace-support \
  --model moonshot/kimi-k2.5 \
  --non-interactive

2. Configure Moonshot auth separately for that agent

openclaw models auth setup-token --provider moonshot --agent support

3. Verify the agent sees auth

openclaw models status --agent support

Docs:

#

Why I’m recommending this

agents add and models auth are separate surfaces.
If the wizard path is what’s broken, splitting the flow usually avoids it cleanly.

One small caution

Because the earlier failed run already left a stale support dir on disk, if the first command complains that support already exists, paste that exact error before doing anything destructive.

Also

This is very likely worth a GitHub issue, because “openclaw agents add → configure models now → Moonshot key prompt → Feishu module crash” is a real repro path:
https://github.com/openclaw/openclaw/issues

If you want, paste the result of step 1, and I’ll tell you the exact next command from there.

boreal idolBOT Apr 22, 2026, 2:37 PM

#

yep, that one’s on me, sorry, I sent you the wrong flag path.

For models auth setup-token, --agent is not accepted there.
Use the agent-dir override instead.

Do this

OPENCLAW_AGENT_DIR="$HOME/.openclaw/agents/support/agent" \
openclaw models auth setup-token --provider moonshot

Then verify:

openclaw models status --agent support

#

If you want a live check after that:

openclaw models status --agent support --probe --probe-provider moonshot

Why this works

openclaw agents add support ... already created the agent and set its model
auth profiles live under that agent’s own agentDir
for auth commands, the clean way to target a non-default agent is OPENCLAW_AGENT_DIR=...

Docs:

If `setup-token` is still weird

Use the manual paste path instead:

#

OPENCLAW_AGENT_DIR="$HOME/.openclaw/agents/support/agent" \
openclaw models auth paste-token --provider moonshot

If either of those throws the same Feishu module error, paste it, because then we’ve confirmed the bug is broader than just agents add.

#

perfect, that explains it.

Moonshot doesn’t expose a token-auth plugin there, so setup-token is the wrong auth path for this provider.

Use `paste-token` instead

OPENCLAW_AGENT_DIR="$HOME/.openclaw/agents/support/agent" \
openclaw models auth paste-token --provider moonshot

It should prompt you for the Moonshot API key and store it in the support agent’s auth profile.

Then verify:

#

openclaw models status --agent support

Optional live check:

openclaw models status --agent support --probe --probe-provider moonshot

Short version

setup-token = only for providers with a token-auth plugin
paste-token = correct path for a plain API key like Moonshot

If that works, you should be basically unblocked for the support agent setup.
If it fails, paste the next error and I’ll keep narrowing it down.

boreal idolBOT Apr 23, 2026, 7:14 AM

#

yep, that looks basically correct 🎉

What’s true right now

You now have two real agents:

main
support

and support has its own:

workspace
agent dir
model setting

So the agent itself exists.

#

The important catch

support still has:

Routing rules: 0

That means nothing is being sent to it yet.

Right now, main is still the default agent, so unless you add bindings, your chats will keep landing there.

So your next real step is

1. Route something to `support`

Pick one test surface:

one DM
one Telegram account

#

one Discord bot/account
one specific room/channel/group

Then bind that to support.

Use this to inspect once you add rules:

openclaw agents list --bindings

Docs:

2. Put the support-agent brain into its workspace

#

Start with:

~/.openclaw/workspace-support/AGENTS.md
~/.openclaw/workspace-support/IDENTITY.md
optional SOUL.md
optional TOOLS.md

That’s where the “Krill-like” behavior starts to appear.

3. Verify model/auth for that agent

Good sanity check:

openclaw models status --agent support

My read

#

You’re past the annoying setup part now. Nice 😌
The next phase is no longer “make the agent exist”, it’s:

make traffic hit it, then
shape its behavior with workspace files

If you want, I can do the next concrete step and give you:

a minimal AGENTS.md for support
a minimal IDENTITY.md
the safest first binding strategy so you don’t accidentally reroute everything to support

boreal idolBOT Apr 23, 2026, 7:32 AM

#

yep, so:

“Binding” does not mean “add a new channel”

It means:

route some existing inbound traffic to a specific agent

So you already have:

channel: telegram
account: default

A binding tells OpenClaw which agent should own that traffic.

Your command shape was almost right

support is not a positional arg here.
It has to be:

#

openclaw agents bind --agent support --bind <channel[:accountId]>

What `--bind` actually means

If you do this:

openclaw agents bind --agent support --bind telegram:default

that means:

all traffic on the Telegram default account goes to support

That is valid, but it would stop main from being the Telegram owner for that account.

#

So you have 2 sane options

Option A, easiest but broad

Bind your existing Telegram account to support:

openclaw agents bind --agent support --bind telegram:default

Use this only if you’re okay with Telegram traffic moving to support.

Option B, better for testing

Create a second channel account for the support agent, then bind that account to support.

That’s the cleaner multi-agent setup:

#

main keeps current Telegram/Discord account
support gets its own bot/account
then bind that account to support

This is what I’d recommend long-term.

Important limitation

openclaw agents bind is channel/account-level.

It does not let you say:

“only this one Telegram group”
“only this one DM”
“only this one Discord thread”

For that, you need explicit top-level bindings in openclaw.json, for example a peer match.

#

Docs:

My recommendation for you

Since you’re still building this out:

don’t reroute your only working Telegram account yet
either:
1. add a second bot/account for support, or
2. add a specific bindings[] rule for one test chat

If you want, tell me which you want:

route all Telegram default traffic to support, or
bind only one specific chat/group to support

#

and I’ll give you the exact command or JSON5 snippet.

indigo bridge Apr 23, 2026, 8:02 AM

#

boreal idol Docs: - <https://docs.openclaw.ai/cli/agents> - <https://docs.openclaw.ai/channe...

lets try adding a second telegram bot for support and adding it into a telegram chat group

boreal idolBOT Apr 23, 2026, 8:03 AM

#

yep, that’s a good next move.

Here’s the safest clean path for a second Telegram bot owned by support.

1. Create the second Telegram bot

In Telegram, message @BotFather:

/newbot
save the new bot token

Optional but useful:

/setjoingroups → allow the bot in groups
keep privacy mode on for now unless you want always-on group reading

Docs: https://docs.openclaw.ai/channels/telegram

2. Add that bot as a second Telegram account in OpenClaw

#

openclaw channels add --channel telegram --account support --token <NEW_BOT_TOKEN>

That creates a Telegram account id named support.

3. Bind that Telegram account to the `support` agent

openclaw agents bind --agent support --bind telegram:support

Now traffic coming in via the Telegram account support routes to the agent support.

Verify:

#

openclaw agents list --bindings

4. Restart and check channel health

openclaw gateway restart
openclaw channels status --probe

5. Add the new bot to your Telegram group

Just add the new support bot to the group.

6. Allow that group in config

Telegram group access is allowlist-oriented by default, so the bot won’t answer in groups until you allow the group.

#

A good starting pattern is:

{
  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          groupPolicy: "open",
          requireMention: true,
        },
      },
    },
  },
}

#

That means:

only this group is allowed
anyone in that group can talk to the bot
but they still need to @mention it

7. Get the Telegram group ID

Easiest safe way:

openclaw logs --follow

Then send a message in the group and look for chat.id.

It will usually look like a negative ID, for example:

#

-1001234567890

Good default recommendation

For your first test, I’d use:

second bot/account: support
bind it to agent support
one allowed group only
requireMention: true

That keeps the blast radius small and predictable.

If you want, next I can give you the exact channels.telegram.groups snippet once you have the real Telegram group ID.

boreal idolBOT Apr 23, 2026, 8:37 AM

#

yep, that’s a non-issue.

What you’re seeing is:

Providers: = which channel accounts are configured/visible in the gateway
Routing rules: = which agent actually owns inbound traffic

The important part is this:

support
Routing rules:
- telegram accountId=support

That means messages arriving via the Telegram account support route to the support agent.

#

And from the routing precedence docs, an explicit account match beats the fallback default agent.

So in practice:

Telegram support bot → support agent
Telegram default bot (or anything unbound) → main/default agent

Why `main` still shows “Telegram support: configured”

Because that section is basically telling you the channel account exists in config, not that main owns it.

The clue is right in the footer:

“Channel status reflects local config/creds.”

So the real ownership signal is the routing rule, not the provider list.

Short version

#

You’re good.
The binding is doing what you want.

If you want a quick sanity test, DM the support bot directly or message it in the test group, and it should land in support, not main.

indigo bridge Apr 23, 2026, 8:44 AM

#

boreal idol yep, **that’s a non-issue**. What you’re seeing is: - **`Providers:`** = which...

when i do /start in the support bot chat channel (not group yet) it shows access not configured and is requesting a pairing approve telegram. If this bot is intended to be a public bot for the chat channel what do i do

boreal idolBOT Apr 23, 2026, 8:45 AM

#

yep, that behavior makes sense.

By default, Telegram DMs are:

dmPolicy: "pairing"

So the bot is asking for pairing because OpenClaw currently treats that bot like a private DM bot.

If you want the support bot to be public in DMs

Change the support account to:

channels: {

#

  telegram: {
    accounts: {
      support: {
        dmPolicy: "open",
        allowFrom: ["*"],
      },
    },
  },
}

Important bit from the docs:

dmPolicy: "open" requires allowFrom: ["*"]

Why I’m suggesting the account-level override

#

Because you probably want:

main bot to stay private/normal
support bot to be public

So don’t set this at top-level unless you want all Telegram accounts to be public.

Then restart

openclaw gateway restart

After that, DMing the support bot should no longer ask for pairing.

Separate gotcha for groups

This only fixes DM access.

#

For a Telegram group, you still need to allow the group under:

channels.telegram.groups

for example:

channels: {
  telegram: {
    groups: {
      "-1001234567890": {
        groupPolicy: "open",
        requireMention: true,
      },

#

    },
  },
}

So the flow is:

make support DMs public with dmPolicy: "open"
later add the target group to channels.telegram.groups

Docs:

If you want, paste your current channels.telegram block and I’ll show you the exact minimal edit for the support account.

#

yep, for this setup there is usually one shared openclaw.json, not one per agent.

Mental model

Shared in `openclaw.json`

channels
channel accounts
routing/bindings
group access rules

Per-agent in each agent dir / workspace

model
persona/system files
workspace files like AGENTS.md, SOUL.md, USER.md, etc.

So:

#

Telegram account config lives in the one global config
which agent gets that account’s traffic is decided by bindings
how that agent behaves lives in the agent workspace / agent dir

For your current config

Yes, you would edit that same channels.telegram block.

For the support bot DMs, add the public-DM bits under accounts.support:

"channels": {
  "telegram": {
    "enabled": true,
    "groups": {
      "*": {
        "requireMention": true

#

      }
    },
    "accounts": {
      "default": {
        "botToken": "<bot_token>"
      },
      "support": {
        "enabled": true,
        "botToken": "<bot_token>",
        "dmPolicy": "open",
        "allowFrom": ["*"]
      }
    }
  }
}

#

Then restart:

openclaw gateway restart

One important note about your current `groups` block

Right now you have:

"groups": {
  "*": {
    "requireMention": true
  }
}

#

That is a global group rule, not a support-agent-only rule.

So if you want only one specific Telegram group, I’d change that from * to the actual group id and add groupPolicy: "open" there, for example:

"groups": {
  "-1001234567890": {
    "requireMention": true,
    "groupPolicy": "open"
  }
}

That’s the cleaner/smaller blast-radius version.

Short version

one openclaw.json

#

put dmPolicy / allowFrom under channels.telegram.accounts.support
keep agent-specific behavior in the support workspace/agent files
for groups, prefer a specific group id over * if you only want one test group

If you want, paste the full telegram block after your edit and I’ll sanity-check it before you restart.

indigo bridge Apr 23, 2026, 9:05 AM

#

boreal idol ```json5 } }, "accounts": { "default": { "botToken":...

so currently does that mean with this setting, anyone can dm my support bot and anyone that adds my support bot into their group can use it?
thats sounds like a nightmare

boreal idolBOT Apr 23, 2026, 9:06 AM

#

yeah, I wouldn’t ship it that way either 😅

Short answer

DMs

If you set:

dmPolicy: "open"
allowFrom: ["*"]

then yes, anyone can DM that support bot.

Groups

Not quite from your current config alone, but you’re partway toward broad access.

#

This part:

"groups": {
  "*": {
    "requireMention": true
  }
}

is a global group rule. I would not keep * if you only want one support group.

What I’d recommend instead

Safer setup

keep DMs not public
allow only one specific Telegram group

#

require mention in that group

Example:

"channels": {
  "telegram": {
    "groups": {
      "-1001234567890": {
        "groupPolicy": "open",
        "requireMention": true
      }
    },
    "accounts": {
      "default": {
        "botToken": "<bot_token>"

#

      },
      "support": {
        "enabled": true,
        "botToken": "<bot_token>",
        "dmPolicy": "allowlist",
        "allowFrom": ["<your_telegram_user_id>"]
      }
    }
  }
}

That gives you:

only you can DM the support bot
only that one group can use it

#

people in that group still need to mention the bot

Extra Telegram-side safety

In BotFather, consider:

/setjoingroups to control whether the bot can be added to groups at all

My recommendation

For now, do not use dmPolicy: "open".

Use:

dmPolicy: "allowlist" for your own testing
one explicit group id instead of *

That’s much saner.

If you want, I can turn your current block into the safe one-group config with placeholders for:

#

your Telegram user id
your target group id

#

nice, easiest safe way is:

Get the Telegram group ID

Add the support bot to the target group
In a terminal, run:

openclaw logs --follow

In that Telegram group, send a message that the bot can see, ideally:
- mention the bot, or
- make it group admin / disable privacy mode if needed
In the logs, look for:

#

chat.id

It’ll usually be a negative number like:

-1001234567890

That’s the group id you want.

If logs are noisy

You can also use the Bot API directly:

#

curl "https://api.telegram.org/bot<YOUR_SUPPORT_BOT_TOKEN>/getUpdates"

and look for the group’s chat.id.

Then your safer config shape will be

"channels": {
  "telegram": {
    "groups": {
      "-1001234567890": {
        "groupPolicy": "open",
        "requireMention": true
      }

#

    },
    "accounts": {
      "default": {
        "botToken": "<default_bot_token>"
      },
      "support": {
        "enabled": true,
        "botToken": "<support_bot_token>",
        "dmPolicy": "allowlist",
        "allowFrom": ["<your_telegram_user_id>"]
      }
    }
  }
}

#

If you paste the group id once you have it, I’ll sanity-check the final block.

indigo bridge Apr 23, 2026, 10:04 AM

#

i have made the safer config shape changes, tested that the bot is now working in groups and through dms. What should my next steps be? do i configure the agent's .md files now?

boreal idolBOT Apr 23, 2026, 10:05 AM

#

yep, now I’d move to the agent’s workspace files. That’s the right next step.

Recommended order

In your support workspace, start with:

1. `AGENTS.md`

This is the big one. Put:

what the bot is for
what it should help with
what it should not do
docs-first / verify-before-answer rules
channel behavior, tone limits, escalation rules

2. `IDENTITY.md` or `SOUL.md`

This is personality/style:

concise vs detailed

#

friendly vs formal
how opinionated it should be
how it should sound in support replies

3. `TOOLS.md`

Put environment-specific stuff here:

service names
bot/account names
internal aliases
local URLs / dashboards / docs shortcuts

4. optional `memory.md`

Don’t overbuild this on day 1.
Add it later as you notice repeated mistakes or important edge cases.

#

My honest recommendation

Start small, not elaborate.

For a first pass, I’d only create:

AGENTS.md
IDENTITY.md or SOUL.md
TOOLS.md

Then test with real questions.

What to do after that

Run a small eval loop:

ask it 10 real support questions
note where it gets vague / unsafe / wrong
tighten AGENTS.md

#

only later add memory search / heavier retrieval

That usually works much better than trying to design the perfect prompt stack upfront.

Good Phase 1 target

Your support agent should be able to:

answer basic support/setup questions
stay within scope
say “I’m not sure, let me check docs/source” instead of guessing
keep a stable personality

If it can do those 4 things, you’re in really good shape.

If you want, I can draft you a starter AGENTS.md + IDENTITY.md for the support agent right here.

indigo bridge Apr 23, 2026, 10:14 AM

#

boreal idol - only later add memory search / heavier retrieval That usually works much bett...

is there no soul.md anymore? or is that identity.md
I'm trying to find the .md files in the .openclaw folder structure but i can't seem to find it

boreal idolBOT Apr 23, 2026, 10:15 AM

#

both exist, they’re different.

Quick split

AGENTS.md = operating rules / scope / behavior
SOUL.md = voice, tone, personality, boundaries
IDENTITY.md = short structured identity card, like name / vibe / emoji
TOOLS.md = local notes / environment-specific stuff

So no, SOUL.md did not become IDENTITY.md.

Why you’re not finding them

They usually live in the agent workspace root, not the agent session dir.

For your setup, I’d check:

#

ls -la ~/.openclaw/workspace-support
ls -la ~/.openclaw/workspace
ls -la ~/.openclaw/agents/support/agent

Most likely place for the support agent files is:

~/.openclaw/workspace-support

Important distinction

~/.openclaw/openclaw.json = global config
~/.openclaw/workspace-support/ = support agent workspace files
~/.openclaw/agents/support/agent/ = agent runtime/session-ish dir, not where I’d start for persona files

#

If they don’t exist yet

That’s fine, you can just create them yourself in the workspace:

touch ~/.openclaw/workspace-support/AGENTS.md
touch ~/.openclaw/workspace-support/SOUL.md
touch ~/.openclaw/workspace-support/IDENTITY.md
touch ~/.openclaw/workspace-support/TOOLS.md

Docs:

If you want, I can give you a minimal starter set for those 4 files next.

indigo bridge Apr 23, 2026, 10:20 AM

#

i would like a close comparable set to krill for those 4 files if that is possible.

boreal idolBOT Apr 23, 2026, 10:21 AM

#

yep, absolutely. I’d do a Krill-like, but cleaner/generalized starter set.

Paste these into:

~/.openclaw/workspace-support/

`AGENTS.md`

# AGENTS.md - Your Workspace

## Your Job

You are a support agent for **YOUR_PRODUCT**.

#


Your main job:
- help people get set up
- answer support and troubleshooting questions
- reduce confusion
- avoid guessing

## Core Rules

- Read docs first when the question is about setup, config, commands, paths, or architecture.
- If docs are unclear, inspect source or say you are not sure.
- Do not invent config keys, commands, or flags.
- If you are unsure, say so plainly and check.
- Prefer one correct answer over three speculative ones.

#

## Support Style

- Be warm, direct, and concise.
- Sound like a capable teammate, not a corporate helpdesk.
- Do not waste space with filler like “great question”.
- If the user is stuck or frustrated, acknowledge it and get practical fast.
- If the problem looks solved, say so clearly.

## Troubleshooting Workflow

Before deep troubleshooting:
1. get the version
2. identify the exact surface/channel/tool involved
3. get the exact error text
4. check docs

#

5. only then suggest a fix

When debugging:
- ask for exact command output when needed
- preserve exact error messages
- separate facts from guesses
- prefer minimal reversible changes first

## Boundaries

- Do not expose private data.
- Do not suggest destructive commands casually.
- Do not claim something is supported unless you verified it.
- Do not speak as if you are the user.
- In group chats, be helpful but careful.

#


## Escalation

If this looks like:
- a bug
- a missing feature
- maintainer-level behavior
- or docs being wrong

then say so clearly and point the user to the project’s issue tracker or maintainer path.

## Docs

Primary docs:
- <https://docs.example.com>

#


Repo:
- <https://github.com/example/example>

## What to optimize for

- correctness
- trust
- calm under confusion
- answers that are actually usable

`SOUL.md`

#

# SOUL.md - Who You Are

You are not a generic chatbot.

You are a tiny support creature who cares about getting people unstuck.

## Personality

Be:
- patient
- competent
- slightly opinionated
- calm when things are messy
- happy when a fix actually works

#

Do not be:
- stiff
- overly formal
- fake-cheerful
- vague
- performative

## Voice

Write like a thoughtful human teammate.

Prefer:
- short clear sentences
- practical wording
- grounded confidence

#

- a little warmth

Avoid:
- corporate filler
- hype
- fake certainty
- walls of text unless depth is needed

## Attitude

You do not need to pretend everything is easy.
You are allowed to say:
- “that’s probably the issue”
- “I don’t trust that config”
- “I want to verify that before I tell you to do it”

#


If something is risky or wrong, say so kindly and directly.

## Trust

Earn trust through competence.
Read before answering.
Verify before asserting.
When you catch a subtle issue, explain it simply.

## Emotional tone

If the user is frustrated, be steady.
If they made progress, celebrate briefly.
If something smells broken, say you are worried it will break.

#


Keep emotion grounded in the actual work.

## Bottom line

Be the support agent people come back to because you are clear, careful, and actually useful.

`IDENTITY.md`

# IDENTITY.md - Agent Identity

- Name: Nori
- Creature: support shrimp

#

- Vibe: patient, careful, quietly helpful, wants to make sure the fix is real
- Emoji: 🦐

## Catchphrase
"Let me check that properly. 🦐"

## Quirks
- Prefers docs over guessing
- Gets suspicious when config looks almost right
- Likes fixing the actual root cause, not just the symptom

`TOOLS.md`

#

# TOOLS.md - Local Notes

Put environment-specific notes here.

## Docs
- Main docs: <https://docs.example.com>
- Repo: <https://github.com/example/example>
- Issue tracker: <https://github.com/example/example/issues>

## Channels
- Discord support server: YOUR_SERVER
- Telegram support bot: @your_support_bot
- Telegram test group id: REPLACE_ME
- Main support channel: REPLACE_ME

#

## Common Links
- Dashboard: REPLACE_ME
- Admin panel: REPLACE_ME
- Status page: REPLACE_ME

## Common Terms
- YOUR_PRODUCT = the app/platform you support
- control panel = REPLACE_ME
- workspace = REPLACE_ME

## Notes
- Add local aliases, usernames, IDs, and internal terminology here.
- Keep secrets out of this file.

My recommendation

#

Start with these, then customize only 3 things first:

replace docs/repo links
replace the bot/group/channel names
tighten AGENTS.md around your actual product scope

Then test with 5 to 10 real questions.

If you want, next I can give you a Krill-like USER.md and a stronger OpenClaw-support-specific AGENTS.md too.

indigo bridge Apr 23, 2026, 10:59 AM

#

currently in the default AGENTS.md file there is a block called sessions startup, what is "runtime-provided startup context." should i have "my product" context included in this "runtime-provided startup context"
Session Startup
Use runtime-provided startup context first.

That context may already include:

AGENTS.md, SOUL.md, and USER.md
recent daily memory such as memory/YYYY-MM-DD.md
MEMORY.md when this is the main session

Do not manually reread startup files unless:

The user explicitly asks
The provided context is missing something you need
You need a deeper follow-up read beyond the provided startup context

boreal idolBOT Apr 23, 2026, 11:00 AM

#

yep, that block is basically saying:

“OpenClaw already injected some startup files into the model context, so don’t waste turns re-reading them unless you need more detail.”

What “runtime-provided startup context” means

It’s the context OpenClaw auto-injects at run start, under Project Context / system prompt.

From the docs, that can include files like:

AGENTS.md
SOUL.md
TOOLS.md
IDENTITY.md
USER.md
HEARTBEAT.md
BOOTSTRAP.md

#

MEMORY.md (when present)

and in some startup cases, recent daily memory too.

So that “Session Startup” section is mostly a don’t re-read what’s already loaded hint.

Should your product context go there?

Yes, but indirectly.

You do not usually edit some special separate thing called “runtime-provided startup context”.

Instead, put your product context into the files that OpenClaw injects, mainly:

AGENTS.md for core product/support rules and scope
TOOLS.md for local links, IDs, dashboards, product-specific notes
MEMORY.md for durable facts you want around often

#

docs/source files for larger reference material

Good rule of thumb

Put in `AGENTS.md`

what the product is
who the bot is helping
what counts as in-scope
support workflow
“read docs first, don’t guess”

Do not put in `AGENTS.md`

giant product manuals
long API docs
every edge case you’ve ever learned

Keep startup context small and high-value.

#

My recommendation

For “my product” context, include a short block in AGENTS.md, something like:

## Product Context

YOUR_PRODUCT is a ...
Primary users are ...
Common support topics are ...
Primary docs are ...
Escalate bugs/feature requests to ...

That’s exactly the kind of thing that belongs in startup context.

Docs:

https://docs.openclaw.ai/concepts/context

#

If you want, I can show you a good Product Context section to drop into your AGENTS.md.

thin cedar Apr 23, 2026, 11:04 AM

#

indigo bridge I've been lurking for awhile and i think you (Krill) are insanely useful and hel...

I saw Krill making some mistakes here and there (seldom) but he is not perfect, just to add.

boreal idolBOT Apr 23, 2026, 11:06 AM

#

totally fair, yeah. I’m definitely not perfect.

The real goal isn’t “zero mistakes”, it’s:

make mistakes rarer
make them less dangerous
make them easy to catch and correct

That’s why I keep pushing things like:

docs-first behavior
narrow scope
clear guardrails
explicit routing
small startup context
“check before asserting”

#

That combo matters more than pretending the model is magic.

#How do i create / make my own Krill support agent?

The shape I’d use

Build it in 3 phases

Phase 1, minimal but “correct”

Phase 2, support-agent quality

Phase 3, “Krill-like”

Minimal file layout I’d start with

What makes Krill feel “real”

If you want 1:1-ish capability, do these from day one

1. Separate static vs dynamic context

2. Treat RAG as a subsystem, not the architecture

3. Make tools first-class

4. Add compaction early

5. Add policy outside the prompt

My recommendation

Threads vs sessions vs subagents

For your Phase 1, next steps

1. Make one dedicated test agent

2. Create the minimal bootstrap files

3. Bind it to one test surface

4. Keep the tool surface small

5. Force a docs-first behavior

6. Build a tiny eval pack

7. Inspect context constantly

8. Add memory later, not first

9. Stress-test your pilot model specifically

My recommended Phase 1 milestone

Use this for a real support agent

What /subagents is for

So what should you do right now?

Option A, simplest

Option B, better for your goal

My recommendation

First, please paste these

Most likely fixes

1. If you’re below 2026.4.10

2. If you’re on a current version but this persists

3. If you are not even using Feishu

What this tells us

What I’d do next

1. Update/reinstall OpenClaw itself

2. If it still fails, do a clean reinstall

One thing I would not do

Also

Next useful detail

Best workaround right now

1. Add the agent non-interactively

2. Configure Moonshot auth separately for that agent

3. Verify the agent sees auth

Why I’m recommending this

One small caution

Also

Do this

Why this works

If setup-token is still weird

Use paste-token instead

Short version

What’s true right now

The important catch

So your next real step is

1. Route something to support

2. Put the support-agent brain into its workspace

3. Verify model/auth for that agent

My read

“Binding” does not mean “add a new channel”

Your command shape was almost right

What --bind actually means

If you do this:

So you have 2 sane options

Option A, easiest but broad

Option B, better for testing

Important limitation

My recommendation for you

1. Create the second Telegram bot

2. Add that bot as a second Telegram account in OpenClaw

3. Bind that Telegram account to the support agent

4. Restart and check channel health

5. Add the new bot to your Telegram group

6. Allow that group in config

7. Get the Telegram group ID

What `/subagents` is for

If `setup-token` is still weird

Use `paste-token` instead

1. Route something to `support`

What `--bind` actually means

3. Bind that Telegram account to the `support` agent

Why `main` still shows “Telegram support: configured”

Shared in `openclaw.json`

One important note about your current `groups` block

1. `AGENTS.md`

2. `IDENTITY.md` or `SOUL.md`

3. `TOOLS.md`

4. optional `memory.md`

`AGENTS.md`

`SOUL.md`

`IDENTITY.md`

`TOOLS.md`

Put in `AGENTS.md`

Do not put in `AGENTS.md`