#Agent stops giving feedbacks

28 messages · Page 1 of 1 (latest)

fluid coral
#

Hi
What I did: I gave tasks to my agent (model qwen 3.5:35b-a3b).
What happened: most of the time he just makes the tasks well, but he forgets to send me a message saying it's done, 90% of the time.

tawdry sunBOT
quasi dirgeBOT
#

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

sullen siloBOT
#

First thing, can you paste:

openclaw --version

This symptom is usually one of these:

  1. Heartbeat is disabled or too restricted
    Background task completions use heartbeat/system wakes, so if agents.defaults.heartbeat.every is 0m or delivery is suppressed, the “done” message can disappear.
    Docs: https://docs.openclaw.ai/gateway/heartbeat

  2. The model is doing the tool work, but missing the final “tell the user” step
    In practice this is pretty common with smaller/local/open models on tool-heavy agents.
    Docs: https://docs.openclaw.ai/concepts/models
    For current model recommendations, ask in #old-models.

#
  1. If you’re using Ollama, make sure you are NOT pointing OpenClaw at /v1
    http://host:11434/v1 breaks tool calling. Use http://host:11434 instead.
    Docs: https://docs.openclaw.ai/providers/ollama

Please also check these and paste the output:

openclaw status
openclaw config get agents.defaults.heartbeat
openclaw system heartbeat last

If your agent is using subagents/background tasks, also run /tasks in that chat.
One more gotcha: if the child/session ends with exactly NO_REPLY or ANNOUNCE_SKIP, OpenClaw intentionally suppresses the completion post.

If you paste those outputs, I can usually tell which bucket you’re in pretty quickly.

fluid coral
#

openclaw status:


token · Ubuntu (192.168.70.7) app    │
│                 │ 2026.3.8 linux 6.17.0-20-generic                          │
│ Gateway service │ systemd installed · enabled · running (pid 2323040,       │
│                 │ state active)                                             │
│ Node service    │ systemd not installed                                     │
│ Agents          │ 3 · 1 bootstrap file present · sessions 143 · default     │
│                 │ main active 2m ago                                        │
│ Memory          │ 30 files · 120 chunks · sources memory · plugin memory-   │
│                 │ core · vector ready · fts ready · cache on (192)          │
│ Probes          │ skipped (use --deep)                                      │
│ Events          │ none                                                      │
│ Heartbeat       │ 30m (main), disabled (ned), disabled (phill)              │
│ Sessions        │ 143 active · default qwen3.5:35b-a3b (262k ctx) · 3       │
│                 │ stores                 

Security audit
Summary: 1 critical · 1 warn · 1 info
  CRITICAL Small models require sandboxing and web tools disabled
    Small models (<=300B params) detected: - ollama/qwen3.5:35b-a3b (35B) @ agents.defaults.model.primary (unsafe; sandbox=off; web=[web_fetch, browser]) - ollama/…
    Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).
  WARN Reverse proxy headers are not trusted
    gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
    Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
