Loading...
Forceworks · Specification
RapidClaw
Current-State Technical Specification · v0.3.122
Governed AI, deployed into your own cloud.
RapidClaw is a Microsoft-cloud-native AI operations layer for RapidStart CRM — Dataverse as system of record, Azure as runtime, Teams as the user surface, and an operator console that keeps governance ahead of autonomy.
Contents — sixteen sections
01Purpose→
02Product Definition→
03Architectural Thesis→
04System Topology→
05Microsoft Platform Footprint→
06Deployment Model→
07Dataverse as Control Boundary→
08Runtime Model→
09Agent System→
10Microsoft Teams Architecture→
11RapidClaw Command Center→
12Security & Governance→
13Operational Lifecycle→
14Current Product Maturity→
15Why This Matters→
16Summary→
01 / 16
Purpose
RapidClaw is a Microsoft-cloud-native AI operations layer for RapidStart CRM. It combines four substrates into one governed product.
- Dataverse as the system of record and policy boundary
- Azure as the deployment and runtime substrate
- Microsoft 365 / Entra / Graph / Teams as 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, a RapidClaw Command Center web application for runtime operations, and 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.
02 / 16
Product Definition
RapidClaw is not a generic chatbot and not a standalone CRM. It is an AI agent layer on top of RapidStart CRM, with three core responsibilities.
- Deploy a customer-owned Azure runtime for the agent system
- Operate a bounded multi-agent environment against Dataverse and Microsoft 365
- Expose that environment through Teams and administrative control surfaces
In practical terms, RapidClaw gives a RapidStart CRM customer:
- an orchestrated AI runtime deployed into their Azure subscription
- specialist CRM agents with constrained domains
- Teams-based conversational access
- optional background and scheduled execution
- operational controls, approvals, and diagnostics
- a browser-first deployment experience inside Dynamics / Power Platform
By design, a fresh deployment is provisioned in a non-live posture. Agents, scheduled jobs, and other behaviors that could produce autonomous activity are not assumed to become active immediately at install time. Operators are expected to review and explicitly activate those capabilities in RapidClaw Command Center.
03 / 16
Architectural Thesis
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, Command Center, supporting services, 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.
Reasoning is delegated to agents — but configuration, policy, status, and lifecycle remain deterministic and inspectable.
This architecture exists for three reasons
- Tenant isolation. Each customer gets a dedicated runtime in their own Azure subscription.
- Microsoft-platform affinity. Identity, CRM, Teams, Graph, bot routing, deployment, and operational records all stay inside the Microsoft stack.
- Governance before autonomy. The control surface is product-shaped, not implementation-shaped.
04 / 16
System Topology
RapidClaw is intentionally split into four planes.
PLANE 01
RapidStart CRM / Dataverse
Authoritative business state, policy, audit, and deployment records. Setup web resource and model-driven app surfaces live here.
PLANE 02
Forceworks Deployment
Orchestration, routing, release management, durable lifecycle control. Azure Functions, Durable Functions, Teams router, App Insights.
PLANE 03
Customer Runtime
Dedicated resource group + Ubuntu VM in the customer's Azure subscription. Isolated execution of the agent system.
PLANE 04
User-Facing Surfaces
Provisioning, administration, advanced runtime access, end-user interaction.
High-level flow
- 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
05 / 16
Microsoft Platform Footprint
RapidClaw is notable because it is not merely "integrated with Microsoft" — it is built almost entirely from Microsoft platform components.
5.1Dynamics 365 / Power Platform / Dataverse
- operator UI embedding
- application data, policy records, runtime memory and audit records
- deployment records and progress
5.2Microsoft Entra ID
- customer app registration creation
- delegated browser sign-in flows
- JWT-backed service auth migration
- tenant-bound deployment authorization
5.3Microsoft Graph
- application registration and service principal operations
- Teams app publish, catalog inspection, install checks
- mailbox and directory-related provisioning paths
- Teams readiness diagnostics
5.4Microsoft Teams
- personal bot app
- customer-owned Bot Service ingress
- Teams admin-center deployment workflow
- chat-based interaction with RapidClaw
- emerging file-delivery flow using Teams file consent cards
5.5Azure
- resource group lifecycle
- VM deployment, Key Vault, Azure OpenAI
- Azure Functions / Durable Functions
- Bot Service integration
- RunCommand-based post-deploy configuration
RapidClaw extends the existing business application estate while staying inside the same control, identity, and data boundaries as the surrounding platform.
06 / 16
Deployment Model
6.1Provisioning 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.2Operator entry point
Provisioning begins in the Dataverse-hosted RapidClaw setup wizard. 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
6.3Default activation posture
RapidClaw does not treat deployment completion as permission to begin autonomous operation. New environments are provisioned in a controlled non-live state:
State 01
Provisioned
Infrastructure, runtime, and product surfaces exist. The environment is reachable and administrable.
State 02
Configured
Agent definitions, policies, Teams setup, mailbox setup, and schedules may already be present as managed artifacts.
State 03
Live
Specific agents, schedules, and interaction surfaces have been explicitly activated for production use.
6.4Deployment service
The deployment service currently exposes these first-class HTTP functions:
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
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, and coordinates ARM, Graph, and Dataverse operations.
6.5Authentication 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. This is an important maturity step — it moves deployment authorization closer to standard Microsoft enterprise patterns.
6.6Browser vs backend split
Service-owned
- infrastructure orchestration · reset teardown · Teams deployment
- agent seeding and action-policy seeding
- mailbox provisioning · release config resolution
Still browser-mediated
- initial identity flows and delegated consent
- some setup-time token acquisition and user-scoped handoffs
- parts of the remaining deployment sequence still being migrated from the legacy web resource model
07 / 16
Dataverse as the Control Boundary
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.1Core 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, failure detail, durable operator-visible progress surface.
7.2Why Dataverse matters architecturally
- 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
If a runtime file and a Dataverse record disagree, the Dataverse record is authoritative.
08 / 16
Runtime Model
8.1Runtime host
The customer VM runs the RapidClaw runtime stack:
- OpenClaw gateway/runtime
- RapidClaw Command Center (Next.js operational UI)
- rapidclaw-memory
- Graph support services / MCP-style integrations
- rapidclaw-bot-forwarder
nginx+oauth2-proxy
8.2Runtime behavior
OpenClaw is the on-VM execution engine. RapidClaw layers agent workspaces, prompts, shared team policy files, Dataverse-anchored policy and memory boundaries, and operational integration with Teams and Command Center.
At deployment time, the installed OpenClaw version is the current version available at that moment, rather than a separately pinned long-term RapidClaw-specific runtime channel. Future OpenClaw runtime updates should therefore be treated as an explicit administrative action rather than implicit background behavior.
8.3OpenClaw vs RapidClaw boundary
OPENCLAW PROVIDES
The substrate
The underlying gateway/runtime, agent execution substrate, advanced runtime administration surface, and upstream plugin/runtime behavior.
RAPIDCLAW PROVIDES
The product
Dataverse-centered control model, deployment & teardown orchestration, customer-facing Command Center, agent team definitions, policy model, Teams router/forwarder, and the productized lifecycle.
RapidClaw is not a cosmetic wrapper around OpenClaw. The core product value is in the governed operating model built around the runtime — not in exposing the runtime itself.
8.4Current durability posture
- scheduled jobs exist and are manageable
- policy records exist and are consulted
- record-level locking and deny-by-default policy posture exist
- durable runtime job-state and stronger execution controls remain roadmap items
09 / 16
Agent System
RapidClaw deploys a named agent team rather than a single monolithic assistant.
9.1Core roles
Coordinator
RapidClaw
Orchestrator. Primary conversational surface. Decides when specialist or reader agents are involved.
Specialist
Alex
Account health.
Specialist
Casey
Contact health.
Specialist
Quinn
Prospect qualification.
Specialist
Morgan
Opportunity acceleration.
Specialist
Jordan
Customer service.
Specialist
Riley
Relationship intelligence.
Builder
Cody
Power Platform / configuration-oriented specialist.
Mediation
Reader Agents
Sanitization, normalization, narrower trust boundaries before specialist work runs.
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 decides when specialist agents or reader agents should be involved, coordinates handoffs, and returns a unified response.
9.2Team 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, and deliverable-file behavior for Teams file delivery.
One shared policy surface governs the agent team — making behavior more consistent and inspectable than ad hoc prompt sprawl.
9.3Trust boundary & coordination
- 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
- action policies and Dataverse-backed control records constrain what live actions may occur
9.4Activation and live-state model
RapidClaw distinguishes between provisioned, configured, and live. 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.5Current 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 conversationally, route to specialist agents, write structured outputs and files, run optional background tasks, and perform CRM-adjacent actions within policy.
The more advanced "safe execution modes / approval-required runtime / durable interrupted-job review" model remains an explicit next-stage maturity target.
10 / 16
Microsoft Teams Architecture
10.1Current Teams app shape
RapidClaw currently ships a personal-scope Teams bot app with scopes: ["personal"] and supportsFiles: true. This means a direct 1:1 chat-style assistant experience inside the RapidClaw app — not general @mention participation in arbitrary team or group chat contexts.
Teams access is not universal by default. The app must be deployed and made available through the Teams admin center, and access can be limited to specific users.
10.2Customer-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.
- 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.3Customer 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, and returns replies through the Bot Framework adapter for the customer-owned bot path.
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, and specialist-coordinated turns may still take longer.
10.4Teams readiness and truthfulness
- customer-ingress and forwarder readiness checks
- distinction between "admin approval missing" and "Graph sign-in required"
- more honest deployment/readiness states in Command Center
- retirement of vestigial
msteamsplugin ingress assumptions
Enterprise trust is built not just on successful deployment, but on whether the operational surfaces tell the truth.
10.5Teams file delivery
RapidClaw now has an initial Teams file-delivery bridge for agent-produced markdown deliverables. Agents write to a turn-specific outbox; the VM forwarder detects the files; the Teams delivery path can return FileConsentCard attachments back to Teams.
As of this snapshot, this is Phase A: visible file consent cards are supported, the full click-to-upload completion path is still in progress.
11 / 16
RapidClaw Command Center
The operational web application deployed on the customer VM, exposed under /dashboard.
11.1Current pages
01
Dashboard
02
Agent Roster
03
Approvals
04
Safety Controls
05
Permission Rules
06
Agent Instructions
07
Activity Log
08
Journal / History
09
Scheduled Tasks
10
Usage / Costs
11
Email Settings
12
Microsoft Teams
13
Model Operations
14
Bug Report
15
OpenClaw Admin Launcher
11.2Purpose
Command Center is where RapidClaw becomes a product rather than just a deployment.
- a stable runtime surface after deployment
- the primary administrative surface for normal operation
- separates advanced OpenClaw internals from the customer-friendly admin experience
- centralizes approvals, controls, Teams diagnostics, and runtime visibility
- gives operators a product-native path to send bug reports with version, browser, tenant, and optional screenshot context
- previews future model operations for Azure AI / Azure OpenAI catalog, quota, deployment, and assignment workflows
- is where operators activate agents, schedules, and other live behaviors after deployment
11.3Model Operations preview
The current Model Operations page is a non-functional preview. It is intentionally present so administrators can see the intended direction:
- show which models are available in the selected subscription and region
- show whether required quota exists
- guide administrators to add model deployments when capacity is approved
- keep RapidClaw orchestrator assignments on full-size models while allowing mini-class deployments for worker/reader agents
- apply model changes through guarded backend operations rather than browser-only calls
11.4Bug reporting
Command Center includes a Bug Report page that posts reports to Forceworks through a Power Automate workflow. The report includes user-entered issue details plus background context such as Command Center version, host, Dataverse URL, tenant id, browser, viewport, and optional screenshot content.
The current implementation treats a Power Automate NoResponse 502 as an accepted submission because that condition indicates the workflow was invoked but did not return an HTTP acknowledgement. The preferred flow configuration remains an explicit HTTP 200 response action.
11.5Relationship to OpenClaw Admin
OpenClaw Admin remains available for advanced users who want lower-level runtime access, diagnostics, or direct interaction with the underlying OpenClaw surface. It is not intended to be the primary day-to-day operating experience.
Command Center is where the product is operated. OpenClaw Admin is where advanced users manage the underlying runtime.
12 / 16
Security & Governance
RapidClaw's current security story is stronger than "LLM with CRM access," but intentionally honest about what remains to be hardened.
Current strengths
- Customer-owned Azure subscription & 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
- 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
Known boundaries
- Runtime job durability not yet at final intended maturity
- Richer execution modes & operator kill switches 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
12.3Failure and degradation behavior
RapidClaw is 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 surfaces 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
- if local execution material on the VM becomes stale or inconsistent, Dataverse policy/configuration records remain the recovery reference point
Not every partial failure should erase operator visibility. The product preserves truthful status even when a surface is degraded.
13 / 16
Operational Lifecycle
13.1Deploy
FLOW 01Deploy sequence
01Sign in and grant the needed delegated permissions
02Select environment inputs in Dataverse
03Trigger provisioning
04Watch
fw_Deployment* progress05Optionally run post-deploy steps for agents, mailboxes, and Teams
06Activate desired agents, schedules, and live behaviors in Command Center
13.2Operate
After deployment, operators use Command Center and Teams to interact with agents, manage deployment and runtime status, inspect Teams readiness, work with prompts and policies, control schedules, and decide what becomes active in production rather than inheriting a fully live runtime by default.
13.3Day-2 operations
- reviewing deployment and runtime history in Dataverse-backed records
- confirming Teams readiness and route truthfulness
- 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 surface, reserving OpenClaw Admin for advanced runtime work
13.4Concrete flow examples
FLOW 02Teams conversation flow
01A permitted user sends a message in the RapidClaw Teams app
02The customer-owned Azure Bot Service receives the activity
03The customer VM forwarder receives the Bot Framework activity at
/api/messages04The forwarder authenticates the request and invokes the RapidClaw orchestrator
05The orchestrator may coordinate with reader / specialist agents
06The resulting reply is returned through the Bot Framework adapter back to Teams
FLOW 03Deployment orchestration flow
01Operator starts provisioning from the Dataverse-hosted setup experience
02The deployment service starts a Durable Functions orchestration
03Step progress and events are written to
fw_Deployment* records04The operator observes progress in the product UI rather than a page-local process
05After provisioning, the environment remains non-live until activation
FLOW 04Generated-file delivery flow
01The orchestrator or delegated agent produces a markdown deliverable
02The file is written to the turn outbox on the customer VM
03The forwarder detects it and returns a structured attachment payload
04The Teams delivery path relays the attachment back into Teams using the current file-delivery bridge
05The document becomes part of the conversation surface
13.5Reset / redeploy
Reset and lifecycle teardown are now increasingly service-owned rather than browser-owned. This is a major maturity improvement — destructive orchestration moves into durable backend workflows with step tracking instead of a fragile page-local process.
14 / 16
Current Product Maturity
Production-shaped now
- Customer-owned Azure deployment model
- Dataverse-native setup experience
- Forceworks-hosted deployment orchestration service
- Teams app distribution and customer-owned bot ingress
- RapidClaw Command Center operational surface
- Command Center Bug Report intake with background context and optional screenshot
- Model Operations preview surface
- Service-driven reset, Teams rollout, agent seeding, mailbox provisioning
- Richer auth posture for backend deployment APIs
- Honest Teams readiness diagnostics
- Deliberate non-live deployment posture with operator activation
Clearly roadmap
- Fully durable runtime job ledger
- Comprehensive runtime safe execution modes
- First-class approval queue tied to runtime execution decisions
- Broader deterministic routing and degradation modes
- Lower-latency Teams execution path
- Final cleanup of some legacy setup/runtime assumptions
The key point is not simply that these items remain. It is that RapidClaw already has a coherent, shippable product core while those next-stage controls are being added.
15 / 16
Why This Matters
RapidClaw 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.
16 / 16
Summary
RapidClaw today is —
A
A Dataverse-native deployment and operations product.
B
An Azure-deployed customer-owned runtime.
C
A Teams-integrated personal AI assistant for RapidStart CRM.
D
A multi-agent system with real operational controls.
E
A product in active hardening — with a visible and credible path from useful to fully governed.
Strongest differentiator
Not any single model or prompt — but the combination of Microsoft-platform alignment, customer-owned runtime isolation, browser-first deployment, Dataverse-centered governance, Teams-native end-user access, and an increasingly durable backend orchestration layer.
That combination is the product.