Where RapidClaw goes next.

RapidClaw is being built around a clear operating model:

• a customer-owned runtime deployed into the customer's Azure subscription
• Dataverse as the control boundary for policy, state, and auditability
• RapidClaw Command Center as the primary administrative surface
• Microsoft Teams as the primary end-user interaction surface
• safe-by-default deployment, with explicit activation of live behaviors
• prerequisite checks before long-running deployment begins

The roadmap below is about strengthening that model, making it easier to operate, and improving confidence in day-to-day use.

Beyond the immediate fixes above, the next productization work falls into several clear tracks.

3.1 Day-2 administration

RapidClaw needs stronger day-2 operational workflows in RapidClaw Command Center.

Focus areas

• agent roster management
• configurable customer-facing agent display names during initial setup while keeping stable internal agent IDs
• customer-specific agent instructions, motion templates, and operating playbooks that can be adapted without assuming RapidClaw's own internal sales process
• clearer enable/disable and activation flows
• clearer separation between core agent setup and optional email/mailbox operations
• deeper progress visibility for long-running agent setup subphases
• safer editing of instructions and operating behavior
• better visibility into what is provisioned versus what is live

3.2 Runtime durability

The runtime is already useful, but it still needs a more explicit and inspectable execution model.

Focus areas

• clearer runtime history
• stronger handling of interrupted or incomplete work
• durable per-agent state for processed records, pending approvals, pending replies, retries, and blocked work
• explicit agent-to-agent handoff queues with reason, context, owner, and status
• richer activation and approval modes
• more deterministic pre-execution controls

3.3 Policy maturity

RapidClaw already has a policy model, but it needs to mature into a more complete operating system for governed AI behavior.

Focus areas

• richer policy editing
• stronger approval and review patterns
• human approval workflows where agents prepare proposed actions, drafts, or cards, then wait for an approved decision before acting
• clearer policy versioning and evaluation
• better mediation around higher-risk or ambiguous work
• reusable safety policies for outbound communication, inbound-message handling, and external data processing

3.4 Model and provider management

The runtime is becoming more flexible than the current product surfaces expose.

Focus areas

• dynamic model catalog visibility
• per-agent model assignment
• model-quota operations and clearer admin guidance for requesting or adding capacity
• clearer runtime/provider management for administrators
• guarded backend operations for model changes rather than browser-only model administration

3.5 Customer-configurable communications

RapidClaw-supported communication channels are Email and Microsoft Teams. Customers may connect other channels through their own OpenClaw/runtime work, but those channels are outside RapidClaw's supported guardrail boundary and are the customer's responsibility to secure and govern.

Focus areas

• an outbound communication gateway that can enforce test mode, sender identity, do-not-contact rules, rate limits, cooldowns, unsubscribe/footer requirements, and central logging
• inbound message sanitization before agents process emails, Teams messages, or copied web content
• configurable compliance actions for bounces, opt-outs, "left company" replies, and other do-not-contact scenarios
• customer-specific language, timezone, business-hours, and routing rules
• configurable partner, reseller, or regional routing policies for customers whose go-to-market model needs them
• branded email footer settings, including company logo upload or hosted logo URL, footer preview, and validation in Command Center

3.6 Central coordination and interaction history

RapidClaw already uses Dataverse as the control boundary. The next step is to make the interaction log a stronger coordination surface for normal operations, not only a historical record.

Focus areas

• richer use of RapidClaw Interaction Log for agent actions, skipped work, approvals, handoffs, replies, safety decisions, and outcomes
• structured fields that make cooldown checks, customer history, agent influence, and compliance reporting queryable
• clear separation between raw execution logs, curated operational memory, and customer-visible history
• practical retention controls for logs, generated drafts, message bodies, and sensitive operational details

3.7 Customer motion templates

RapidClaw should provide reusable operating patterns without assuming every customer works like RapidStart or Forceworks.

Focus areas

• configurable templates for common business motions such as qualification, follow-up, renewal, customer success, internal operations, and reporting
• template guidance that separates universal guardrails from customer-specific sales language, product matrices, routing rules, and data model assumptions
• stable internal agent IDs with customer-specific names, mailboxes, instructions, schedules, and approval paths
• import/export patterns for customer playbooks so partners or implementation teams can adapt them safely