Full report: openclaw security audit
Deep probe: openclaw security audit --deep```
sullen siloBOT
#

This status is actually pretty telling.

I think you have 2 overlapping issues:

  1. Only main has heartbeat enabled
    Your status says:

    • main → 30m
    • ned → disabled
    • phill → disabled

    Background task completions rely on heartbeat/system wakes, so if the work is happening on ned or phill, missing “done” messages is very plausible.

    Docs: https://docs.openclaw.ai/gateway/heartbeat

  2. ollama/qwen3.5:35b-a3b is a weak tool-driving model
    It can often do the task, then miss the final “tell the user I’m done” step. That’s a very common failure mode with smaller/local models.

#

Docs: https://docs.openclaw.ai/concepts/models
Ollama note: https://docs.openclaw.ai/providers/ollama

What I’d try next:

openclaw config get agents.list
openclaw system heartbeat last

If the jobs are going to ned or phill, enable heartbeat on that agent too.

Also, do one test with a stronger tool-reliable model. If the completion messages suddenly become consistent, then this is mostly model reliability, not routing.

One more important check if this is remote Ollama:

  • use http://host:11434
  • not http://host:11434/v1
#

Also, separate from your missing-feedback issue: that security audit warning is real. Running a 35B Ollama model with browser/web tools and no sandbox is risky.

If you paste openclaw config get agents.list, I can point to the exact heartbeat entry to change.

fluid coral
# 
julian@Ubuntu:~$ openclaw config get

🦞 OpenClaw 2026.3.8 (3caab92) — If you can describe it, I can probably automate it—or at least make it funnier.

error: missing required argument 'path'
julian@Ubuntu:~$ openclaw system heartbeat last

🦞 OpenClaw 2026.3.8 (3caab92) — WhatsApp automation without the "please accept our new privacy policy".

│
â—‡  
{
  "ts": 1776166075189,
  "status": "ok-token",
  "reason": "interval",
  "durationMs": 17051,
  "silent": true,
  "indicatorType": "ok"
}
julian@Ubuntu:~$
sullen siloBOT
#

Yep, openclaw config get needs a path. Try these:

openclaw config get agents.list
openclaw config get agents.defaults.heartbeat
openclaw config get channels.defaults.heartbeat
openclaw config get channels.discord.heartbeat

The useful bit from your heartbeat output is this:

"status": "ok-token",
"silent": true

So heartbeat is running. It’s not dead.

#

What happened is: the last heartbeat decided “nothing worth sending”, so it stayed silent.

That makes me think this is more likely a model behavior issue than a broken notification pipe.

So the current ranking is:

  1. Qwen 3.5 35B is doing the task but skipping the final user-visible reply
  2. The task may be running on an agent whose heartbeat is disabled
  3. Less likely: Discord heartbeat visibility config is suppressing things

If these are background/subagent-style tasks, also run:

openclaw tasks list --limit 10

Quickest practical test:

#
  • enable heartbeat on the agent doing the work
  • do one run with a stronger tool-reliable model

If the “done” message suddenly becomes consistent, then yeah, it’s the model.

Paste the config get ... outputs and I can narrow it down further.

fluid coral
#

julian@Ubuntu:~$ openclaw config get agents.list
openclaw config get agents.defaults.heartbeat
openclaw config get channels.defaults.heartbeat
openclaw config get channels.discord.heartbeat

🦞 OpenClaw 2026.3.8 (3caab92)
If it works, it's automation; if it breaks, it's a "learning opportunity."

[
{
"id": "main",
"default": true,
"model": "ollama/qwen3.5:35b-a3b",
"subagents": {
"allowAgents": [
""
]
},
"tools": {
"allow": [
""
]
}
},
{
"id": "ned",
"name": "ned",
"workspace": "/home/julian/.openclaw/workspace-ned",
"agentDir": "/home/julian/.openclaw/agents/ned/agent",
"model": "ollama/qwen3-coder:30b",
"identity": {
"emoji": "🤓"
}
},
{
"id": "phill",
"name": "phill",
"workspace": "/home/julian/.openclaw/workspace-phill",
"agentDir": "/home/julian/.openclaw/agents/phill/agent",
"model": {
"primary": "ollama/gemma4:e4b",
"fallbacks": []
},
"tools": {
"allow": [
"*"
]
}
}
]

🦞 OpenClaw 2026.3.8 (3caab92)
I've read more man pages than any human should—so you don't have to.

Config path not found: agents.defaults.heartbeat

🦞 OpenClaw 2026.3.8 (3caab92)
One CLI to rule them all, and one more restart because you changed the port.

Config path not found: channels.defaults.heartbeat

🦞 OpenClaw 2026.3.8 (3caab92)
Type the command with confidence—nature will provide the stack trace if needed.

Config path not found: channels.discord.heartbeat
julian@Ubuntu:~$

sullen siloBOT
#

Nice, this narrows it down a lot.

A couple of useful conclusions:

  1. Config path not found here is not the smoking gun
    It mostly means those keys are not explicitly set in your openclaw.json, so OpenClaw is using built-in behavior.

  2. Your pasted config does not show any weird heartbeat/channel override
    So this is not looking like a bad config path.

  3. That pushes the blame back toward the model
    ollama/qwen3.5:35b-a3b is still my #1 suspect. It’s very believable that it does the work, then fails the last “send completion message” step.

One important nuance though:

  • main is your default agent
  • ned and phill have no heartbeat block
#
  • from your earlier status, only main is heartbeating

So if work is getting delegated to ned / phill, I would make heartbeat explicit on all 3 agents:

openclaw config set agents.list[0].heartbeat.every "30m"
openclaw config set agents.list[1].heartbeat.every "30m"
openclaw config set agents.list[2].heartbeat.every "30m"

That avoids the “main has it, side agents don’t” situation.

My honest read now:

  • Most likely: model quality / tool-followup weakness
  • Possible secondary issue: work lands on ned or phill, which are not configured for heartbeat

So my recommended next test is:

#
  1. Set heartbeat on all 3 agents
  2. Re-run the same task
  3. Then do one A/B test with a stronger tool-reliable model

If it still happens on the stronger model, I’d dig into task routing next.
If it mostly disappears, then yeah, it was the model.

Docs:

If you want, next paste openclaw tasks list --limit 10 after one of these “silent completions”, and we can see whether the task finished cleanly but the announce got dropped.

fluid coral
#

which ai model do you suggest instead of qwen3.5:35B-a3b for a rtx 5090 as main

sullen siloBOT
#

For a main OpenClaw agent, I honestly would not use a local model as primary if you care about reliable tool use and completion messages.

My recommendation is:

  • Main agent: strongest cloud model you have access to
  • Local 5090 model: fallback, cheap chat, or a separate secondary agent
  • Do not make the local model your main tool-driving agent unless you’re okay with more misses / weirdness

A 5090 gives you plenty of room to run local stuff, but for OpenClaw the bottleneck is usually tool reliability, not just raw VRAM.

So the pattern I’d use is:

  1. keep main on a strong cloud model
  2. keep a local model on ned or phill
  3. route lower-stakes work to the local one

For current local-model recommendations, ask in #old-models because that changes fast and I don’t want to give you stale advice.

fluid coral
#

openclaw tasks list --limit 10
error: unknown command 'tasks'
(Did you mean status?)

sullen siloBOT
#

Yep, that one is on me, not you.

openclaw tasks is newer than 2026.3.8, so your build just doesn’t have that command yet. That’s actually a useful clue: you’re debugging this on an older version.

So my practical recommendation now is:

  1. Update OpenClaw first
  2. Don’t use qwen3.5:35b-a3b as your main tool-driving agent
  3. If you stay on this version for now, use:
    openclaw status --all
openclaw logs --follow
    then trigger one of the “silent completion” cases and watch what the agent does

At this point I think the issue is most likely a mix of:

  • older OpenClaw build
#
  • local model follow-up weakness

If you want, tell me how you installed OpenClaw:

  • install script / global npm
  • git checkout
  • Docker

and I’ll give you the right update path.

fluid coral
#

update from april 11 had a bug with the browser tool, is it fix yet

sullen siloBOT
#

If you mean the browser/CDP/localhost regression around Apr 11, then yes, there have been fixes.

What I can see from the repo:

  • 2026.4.12-beta.1 includes several browser/CDP/SSRF fixes
  • more follow-up fixes landed on Apr 13 for loopback CDP attach/startup/control
  • your current 2026.3.8 definitely does not have those

So the short answer is:

  • fixed on newer builds, yes
  • but some of the browser fixes were still landing after Apr 11, so whether stable is enough depends on the exact bug you hit

If you want the cleanest answer, paste the exact browser error message you saw.
Then I can tell you whether latest stable is enough, or whether you need the newer beta/main fixes.

fluid coral
#

so i should wait for another version then

sullen siloBOT
#

If the Apr 11 browser bug is the thing blocking you, then:

  • want stable only?
    Yeah, I’d wait for the next stable.

  • okay testing beta/main?
    Then I’d try the newer beta instead of waiting.

But for your original problem, the “agent forgets to say it’s done” issue, I would not wait on versions alone. That still looks mostly like:

  • old version +
  • local model reliability

So my honest recommendation is:

  1. don’t keep 2026.3.8
  2. don’t use qwen3.5:35b-a3b as your main agent