Summary

In multi-agent OpenClaw deployments (per-user agents on Slack/Telegram/Discord), when any agent invokes the google_meet tool (action=join, create+joinAfterCreate, test_speech) or the voice_call tool (initiate_call), the outbound voice call is always routed to the single configured agent (voiceConfig.agentId ?? "main") instead of the agent that actually initiated the call. Every user hears the same main agent voice.

Reproduction

1. Deploy OpenClaw with multiple per-user agents (e.g., slack-u123, slack-u456).
2. User Alice (routed to slack-u123) asks the bot to join a Google Meet.
3. User Bob (routed to slack-u456) asks the bot to join a different Google Meet concurrently.
4. Both calls reach Twilio and respond with the same agent's voice/identity (main), not the per-user agent.

Root Causes (multiple, must all be addressed)

1. Static tool registration loses caller identity — extensions/google-meet/index.ts:993 and extensions/voice-call/index.ts:609 register tools via api.registerTool({...}) static-object form. The factory form api.registerTool((ctx) => ({...}), { name }) is required to capture ctx.agentId.
2. Cross-process gateway hop drops context — callGoogleMeetGatewayFromTool (google-meet/index.ts:449-470) hops via callGatewayFromCli (CLI bridge → WebSocket → gateway-rpc.runtime.js). Tool-side closures cannot reach the gateway handler. agentId must travel as a serialized RPC field.
3. Gateway handlers don't extract agentId — googlemeet.join (line 705-720), googlemeet.create, googlemeet.test_speech build rt.join(request) without agentId.
4. JoinMeetRequest / rt.join shape lacks agentId — extensions/google-meet/src/runtime.ts:351; same for joinMeetViaVoiceCallGateway at runtime.ts:443-468.
5. voicecall.start RPC handler doesn't accept agentId — extensions/voice-call/index.ts:581-606 reads only to/message/dtmfSequence/mode. initiateCallAndRespond (line 335-353) calls manager.initiateCall(to, undefined, {...}) with no agentId slot.
6. Three downstream sites read effectiveConfig.agentId, not call.agentId:
   • Webhook → response-generator: voice-call/src/webhook.ts:884 + response-generator.ts:214 (voiceConfig.agentId ?? "main").
   • Realtime consult lane fix: add @lid format support and allowFrom wildcard handling #1: voice-call/src/runtime.ts:348 (effectiveConfig.agentId ?? "main").
   • Realtime consult lane Login fails with 'WebSocket Error (socket hang up)' ECONNRESET #2: voice-call/src/runtime.ts:377 (same fallback).
   • Patching only response-generator silently leaves the realtime path (the dominant Google Meet voice path) broken.
7. voice_call tool itself has the same defect — extensions/voice-call/index.ts:635 initiate_call action calls rt.manager.initiateCall(to, undefined, {...}) with no agentId.

Impact

Proposed Fix (high-level)

Design invariant: resolve effective agentId exactly once at call creation, persist it on CallRecord, and consume call.agentId at every downstream site through a centralized helper. No optional-fallback chain at every hop.

1. Convert google_meet and voice_call tools to factory pattern with { name } opts (required by src/plugins/registry.ts:506-509 for factory-form name auto-derivation).
2. Inject ctx.agentId into the gateway-bound RPC payload at the dispatch boundary; thread it through googlemeet.{join,create,test_speech} handlers → JoinMeetRequest/Create/TestSpeech → rt.join → joinMeetViaVoiceCallGateway → voicecall.start RPC → manager.initiateCall → CallRecord.agentId.
3. Freeze the resolved agentId on inbound CallRecord at manager/events.ts:createWebhookCall (DID-route default, frozen at creation to prevent hot-reload drift).
4. Add extensions/voice-call/src/util/resolve-call-agent-id.ts with a single precedence helper: call.agentId || effectiveConfig.agentId || "main". Consume from webhook, both realtime consult lanes, and response-generator.
5. Construct per-meeting session keys (agent:${agentId}:google-meet:${session.id}) to prevent collisions on shared Twilio dial-ins (pattern reused from extensions/google-meet/src/agent-consult.ts:50-57).

Scope

~14 files across two extensions plus one new helper module:

• extensions/google-meet/: index.ts, src/runtime.ts, src/voice-call-gateway.ts
• extensions/voice-call/: index.ts, src/types.ts, src/manager/outbound.ts, src/manager/events.ts, src/webhook.ts, src/response-generator.ts, src/runtime.ts, new src/util/resolve-call-agent-id.ts

Plus unit tests (per-file) and one integration test driving the webhook → response-generator boundary.

Backward Compatibility

• CallRecord schema: new optional field, Zod strip-mode round-trip preserves old records.
• voicecall.start RPC: old handlers ignore unknown agentId/sessionKey params.
• Single-agent deployments: ctx.agentId === "main" (or undefined → falls through helper to config default → "main"). Identical pre-PR behavior.
• Mixed-version rolling upgrades: voice-call state is process-local (in-memory Map + per-pod calls.jsonl); during a rolling window, old-pod voicecall.start invocations silently drop the field and fall back to effectiveConfig.agentId. Uniform rollout recommended.

Related

• Google Meet tool-created realtime sessions can lose gateway ownership #72440 — Google Meet tool-created realtime sessions can lose gateway ownership (related ownership/identity plumbing)
• Google Meet: support reliable headless agent join with audio/transcription health checks #72478 — Google Meet headless agent join with audio/transcription health checks (closed)
• google-meet realtime sessions don't survive CLI command exit despite #72441 fix #76344 — google-meet realtime sessions don't survive CLI command exit (closed)

PR with full plan and detailed change set will follow shortly. Filed by quangtran88 from oneclaw/oneclaw.improvement for an OneClaw multi-agent deployment.