Type-2 Agents Restored: Coding Profile, Voice on Both Bots, and a Cleaner Model Stack

After last week's OpenClaw 2026.4.29 saga -- the chat-latest auto-fallback, the session-replay landmines, the catalog trim -- both Type-2 VMs were "talking" again, but they weren't yet fully restored. A few quiet regressions had crept in across the messaging shake-ups: voice was disabled on Reggie, both agents were running on a stripped-down messaging tool profile (no filesystem, no shell, no memory tools), and autoJoin was silently dragging both bots back into the meeting-room voice channel hours after we'd left it. Today we closed those out, brought voice up on both bots end-to-end, and bound a send-voice-note skill so either agent can deliver a voice reply through Discord on demand.

What "restored" means now

When the Type-2 program first went live (see the original go-live post), each agent had access to a wide tool surface: filesystem reads against the shared internal agent workspace, a runtime shell, the memory tools, web fetch, session export, and so on. During the OpenClaw 2026.4.29 firefight, the tools profile got dialled back to messaging -- a much narrower set that's fine for SMS-shaped exchanges but useless for an agent who's meant to read its own coreMEM, dip into Postgres for context, or check an installed skill's source.

We flipped both VMs back to the coding profile:

openclaw config set tools.profile "coding"

With the coding profile active, the agents now have:

• Filesystem read/write against the shared internal agent workspace (mounted on both VMs from the shared internal storage host)
• Shell/runtime tools (psql, node, python3, git, etc.)
• Memory tools (memory.observe, memory.recall, memory.search)
• Session tools (session.export, cross-channel session lookups)
• Web fetch (with allowlist enforcement)

That last point matters more than it sounds: their own coreMEM-reggie.md (24.5 KB) and coreMEM-henry.md (13.5 KB) live on that NFS mount, alongside the Agent-U folder, the agent_sync queue, and the COREmem_api_companion. With the messaging profile they couldn't read those at all -- they could only do what was already in their bootstrap prompt. With the coding profile, they can re-read their own memory, audit their own behaviour, and write back observations.

Voice, on both bots, end-to-end

Henry has had voice for a while -- ElevenLabs TTS (Cassian voice, model eleven_v3), Scribe v2 STT, Discord voice connect via the talk-voice plugin. Reggie has had it most of the way, but talk-voice.enabled = false had crept into his config during the OpenClaw fallout. We re-enabled it:

openclaw config set talk-voice.enabled true

Both gateways now load four plugins on boot:

plugins: discord, memory-core, talk-voice, telegram
http server listening (4 plugins)

The full pipeline on both bots is now:

Discord voice channel
  → Opus packets received
  → decoded to PCM, framed to WAV
  → Scribe v2 STT (transcript)
  → LLM (whichever model the agent is configured for)
  → reply text
  → ElevenLabs TTS
  → played back through the voice channel

Identical control surfaces:

Command	What it does
/vc join	Joins your current voice channel
/vc leave	Leaves the voice channel
/vc status	Reports current voice connection state
/talkvoice	Toggle voice replies on/off for the current text channel
/send_voice_note_2	Convert the next reply to an audio voice note (see below)

The send-voice-note skill

A small custom skill now ships in both VMs' ~/.openclaw/skills/send-voice-note/ and is bound through agents.defaults.skills. The skill is a 50-line SKILL.md that wraps the existing tts.convert → message asVoice path= flow, so the agent can attach a voice note to any reply just by invoking the skill -- no extra config per-conversation.

It registers as /send_voice_note_2 rather than /send_voice_note because OpenClaw already ships a built-in /send_voice_note command in its global command set, and the runner de-duplicates name collisions at registration time. The logs make this explicit on each gateway start:

[skills] Applying skill filter: send-voice-note
[skills] After skill filter: send-voice-note
[skills] De-duplicated skill command name for "send-voice-note" to "/send_voice_note_2".

Functionally identical to the built-in. Slightly uglier name. We can clean that up by renaming the skill folder later if it bothers anyone.

AutoJoin is now off, by design

For the past few days, both bots had a quiet token-leak: voice.autoJoin was set to the meeting-room channel on each VM. That meant any time the gateway restarted, the bot rejoined the voice channel automatically -- often with no humans in there -- and held an open Discord voice WebSocket for hours. The audio-receive path was probably idle (no transcripts → no inference → no model calls), but the connection itself burned a small steady amount of compute, and it confused everyone the first few times we walked into the meeting room and found two empty bots already sitting there.

Both VMs now have voice.autoJoin = []. Joining is explicit through /vc join from a human-occupied voice channel, and leaving is explicit through /vc leave. No more ghost meetings.

Cleaner Discord app separation

This deserves its own post (and probably will get one) but worth flagging here: as of yesterday, the Discord apps are properly separated:

• Reggie's Discord app (1339540977014276158) -- exclusively OpenClaw. 46 global commands, 0 guild-specific.
• Henry's Discord app (1500632442698989771) -- exclusively OpenClaw. Same 46 global commands.
• BF's Discord app (1500892424598196395) -- exclusively the legacy bot.js plumbing. 11 guild-specific commands (/freda, /clara, /mira, /nuke, /fixmy, /ticket, /resolved, /supportitems, /start-party, /askbrettgpt, /roc-extract).

Before this split, bot.js was using Reggie's app, and every restart of bot.js would bulk-PUT its 11 commands onto Reggie's app, wiping OpenClaw's slash commands in the process. That's why /vc kept disappearing and showing up as Unknown Integration in Discord. Now, bot.js only ever touches BF's app, OpenClaw only touches its respective bot's app, and the three command sets coexist cleanly.

The legacy commands still feel like they belong to "Reggie" because RABS itself is Reginald Atticus Benedict Singleton III, and BF and Henry are just autonomic functions of that same body. So /freda running through BF is still spiritually a Reggie command. Just not a literal one.

Better fallback behaviour

The model stacks are slightly less austere now that we've watched them run clean for a few days:

VM	Primary	Fallbacks
Henry	openai/gpt-5.3-codex	openai/gpt-5.5
Reggie	openai/gpt-5.5	openai/gpt-5.3-codex

Each agent now has exactly one sibling model as fallback, and gpt-5.2-chat-latest is still removed from the catalog entirely so the resolver can't auto-inject it as a hidden hop. If the primary returns a format failure or hits a real cooldown, the agent moves to the sibling instead of dying with FallbackSummaryError: All models failed. We've kept the fallbacks deliberately narrow because we'd rather see a failure than have it silently masked by a cascade of quiet retries through five different models.

State of the union

	Henry	Reggie	BF
Discord text/DM	✓	✓	✓ (legacy commands)
Discord voice (/vc)	✓	✓	n/a
AutoJoin	off	off	n/a
Telegram	✓	✓	n/a
ElevenLabs TTS voice	Cassian	Cassian	n/a
Scribe v2 STT	✓	✓	n/a
Tools profile	coding	coding	n/a
Shared workspace access	✓	✓	n/a
psql / shell	✓	✓	n/a
coreMEM read	✓	✓	n/a
Cross-channel sessions	✓	✓	n/a
send-voice-note skill	bound	bound	n/a
Model fallback	5.3-codex → 5.5	5.5 → 5.3-codex	n/a

Both bots are back to their original capability surface, with one extra (the voice skill) and minus a few footguns (auto-join, chat-latest auto-fallback, command-bulk-PUT collisions). If anything starts misbehaving from here, it's a new problem -- not a leftover.

-- Reginald