Roadmap
Build Phases
Crawbl is built in four phases, each expanding the platform's capabilities and target market.
In plain language, the roadmap moves from "prove the platform works end to end" to "make it robust for developers and enterprises."
Phase 1 validates the core platform with real consumer traffic. Each subsequent phase builds on the infrastructure and learnings from the previous one.
Phase 1 — Platform Validation (Consumer App)
Status: Active
The foundation phase. Everything built here becomes the substrate for PaaS, IaaS, and marketplace offerings in later phases.
| Component | Description |
|---|---|
| Go orchestrator | Auth, provisioning, LLM mediation, and request routing |
| Internal HTTP MCP | MCP surface embedded in the orchestrator for runtime-to-backend communication |
| Adapter framework | Gmail and Google Calendar adapters (read-only) as the first integration proof |
| UserSwarm operator | Per-user ZeroClaw deployment via Kubernetes operator |
| Flutter app | Onboarding, chat, swarm UX, and integration cards |
| Default skills | Bundled first-party agents and skills for immediate usefulness |
| Infrastructure | DigitalOcean Kubernetes cluster with Pulumi bootstrap and ArgoCD management |
Phase 2 — Production Hardening
Status: Planned
The reliability and trust phase. This is where the platform becomes production-grade.
| Component | Description |
|---|---|
| HA infrastructure | High-availability setup on DigitalOcean with failover and redundancy |
| MCP policy | Hardened capability boundaries and policy enforcement |
| Skill sandboxing | Sandboxed execution environment for community-verified skills |
| Security pipeline | Skill verification and security scanning before marketplace publication |
| Swarm visualizer | Multi-agent orchestration UI with real-time coordination visibility |
| Write approvals | Action approval flows with cost controls and budget ceilings |
| Web dashboard and CLI | Browser-based management and command-line tooling for developers |
Phase 3 — Developer PaaS
Status: Planned
The developer adoption phase. Public APIs and marketplace create the volume play.
| Component | Description |
|---|---|
| Public API | Programmatic agent deployment for external developers |
| Multi-runtime | PicoClaw, NanoClaw, and OpenClaw alongside ZeroClaw |
| Managed provisioning | Database and cache provisioning as platform services |
| Skill marketplace | Curated marketplace MVP with community submission pipeline |
| Export Soul | Portable swarm configuration and memory export |
| Developer SDKs | Client libraries and trusted automation policies |
Phase 4 — Enterprise IaaS and Global Scale
Status: Planned
The enterprise capture phase. Multi-cloud deployment and federation create the high-value contracts.
| Component | Description |
|---|---|
| Multi-cloud | AWS, GCP, Azure, and on-premises deployment support |
| Enterprise tooling | Install-into-customer-infrastructure deployment automation |
| Custom runtimes | Proprietary or specialized runtime integration |
| Agent marketplace | Third-party agent and skill marketplace with revenue share |
| A2A federation | Agent-to-agent communication across organizational boundaries |
| Enterprise controls | Isolation, RBAC, audit, compliance, and BYOK support |
Integration Model
Adapter Architecture
The Go orchestrator owns the entire integration layer. Agents never hold raw third-party credentials. Every external API call flows through the backend adapter layer.
User connects app (OAuth)
--> Backend stores tokens
--> Agent requests capability via MCP
--> Backend adapter calls provider API
--> Normalized data returned to runtime
Design rules:
- Adapters expose narrow capabilities, not raw API passthrough
- Permissions are user-visible and revocable at any time
- Read and write scopes are always separate
- Every executed write is logged with agent ID, integration, timestamp, and payload summary
This architecture means reskilling an adapter (e.g., migrating from Google Calendar v3 to v4) requires zero changes to agent code. The adapter contract is stable; the implementation behind it can evolve freely.
Autonomy Modes
The platform supports three levels of agent autonomy, with each mode giving users clear control over what agents can do without asking.
| Mode | Behavior | When Available | Example |
|---|---|---|---|
| Auto-read | Fetch, monitor, and summarize after user consent | Phase 1 | "Summarize my unread emails" |
| Ask-before-write | Approval required for sends, creates, and updates | v1 default | "Draft a reply" requires tap to send |
| Trusted automation | Bounded by policy, scope, and configurable limits | Planned | "Auto-reply to meeting requests under 30 min" |
Policy dimensions for trusted automation include per-integration rules, per-agent permissions, per-action controls, per-scope boundaries, and per-limit thresholds (budget ceilings, rate limits, and time windows).
MCP Positioning
The Model Context Protocol is the stable capability contract between runtimes and the orchestrator.
- The orchestrator hosts an internal HTTP MCP server
- ZeroClaw connects as an MCP client
- Native Go adapters remain the real implementation behind MCP tools
- MCP becomes the stable interface for skills and runtime integrations
- Runtimes call Crawbl-owned MCP tools, not raw third-party APIs
This layering means the MCP contract is the only thing runtimes depend on. The backend can swap adapter implementations, add caching layers, or change providers without breaking any runtime or skill.
Safety Requirements
Four non-negotiable safety rules govern every integration:
Human-readable writes
Every write proposal must be understandable before a user approves it.
Instant revocation
Users can revoke permissions instantly from any interface.
Prefer undo
The platform prefers undo or compensating actions where providers support them.
No raw credentials
Agents and skills never receive raw third-party credentials.
LLM Account Model
LLM access is platform-managed, with three tiers that scale from consumer use through enterprise deployment.
| Tier | Model | Status | How It Works |
|---|---|---|---|
| Consumer / Phase 1 | Platform-owned API accounts (Anthropic, OpenAI, Gemini) | Active | Crawbl pays provider bills; usage is tracked per user and metered against subscription tier |
| Power users | BYOK (bring your own API key) | Planned | Users supply their own provider keys; Crawbl routes through them with the same audit and quota controls |
| Enterprise | Dedicated provider projects/accounts per customer | Planned | Each enterprise customer gets isolated provider accounts; Crawbl manages routing and attribution |
Rules that apply across all tiers:
- Agent runtimes never store long-lived provider secrets
- The backend stores credentials and applies quotas, attribution, and routing policy
- Usage is tracked against Crawbl users, not external provider accounts
- Cost controls and budget ceilings are enforced at the orchestrator level
Skills and Marketplace
Skill Categories
Skills are the extensibility layer of the platform. They range from trusted first-party bundles to community contributions, with strict trust boundaries between each category.
| Category | Description | Trust Level | Status |
|---|---|---|---|
| First-party default | Bundled by backend, trusted platform profile | Full trust | Phase 1 |
| Curated first-party marketplace | Premium integrations and capabilities | Full trust | Phase 3 |
| Community-verified | Reviewed, adapted, sandboxed execution | Restricted sandbox | Phase 3 |
| Unreviewed submissions | Quarantined, never executable in production | No execution | Phase 3+ |
Core Principles
- Skills receive capability access via MCP, not raw credentials
- Unreviewed user uploads are never executable in production runtimes
- Community-verified skills run in a stricter sandbox than first-party skills
- Users cannot disable the sandbox for community skills
- Raw upstream skill bundles are not installed directly into user bots
Imported Skill Adaptation
When importing skills from ClawHub or upstream sources, the platform creates a Crawbl-managed version with:
- Upstream source metadata, pinned version, and digest for reproducibility
- Declared MCP capabilities and integration requirements
- Trust tier assignment, sandbox policy, and verification suite
- Prompt modifications replacing raw env/apiKey assumptions with Crawbl MCP tools
Submission Pipeline (Phase 3+)
Upload (quarantine) --> Scan and normalize --> Adapt to Crawbl model
--> Verify in dedicated UserSwarm --> Manual review
--> Publish as Community Verified or reject
Every submitted skill goes through automated scanning, adaptation to the Crawbl security model, functional verification in an isolated runtime, and human review before it can execute in any user's swarm.
Marketplace Phases
| Phase | Marketplace State | Focus |
|---|---|---|
| Phase 1-2 | No public marketplace | Orchestrator, internal MCP, and default skills |
| Phase 3 | Curated skill marketplace | Verified skills only; install flow checks prerequisites |
| Phase 4 | Agent marketplace (conditional) | Opens only if trust model and product fit justify it |
Agent Federation
Status: Planned (Phase 4)
Agent federation enables cross-user agent-to-agent communication as a first-class product feature. This is the network-effects play — individual swarms become more valuable when they can collaborate.
Federation rules:
- Each user keeps a private swarm by default — federation is always opt-in
- Cross-user communication requires explicit consent from both parties
- Permissions must be scoped to specific agents and capabilities, and are revocable at any time
- Backend mediation is required for every cross-swarm exchange — no direct pod-to-pod access
- Every A2A connection is identity-aware, auditable, and revocable
Target use cases: Family coordination, shared trip or event planning, trusted B2B workflows between organizations, and marketplace agent collaboration.
Implementation details about the Crawbl ZeroClaw fork, multi-agent runtime support, and the image pipeline live in ZeroClaw Overview.