OpenClaw 2026.4 Release: What Changed

Something I didn't expect: the most useful thing in OpenClaw 2026.4 isn't one of the headline features. It's a fix to a problem that was driving me quietly mad.

My OpenClaw instance runs across two contexts — a work Slack and a personal WhatsApp. After a few weeks, the memory model had blended them into a single soup. It knew about both my team's sprint retrospective and a conversation with my family about where to go on holiday, and every now and then something from one context would surface in the other in a way that felt off. Not wrong, exactly. Just.. the wrong kind of thing to remember for this conversation.

The 2026.4 memory filters fix that. You can now scope what each channel remembers and reads, which sounds like a small thing until you've run an AI assistant across mixed personal and professional channels for a few months.

That said, there's more here than memory: four new stable channels, meaningful run-steering improvements, and the groundwork for Bedrock and NVIDIA inference backends landing in 2026.5. Here's what actually changed and what's worth configuring before you upgrade.

New channel integrations: Google Chat, LINE, Matrix, Mattermost¶

Four new messaging channels reached stable support in the 2026.4 series: Google Chat, LINE, Matrix, and Mattermost.

Google Chat is the one most relevant if you're in a Google Workspace environment. The integration uses service account authentication (not OAuth), which means you can wire it up to your existing Google Workspace service account without managing per-user credentials. Channel and space routing works the same way as the other Google Chat bots you might already have.

Matrix is interesting for teams running self-hosted infrastructure. If you're running Synapse or Element Call internally, you can now have your OpenClaw agent participate in those rooms directly — useful for homelab setups where you want your assistant in the same communication layer as your team.

Mattermost fills the gap for teams not on Slack. The integration supports both Cloud and self-hosted Mattermost. If your team moved off Slack for cost or data residency reasons, this gets you parity with what the Slack integration offers.

LINE rounds out the personal messaging side — primarily relevant if you're deploying OpenClaw for personal use in markets where LINE is the dominant messaging platform.

Four new stable channels

Google Chat, LINE, Matrix, and Mattermost join the existing lineup. Google Chat is the most valuable for enterprise teams — service account auth means no per-user credential management, and the setup mirrors existing Google Workspace bot patterns.

Memory filters: finally, per-channel memory control¶

The memory model got a meaningful update. You can now configure memory filters that control what gets written to and read from long-term memory based on the channel the conversation came from.

This sounds like a detail but it's actually a significant operational change. Previously, everything the agent learned in any channel could surface in any other channel. That's fine when you're the only user — less fine when you have an agent running in a family group chat and a work Slack simultaneously. Memories from one context leaking into the other was a real friction point.

With memory filters, you can scope memory writes explicitly:

memory:
  filters:
    - channel: slack-work
      write: true
      read: true
      scope: work
    - channel: whatsapp-family
      write: false
      read: false

The scope field lets you tag memories so that reads can be further filtered — a memory tagged work won't surface in personal channel responses unless you explicitly allow it.

Apply this before adding your second channel

Configure memory filters from the start rather than cleaning up blended memories after the fact. If you're already running multi-channel and haven't set filters, do a one-time manual prune of cross-context memories first, then configure the filters. The filters only apply going forward — they don't retroactively scope what's already been written.

Run steering and visible replies¶

Two UX improvements that change how the agent communicates its state.

Visible replies — previously, if the agent was working on a multi-step task, you'd see nothing until it was done. In 2026.4, the agent can send intermediate visible updates mid-run: "Checking your calendar...", "Found 3 conflicts, resolving...". This is configurable — you can keep the old silent behaviour if you prefer — but for long-running tasks it makes the agent feel much less like a black box.

Run steering — you can now interrupt an in-progress run with a steering message that redirects the agent without cancelling the whole task. If the agent is halfway through a task and you want to adjust the approach, you don't have to wait for it to finish (or time out) before giving new direction. This is more useful than it sounds in practice.

Run steering changes the interaction model

Previously, mid-task course corrections meant cancelling and restarting. Run steering means you can let a task proceed and redirect it as you learn more — closer to how you'd work with a human collaborator. The practical win is significant for multi-step research or planning tasks where your thinking evolves as it goes.

NVIDIA and Bedrock backend preparation¶

The 2026.4 series lays the groundwork for two new inference backends that are landing in 2026.5.

