Governed AI, deployed into your own cloud.

RapidClaw is a Microsoft-cloud-native AI operations layer for RapidStart CRM. It combines:

• Dataverse as the system of record and policy boundary
• Azure as the deployment and runtime substrate
• Microsoft 365 / Entra / Graph / Teams as the identity, communication, and end-user surface
• OpenClaw as the on-VM agent runtime and gateway

The product is designed to let a customer deploy a governed, tenant-isolated AI agent environment into their own Azure subscription without requiring CLI-based setup. The primary operator experiences are:

• a Dataverse-hosted setup wizard for provisioning and lifecycle management
• a RapidClaw Command Center web application for runtime operations, controls, approvals, Teams readiness, diagnostics, model-operations preview, and bug reporting
• a Microsoft Teams personal app for end-user interaction with the RapidClaw agent team

This document describes the product as it exists now, not the earlier design target. Where a capability is partial or explicitly still in transition, it is called out as such.

RapidClaw is built around a deliberate separation of concerns:

• Deployment control plane: Forceworks-hosted Azure Functions + Durable Functions
• Runtime control plane: customer-hosted VM running OpenClaw, RapidClaw Command Center, supporting services, and local automation
• Shared system-of-record boundary: customer Dataverse

The browser is an operator console, not the deployment engine. The customer VM is a runtime substrate, not a source of business truth. Dataverse remains the canonical source for configuration, runtime metadata, policy, and audit records.

This architecture exists for three reasons:

1. Tenant isolation: each customer gets a dedicated runtime in their own Azure subscription
2. Microsoft-platform affinity: identity, CRM, Teams, Graph, bot routing, deployment, and operational records stay inside the Microsoft stack
3. Governance before autonomy: reasoning is delegated to agents, but configuration, policy, status, and lifecycle remain deterministic and inspectable

RapidClaw is intentionally split into four planes.

1. RapidStart CRM / Dataverse plane

• Dataverse tables:

fw_ClawConfig, fw_ClawAgent, fw_ActionPolicy, fw_InteractionLog, fw_AgentMemory, fw_Deployment, fw_DeploymentStep, fw_DeploymentEvent

• Dataverse-hosted setup web resource
• Model-driven app surfaces
• Purpose: authoritative business state, policy, audit, and deployment records

2. Forceworks deployment plane

• Azure Functions HTTP API
• Durable Functions orchestrators and activities
• legacy Teams router fallback and route diagnostics
• Shared release artifact hosting
• Application Insights and service diagnostics
• Purpose: orchestration, release management, and durable lifecycle control

3. Customer runtime plane

• Dedicated resource group in the customer Azure subscription
• Ubuntu VM running:

nginx, oauth2-proxy, OpenClaw gateway/runtime, RapidClaw Command Center, rapidclaw-memory, Graph helper / MCP support, and rapidclaw-bot-forwarder

• Supporting Azure resources:

Key Vault, Azure OpenAI, networking/security resources, and customer-owned Bot Service ingress

• Purpose: isolated execution of the agent system inside the customer-owned environment

4. User-facing surfaces

• Dataverse setup wizard
• RapidClaw Command Center
• OpenClaw Admin
• Microsoft Teams personal app
• Forceworks bug-report intake workflow from Command Center
• static Command Center customer-preview artifacts for website/demo use
• Purpose: provisioning, administration, advanced runtime access, and end-user interaction

At a high level, the flow is:

• the setup wizard starts provisioning against the Forceworks deployment plane
• the deployment service writes durable state into Dataverse
• the deployment service provisions the customer runtime plane
• operators administer the environment through RapidClaw Command Center
• end users interact through Teams, which routes through customer-owned Bot Service ingress into the customer runtime

6.1 Provisioning shape

RapidClaw deploys into a customer-owned Azure subscription. The canonical runtime unit is a dedicated resource group and Ubuntu VM per customer deployment. The deployment process uses deterministic naming with a short deployment suffix to avoid stale-resource collisions and to support redeploy/reset flows cleanly.

6.2 Operator entry point

Provisioning begins in the Dataverse-hosted RapidClaw setup wizard. The wizard still matters because some steps are inherently user-scoped and browser-mediated:

• Entra sign-in
• delegated Graph/ARM token acquisition
• app registration consent
• environment selection
• setup-time choices and confirmations
• subscription, region, and AI-model prerequisite checks before deployment

After that, responsibility increasingly shifts to the backend deployment service.