RapidClaw's agents should become more capable without growing brittle, overloaded, or customer-specific. The next agent updates should improve the quality of their instructions, tool use, and operating boundaries while keeping the bootstrap context compact.

4.1 Strengthen agent instruction files

The May 2026 OpenClaw Markdown backup contains useful patterns for richer agent playbooks, but it also includes private, prototype, and over-specific material. RapidClaw should harvest the reusable structure without copying stale content or expanding bootstrap files beyond practical limits.

Roadmap direction

• strengthen shared AGENTS.md with compact rules that must survive delegation, including source hierarchy, external-content handling, approval boundaries, and output contracts
• add concise role playbooks to specialist instruction files, including decision models, skip rules, escalation rules, confidence/evidence expectations, and recommended output shape
• preserve the reader/actor split so readers sanitize and summarize while actor agents decide or act
• avoid importing large memory files, personal notes, old Telegram/Ares delivery rules, hardcoded RapidStart sales motions, old agent names, or obsolete script paths
• define a safe update path for existing deployments, since live workspace files may preserve customer edits while stock workspace files receive product updates

4.2 Harvest useful backup-script capabilities

The May 2026 OpenClaw script backup contains several useful prototype capabilities that should be selectively productized rather than copied forward as loose scripts.

Roadmap direction

• promote the inbound email/content sanitizer and its tests into the governed inbound-processing path for email, Teams, and copied web content
• add VM/runtime diagnostic probes inspired by the old health and cron-health scripts, surfaced through Command Center and support bundles
• compare the older Graph MCP tool coverage against the current Graph service and selectively add safe read-only mail, calendar, Teams, and user lookup tools
• fold useful outbound-email safeguards into the governed outbound communication gateway, including do-not-contact checks, one-email-per-day cooldowns, reply-to-thread support, unsubscribe/footer handling, and central logging
• keep memory and Dataverse MCP backup code as reference material only unless a specific algorithm or test case improves the current Memory Service or Dataverse service

RapidClaw Command Center is increasingly the product’s administrative center of gravity.

6.1 What it should become

RapidClaw Command Center should continue to grow as the place where administrators:

• activate agents and schedules
• configure customer-specific agent playbooks and motion templates
• review readiness and diagnostics
• manage policies and approvals
• manage communication channels, sender identities, test mode, email branding, and compliance settings
• review interaction history, handoffs, approvals, blocked/sanitized inbound content, and Teams user/conversation/session mapping
• monitor usage and operational health
• perform normal day-to-day administration
• show a consistent public preview/demo representation for prospective customers without exposing live tenant data

6.2 Public preview/demo surface

RapidClaw now has a static Command Center preview artifact for website and customer-demo use. It should continue to track the real Command Center design closely, while remaining clearly labeled as simulated UI.

Focus areas

• keep preview content aligned with real Command Center tabs and terminology
• use representative demo data instead of live tenant data
• avoid implying that preview-only surfaces are fully wired in production
• use the same product branding treatment as the real Command Center

One of the most important maturity tracks now is confidence.

As RapidClaw adds more productized surfaces, regression prevention becomes more important across:

• deployment lifecycle
• Teams interaction
• administrative surfaces
• runtime assumptions across upstream changes

This means more emphasis on:

• stronger automated test coverage
• better release validation
• clearer upgrade confidence

7.1 Internal security hardening

Some beta-era compatibility paths should be retired after the small tester group validates the current onboarding flow.

Internal focus areas

• complete the migration from compatibility deployment-service authentication to tenant-bound Entra authentication
• add telemetry for any remaining legacy authentication usage before disabling it
• rotate retired compatibility credentials after the Entra path is verified end-to-end
• keep the current beta flow stable until the replacement path is proven

7.2 Typed workflow safety layer

RapidClaw is moving toward a typed, plan-first workflow design for higher-risk operations across Dataverse, Azure, Graph, Teams, Exchange/mailbox, and audit work.

Direction

• prefer constrained domain operations over broad free-form tool execution
• require mutating operations to produce a reviewable plan before execution
• keep explicit approval boundaries for imports, publishes, permissions, resource resets, mailbox changes, Teams catalog changes, and customer-impacting actions