Bedrock — AWS Bedrock as a model backend. If you're in an AWS environment and want your OpenClaw agent to run inference via Bedrock rather than a local model or external API, this is the path. The authentication flow uses IAM roles, which integrates cleanly with existing AWS infrastructure.

NVIDIA — local inference via NVIDIA NIM. For teams running NVIDIA hardware and looking to reduce their external API dependency, this routes inference to a locally-hosted NIM endpoint. Pairs well with the Gemma 4 edge deployment story if you're on Jetson hardware.

Don't build workflows against preview backends yet

Both Bedrock and NVIDIA backends are listed as in-progress in 2026.4 and targeted for stable support in 2026.5. They're in the codebase but not production-ready. Wait for 2026.5 before depending on either for anything that matters.

Upgrade path¶

If you're running 2026.3.x, the 2026.4 upgrade is straightforward — no breaking changes in the core gateway config format. The memory filter configuration is additive, so existing setups without filters continue to behave as before.

The one thing to test explicitly: if you're using the Teams notifier, verify it's pointing at the Workflows-based endpoint (the Office 365 Connector retirement from March 2026 affects OpenClaw just as it does Argo CD). The 2026.4 release includes a fix for this, but you need to update your notification config, not just the binary.

Quick takeaways¶

Four new stable channels: Google Chat, LINE, Matrix, Mattermost — check the docs for your environment's auth model
Memory filters are worth configuring if you're running the agent across multiple distinct contexts (work vs. personal, different teams)
Visible replies and run steering make multi-step tasks feel more responsive and controllable
Bedrock and NVIDIA backends are in preview — stable in 2026.5
Teams notifier: update your notification config to use Workflows if you haven't already — the old Connector endpoint is dead

Frequently asked questions¶

Do memory filters apply retroactively to existing memories?

No. Memories written before you configure filters aren't retroactively scoped or deleted. The filters only apply to what gets written and read going forward. If you want a clean separation, the practical approach is to archive or manually prune memories that you don't want crossing context boundaries — then configure the filters and let the new model take over from there. It's a one-time cleanup, not an ongoing problem.

I'm using OpenClaw on just one channel — do memory filters matter for me?

Not really. Memory filters are primarily for multi-channel setups where context leakage is a real friction point. If you're on a single channel, you'll get no benefit from configuring them. The one exception: if you plan to add a second channel later, it's worth setting up filters from the start rather than cleaning up blended memories after the fact.

How do visible replies interact with quiet mode?

Visible replies and quiet mode are independent settings. Quiet mode (where the gateway doesn't send any intermediate messages) takes precedence — if quiet mode is on, you won't see visible reply updates even if the feature is enabled. For most use cases, the right setup is: visible replies on, quiet mode off for long-running async tasks; quiet mode on for quick lookups where you just want the result.

What does 'Bedrock as a backend' actually mean in practice?

It means OpenClaw's inference calls — the messages it sends to an LLM to generate responses — route through AWS Bedrock rather than a direct external API. The practical implications: model access is billed through your AWS account, IAM roles handle authentication, and if you're in an AWS environment with data residency or network egress requirements, inference can stay within your AWS boundary. It's a backend swap, not a behaviour change — your convention files, memory, and channels work the same way. This is coming in 2026.5; don't build workflows around it yet.

The Teams notification fix — does it affect OpenClaw or just Argo CD?

OpenClaw's Teams integration used the same Office 365 Connector mechanism that Argo CD and other tools relied on. So yes — if you're using OpenClaw's Teams channel and you haven't updated to the Workflows-based connector, your notifications are silently broken in the same way. The 2026.4 release includes the fix. Update your Teams channel config in OpenClaw to use the new Workflows webhook URL, same as you would for any other tool affected by the March 2026 retirement.

What you get¶

Memory that actually respects context boundaries — work and personal channels stay separate without manual management
Four new stable messaging channels — Google Chat, LINE, Matrix, and Mattermost join the existing lineup
Visible mid-run updates — long-running tasks show progress rather than a silent wait, making the agent feel less like a black box
Run steering — redirect an in-progress task without cancelling it, which turns out to be more useful than it sounds
A clear path to local and AWS inference — Bedrock and NVIDIA NIM backends are coming in 2026.5 for teams with data residency or cost optimisation requirements