The current setup flow includes a Step 2 prerequisite gate. After the operator selects a subscription and region, the wizard calls the deployment service preflight endpoint to check subscription access, provider readiness, and Azure OpenAI / Foundry model availability and capacity. Step 3 deployment is blocked until the current subscription/region/release preflight passes. This prevents the user from starting a long deployment that is already known to fail for missing model capacity or subscription prerequisites.

6.3 Default activation posture

RapidClaw does not treat deployment completion as permission to begin autonomous operation. New environments are provisioned in a controlled non-live state:

• core infrastructure is installed and configured
• runtime surfaces are reachable
• agents and schedules exist as managed artifacts
• but operators are expected to enable or activate the behaviors they want in production

This deliberate safety choice gives the customer a review window between "the environment exists" and "the environment is allowed to act."

6.4 Deployment service

The deployment service currently exposes these first-class HTTP functions:

• POST /preflight
• POST /deployments
• GET /deployments/{id}
• POST /deployments/{id}/retry
• POST /deployments/{id}/cancel
• POST /deployments/{id}/reset
• POST /deployments/{id}/teams-deployment
• POST /deployments/{id}/agents-team
• mailbox-related deployment helpers
• GET /release/config

The service:

• creates and updates fw_Deployment* records in Dataverse
• runs Durable Functions orchestrators for long-running work
• owns tenant-bound authorization checks
• coordinates ARM, Graph, and Dataverse operations
• checks deployment prerequisites before infrastructure work starts
• provides a durable backbone for provisioning and teardown

6.5 Authentication posture

RapidClaw is mid-migration from a browser-exposed deployment API key model toward Entra JWT-based backend authorization. Current code prefers JWT validation with strict tenant binding and retains a controlled legacy fallback for rollback safety in some paths. This is an important maturity step because it moves deployment authorization closer to standard Microsoft enterprise patterns.

6.6 Current split of browser vs backend work

As of this snapshot:

• Service-owned
• subscription/region/model prerequisite preflight
• infrastructure orchestration
• reset teardown orchestration
• Teams deployment orchestration
• agent seeding and action-policy seeding
• mailbox provisioning orchestration
• release config resolution

• Still browser-owned or browser-mediated
• initial identity flows and delegated consent
• some setup-time token acquisition and user-scoped handoffs
• some setup-time ceremony and state hydration still being migrated from the legacy web resource model

This is a meaningful transition state: RapidClaw is no longer a browser-driven installer, but it is not yet a fully headless backend deployment pipeline either.

RapidClaw uses Dataverse as the authoritative business and control boundary.

In practice, that means Dataverse is the system of record for what RapidClaw is, what it is allowed to do, and what state it is in. Local VM files, workspace prompts, temporary memory artifacts, and runtime-generated support files exist to help the runtime execute, but they are not the authoritative source of product truth.

7.1 Core tables

• fw_ClawConfig
• singleton-style environment/runtime configuration
• Azure identifiers, deployment metadata, endpoint references, status fields

• fw_ClawAgent
• agent roster and provisioning metadata
• email/Teams enablement metadata
• runtime-facing identity records

• fw_ActionPolicy
• per-agent permission controls
• allow/deny decisions for action classes

• fw_AgentMemory
• long-term structured memory records synchronized from runtime memory systems

• fw_InteractionLog
• audit trail of runtime activity and decisions

• fw_Deployment / fw_DeploymentStep / fw_DeploymentEvent
• deployment state machine records
• step-level progress and failure detail
• durable operator-visible progress surface

7.2 Why Dataverse matters architecturally

Dataverse is doing more than storing configuration:

• it gives the deployment service a customer-owned state boundary
• it keeps product configuration close to the CRM workload
• it allows model-driven-app-native operator visibility
• it creates an auditable bridge between Azure runtime actions and CRM context

This is an important differentiator: RapidClaw does not externalize the governance surface into a disconnected control plane. It keeps the control model anchored in Dataverse while still using Azure for the runtime substrate.

Operationally, that means if a runtime file and a Dataverse record disagree, the Dataverse record should be treated as authoritative. Workspace files such as prompts, local memory artifacts, and supporting markdown files are execution material; Dataverse holds the approved configuration, policy, deployment state, and business-facing control data.

RapidClaw deploys a named agent team rather than a single monolithic assistant.

9.1 Core roles

Current shared team definitions include:

• RapidClaw orchestrator (orchestrator)
• Alex (account-health) — account health
• Casey (contact-health) — contact health
• Quinn (prospect-qualifier) — prospect qualification
• Morgan (opportunity-chaser) — opportunity acceleration
• Jordan (customer-service) — customer service
• Riley (relationship-intelligence) — relationship intelligence
• Cody (pp-builder) — Power Platform builder
• supporting reader agents for sanitization and mediation:

