For technical buyers and curious builders

The button is simple because the backend is not.

JimsBots separates the client experience from the operational machinery. The user gets one-button access. The provider gets session control, memory, audit trails, tool orchestration, approvals, execution policy, and monitoring.

System shape

1. Button layer
Voice, phone, shortcut, web, or message capture.
2. Mercury
Realtime session management, transcripts, conversations, ActionDrafts, approvals, SidecarEvents, and per-agent settings.
3. OpenClaw
Reasoning, tool use, memory, background workers, human-in-the-loop escalation, and provider operations.
4. Tools
Email, calendar, docs, shopping, research, reminders, calls, and client-specific integrations.

Why split Mercury and OpenClaw?

Mercury is the control plane for live interactions. It keeps auditable state: who asked, what was heard, what was drafted, what needs approval, and what happened next.

OpenClaw is the intelligent orchestration layer. It reasons over tasks, invokes tools, coordinates subagents, watches queues, and gives the service provider an advanced management surface.

Approval-gated execution

The core trust boundary is the ActionDraft. The agent can prepare a draft, but external side effects require explicit approval.

  • Safe prep: summarize, research, draft, plan, remind.
  • Approval required: send, buy, schedule, call, share, cancel, submit, pay.
  • Execution is logged as a state transition with provider, result, and audit event.

Voice and realtime

For browser voice, JimsBots uses WebRTC-style realtime sessions with short-lived credentials minted server-side. Secrets stay off the client. Phone or telephony flows can use WebSocket media streams where appropriate.

Voice is not the whole product. It is the capture layer. The durable product is the task state and approval loop behind it.

Reference flow

User presses Talk
  -> Browser opens realtime voice session
  -> Mercury records session and state
  -> Agent prepares a request as an ActionDraft
  -> Dashboard/phone prompt asks for approval
  -> Approved draft enters execution boundary
  -> OpenClaw worker performs safe/internal or approved external action
  -> Mercury records result and reports back

Provider controls

  • Per-client agent profiles and prompts
  • Tool allowlists and approval policy
  • Memory and task history
  • Execution queues and failure review
  • Human review and retraining notes
  • Client-specific integrations

Current build direction

The first production shape is deliberately conservative: one-button capture, realtime voice, Mercury state, approval drafts, simulated execution, and OpenClaw worker contracts. Real external actions are added only after the approval and review model is stable.

See service plans