prospect-qualifier-reader, opportunity-chaser-reader, customer-service-reader, and relationship-intelligence-reader

The key interaction model is that end users do not independently converse with all of these agents. In Teams and other normal product surfaces, the user interacts with the RapidClaw orchestrator. The orchestrator is responsible for deciding when specialist agents or reader agents should be involved, coordinating those handoffs, and returning a unified response.

Once activated, the specialist roles are intended to behave roughly as follows:

• RapidClaw orchestrator
• primary conversational surface for end users
• interprets requests, applies policy context, and coordinates specialist work
• decides when a request should remain conversational versus invoke a narrower specialist path
• Alex / Casey / Quinn / Morgan / Jordan / Riley
• domain-focused CRM specialists with narrower responsibility than the orchestrator
• contribute analysis, recommendations, summaries, or task-specific actions inside their assigned business domain
• are generally intended to be coordinated through the orchestrator rather than exposed as separate user-facing personas in normal operation
• Cody
• Power Platform and configuration-oriented specialist for builder/admin-adjacent tasks
• supports controlled solution/configuration work rather than broad conversational CRM assistance
• Reader agents
• mediation and sanitization layer for safer delegation and narrower trust boundaries

Activation therefore is not just "turning on an agent name." It is enabling a governed role in the overall team model, with expected responsibilities, policy boundaries, and operational consequences.

The reader agents are worth calling out explicitly because they are part of the product's control posture, not just an implementation detail. They sit between raw user input or delegated work and the higher-trust specialist paths, and are used to:

• sanitize or normalize incoming requests before handoff
• mediate delegated execution when a narrower tool or domain boundary is required
• reduce prompt-sprawl by applying a consistent shared policy layer before specialist work runs
• support safer composition of multi-agent behavior without giving every specialist the same broad conversational responsibility

9.2 Team policy file

The shared workspace/_shared/AGENTS.md is authoritative for all agents, including delegated/sub-agent paths. It encodes:

• environment identity
• team roster
• trust architecture
• tool-use rules
• Dataverse table conventions
• deliverable-file behavior for Teams file delivery

This is a strong operational design choice: one shared policy surface governs the agent team, making product behavior more consistent and inspectable than ad hoc prompt sprawl.

9.3 Trust boundary and coordination model

The agent team is not a flat set of equally privileged conversational actors. There is a deliberate trust and coordination model:

• the orchestrator is the primary user-facing coordinator
• reader agents mediate, sanitize, and narrow inputs before higher-trust specialist work runs
• specialist agents operate inside narrower role boundaries and are not assumed to independently own the full user conversation
• action policies and Dataverse-backed control records constrain what live actions may occur

The orchestrator is powerful, but not unconstrained. Its role is to coordinate work within policy, not to bypass the control model. Likewise, specialists are intentionally narrower than the orchestrator; they exist to improve domain quality and boundedness, not to become parallel unsupervised user-facing assistants.

Recent instruction updates also push the orchestrator toward answering directly when it already has enough CRM context. Specialist delegation is still supported, but it should not be the default for every non-trivial user message. The intended pattern is:

• orchestrator handles straightforward read-only CRM questions directly
• orchestrator resolves exact record identity before delegation
• specialists are invoked for domain-specific judgment, long-running work, or stronger context requirements
• reader agents sanitize raw external content before actor agents process it

9.4 Activation and live-state model

RapidClaw distinguishes between provisioned, configured, and live:

• Provisioned
• infrastructure, runtime, and product surfaces exist
• the environment is reachable and administrable
• Configured
• agent definitions, policies, Teams setup, mailbox setup, and schedules may already be present as managed artifacts
• the environment has the shape needed for live use
• Live
• specific agents, schedules, and interaction surfaces have been explicitly activated for production use

A fresh environment can be fully deployed without being allowed to act. Activation is the point at which a customer intentionally permits a role, schedule, or interaction path to participate in day-to-day operation.

9.5 Current execution posture

RapidClaw today is best characterized as a bounded multi-agent assistant with selective automation, not as a fully autonomous back-office worker. It can:

• answer and coordinate in conversational form
• route to specialist agents
• write structured outputs and files
• run optional background and scheduled tasks
• perform CRM-adjacent actions within policy and integration constraints

It is also not intended to go live by accident. The product assumes operators will use RapidClaw Command Center to decide when specific agents, schedules, and operational behaviors should be activated.

From a product perspective, "activation" should be understood as an administrative approval to let a specific role or schedule participate in live operation. A deployed environment can therefore be healthy and fully provisioned while still intentionally not acting until those activation choices have been made.

The more advanced “safe execution modes / approval-required runtime / durable interrupted-job review” model remains an explicit next-stage maturity target rather than a fully completed capability today.

10.1 Current Teams app shape

RapidClaw currently ships a personal-scope Teams bot app with:

• scopes: ["personal"]
• supportsFiles: true

This defines what the current product actually supports:

• a direct 1:1 chat-style assistant experience inside the RapidClaw app
• not general @mention participation in arbitrary team or group chat contexts

It also means Teams access is not universal by default. The Teams app must be deployed and made available through the Teams admin center, and access can be limited to specific users rather than exposed to everyone in the tenant. That is an important part of the safety model: limiting who can directly interact with RapidClaw is one of the controls available to the customer.

10.2 Customer-owned bot ingress model

RapidClaw now provisions a customer-owned Azure Bot Service in the customer resource group. The Teams app points Bot Framework traffic at that customer-owned bot endpoint, and the bot forwards messages directly to the customer VM at /api/messages.

This pattern gives RapidClaw:

• one Teams app surface per deployed customer environment
• a shorter Teams message path into the isolated customer runtime
• less day-to-day dependency on Forceworks-hosted runtime services
• a cleaner failure boundary if the Forceworks deployment plane is unavailable after deployment

The Forceworks shared router still exists as a fallback and diagnostic path during transition, but it is no longer the intended primary path for day-to-day Teams conversations.

10.3 Customer VM bot-forwarder

On the customer VM, rapidclaw-bot-forwarder:

• authenticates Bot Service and legacy router traffic
• extracts message text and conversation context
• performs deterministic local replies and acknowledgement/progress messages when safe
• invokes the appropriate OpenClaw agent via CLI
• returns replies through the Bot Framework adapter for the customer-owned bot path
• still supports /api/bot/forward for the legacy shared-router fallback

This path is functionally solid today, but still has meaningful latency overhead because it spawns the OpenClaw CLI/runtime path per message. Recent testing showed that direct Azure OpenAI calls from the VM are fast, while full OpenClaw CLI turns can be much slower even for small prompts. That makes Teams message latency a first-class roadmap item rather than a Teams/Bot Framework issue.

The current mitigation is intentionally conservative:

• simple bounded messages can receive deterministic local replies
• longer orchestrator-led turns can receive a quick acknowledgement that RapidClaw is checking context
• specialist-coordinated turns may still take longer

The intended next-stage improvement is a supported persistent OpenClaw session or lower-latency invoke path that avoids CLI startup per Teams message without bypassing policy, logging, or agent coordination.

From the end-user point of view, Teams is still a conversation with the RapidClaw orchestrator. The specialist agents are behind that surface. Users are not expected to choose among Alex, Casey, Quinn, Morgan, Jordan, Riley, or Cody directly in normal Teams operation; the orchestrator coordinates with them as needed.

10.4 Teams readiness and truthfulness

Recent product work materially improved the Teams admin experience:

• customer-ingress and forwarder readiness checks
• distinction between “admin approval missing” and “Graph sign-in required”
• more honest deployment/readiness states in RapidClaw Command Center
• retirement of vestigial msteams plugin ingress assumptions

Enterprise trust is built not just on successful deployment, but on whether the operational surfaces tell the truth.

10.5 Teams file delivery

RapidClaw now has an initial Teams file-delivery bridge for agent-produced markdown deliverables:

• agents can write deliverables to a turn-specific outbox directory
• the VM forwarder detects those files
• the Teams delivery path can return FileConsentCard attachments back to Teams

As of this snapshot, this is Phase A of the capability:

• visible file consent cards are supported
• the full click-to-upload completion path is still in progress

This shows that RapidClaw is not limited to pure chat text; it is actively evolving into a richer Teams-native assistant surface.

RapidClaw’s current security story is stronger than “LLM with CRM access,” but still intentionally honest about what remains to be hardened.

12.1 Current strengths

• customer-owned Azure subscription and runtime resources
• Entra-mediated delegated setup
• tenant-bound JWT validation on backend deployment APIs
• customer-owned Teams bot ingress
• per-tenant shared secrets for Bot Service / fallback router traffic
• gateway token reuse across redeploys to avoid accidental auth churn
• deny-by-default action policy posture
• record-level locking
• network and VM isolation controls
• Dataverse-anchored audit and policy records
• no Forceworks bot credentials on customer VMs

12.2 Current known boundaries

• runtime job durability is not yet at the final intended maturity
• richer execution modes and operator kill switches are not fully productized
• customer-owned Teams bot ingress still needs additional clean-install soak and hardening
• Teams deep-response latency is still too high on some turns because the current forwarder invokes OpenClaw through the CLI/runtime path per message
• OpenClaw Admin launch from RapidClaw Command Center uses a retry landing page while the upstream pairing race remains unresolved

This is the right posture for sophisticated readers: RapidClaw is governed and enterprise-aligned today, but it is not pretending that the entire maturity roadmap is already complete.

12.3 Failure and degradation behavior

RapidClaw is also designed to degrade in understandable layers rather than treating every failure as a total product failure:

• if delegated Graph-backed checks cannot run, the product can still surface a more limited but truthful readiness state
• if Teams Bot Service deployment, app catalog publication, or VM forwarder configuration is incomplete, Teams may be unavailable while Command Center and Dataverse-backed administration remain authoritative
• if a Teams turn requires deeper orchestrator/specialist work, the user may receive an immediate acknowledgement while the slower runtime turn proceeds
• if runtime-facing features fail on the VM, Dataverse deployment state and backend orchestration records still provide the canonical view of what was attempted and what completed
• if local execution material on the VM becomes stale or inconsistent, Dataverse policy/configuration records remain the recovery reference point

The operating principle is straightforward: not every partial failure should erase operator visibility. The product should preserve truthful status even when a surface or integration is degraded.

13.1 Deploy

The customer:

1. signs in and grants the needed delegated permissions
2. selects environment inputs in Dataverse
3. triggers provisioning
4. watches fw_Deployment* progress
5. optionally runs post-deploy steps for agents, mailboxes, and Teams
6. activates the desired agents, schedules, and live behaviors in RapidClaw Command Center

13.2 Operate

After deployment, operators use RapidClaw Command Center and Teams to:

• interact with agents
• manage deployment and runtime status
• inspect Teams readiness
• work with prompts and policies
• control schedules
• monitor usage and operations
• decide what becomes active in production rather than inheriting a fully live runtime by default

13.3 Day-2 operations

Day-2 operation is not just "the bot is running." A healthy operating pattern includes:

• reviewing deployment and runtime history in Dataverse-backed records
• confirming Teams readiness and customer-ingress health
• activating only the agents and schedules that are actually intended to run
• tuning prompts, policies, and instructions in a controlled way
• reviewing approvals, logs, and operational anomalies
• using Command Center as the default administrative surface and reserving OpenClaw Admin for advanced runtime work

This is part of the product story: RapidClaw is meant to be operated, not merely installed.

13.4 Concrete flow examples

Three concrete flows are useful for understanding how the system actually behaves:

1. Teams conversation flow

• a permitted user sends a message in the RapidClaw Teams app
• the customer-owned Azure Bot Service receives the activity
• the customer VM forwarder receives the Bot Framework activity at /api/messages
• the forwarder authenticates the request and invokes the RapidClaw orchestrator
• the orchestrator may coordinate with reader/specialist agents
• the resulting reply is returned through the Bot Framework adapter back to Teams

1. Deployment orchestration flow

• an operator starts provisioning from the Dataverse-hosted setup experience
• the deployment service starts a Durable Functions orchestration
• step progress and events are written to fw_Deployment* records in Dataverse
• the operator observes progress in the product UI rather than relying on a page-local process
• after provisioning, the environment remains non-live until activation decisions are made

1. Generated-file delivery flow

• the orchestrator or a delegated agent produces a markdown deliverable
• the file is written to the turn outbox on the customer VM
• the forwarder detects it and returns a structured attachment payload
• the Teams delivery path relays the attachment back into Teams using the current file-delivery bridge
• the document becomes part of the conversation surface rather than staying hidden in a local workspace

13.5 Reset / redeploy

Reset and lifecycle teardown are now increasingly service-owned rather than browser-owned. This is a major maturity improvement because it moves destructive orchestration into durable backend workflows with step tracking instead of a fragile page-local process.

RapidClaw is compelling because it demonstrates a very specific pattern:

AI agents deployed into the customer’s Azure estate, governed through Dataverse, surfaced through Teams, and operated through a platform-native control plane.

That matters because it aligns with real enterprise buying and architecture concerns:

• customer data sovereignty and tenant isolation
• business application adjacency
• Teams as the user surface
• Entra as the trust boundary
• Azure as the deployment substrate
• Dataverse as the operational and business state layer

This is not “AI glued onto CRM.” It is a serious attempt to make AI operations feel native to the surrounding business cloud, identity, and collaboration stack.