Roadmap
Phase 1
Validate the product with real usage
Active
The first phase proves that the platform works end to end with a real user experience, real coordination, and real operational constraints.
- Launch the core product experience.
- Run the orchestrator, runtime, and approvals as one working system.
- Learn from real traffic before widening the surface area.
Build Phases
Phase 1 — Platform Validation (Consumer App)
Status: Active
| Component | Description |
|---|---|
| Go orchestrator | Auth, provisioning, LLM mediation, and request routing |
| Capability framework | Runtime-to-backend communication interface |
| Adapter framework | Gmail and Google Calendar adapters (read-only) |
| Runtime provisioning | Per-user agent deployment via automated provisioning |
| Flutter app | Onboarding, chat, swarm UX, and integration cards |
| Default skills | Bundled first-party agents and skills |
| Infrastructure | Kubernetes deployment with GitOps management |
Phase 2 — Production Hardening
Status: Planned
| Component | Description |
|---|---|
| HA infrastructure | High-availability with failover and redundancy |
| MCP policy | Hardened capability boundaries and policy enforcement |
| Skill sandboxing | Sandboxed execution for community-verified skills |
| Security pipeline | Skill verification and scanning before publication |
| Swarm visualizer | Real-time multi-agent coordination UI |
| Write approvals | Approval flows with cost controls and budget ceilings |
| Web dashboard and CLI | Browser-based management and developer tooling |
Phase 3 — Developer PaaS
Status: Planned
| Component | Description |
|---|---|
| Public API | Programmatic agent deployment for developers |
| Multi-runtime | PicoClaw, NanoClaw, and OpenClaw options |
| Managed provisioning | Database and cache provisioning as platform services |
| Skill marketplace | Curated marketplace with community submissions |
| Export Soul | Portable swarm configuration and memory export |
| Developer SDKs | Client libraries and automation policies |
Phase 4 — Enterprise IaaS and Global Scale
Status: Planned
| Component | Description |
|---|---|
| Multi-cloud | AWS, GCP, Azure, and on-premises support |
| Enterprise tooling | Deploy-into-customer-infrastructure automation |
| Custom runtimes | Proprietary or specialized runtime integration |
| Agent marketplace | Third-party agents and skills with revenue share |
| A2A federation | Agent-to-agent communication across organizations |
| Enterprise controls | Isolation, RBAC, audit, compliance, and BYOK |
Integration Model
Agents never hold raw third-party credentials. Every external API call flows through the backend adapter layer.
- 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 write is logged with agent ID, integration, timestamp, and payload summary
Autonomy Modes
| Mode | Behavior | Example |
|---|---|---|
| Auto-read | Fetch and summarize after user consent | "Summarize my unread emails" |
| Ask-before-write | Approval required for sends, creates, updates | "Draft a reply" requires tap to send |
| Trusted automation | Bounded by policy and configurable limits (planned) | "Auto-reply to meeting requests under 30 min" |
Safety Rules
1
Step 1
Human-readable writes
Every write proposal must be understandable before a user approves it.
2
Step 2
Instant revocation
Users can revoke permissions instantly from any interface.
3
Step 3
Prefer undo
The platform prefers undo or compensating actions where providers support them.
4
Step 4
No raw credentials
Agents and skills never receive raw third-party credentials.
LLM Account Model
| Tier | How It Works | Status |
|---|---|---|
| Consumer | Crawbl pays provider bills; usage metered per user against subscription tier | Active |
| Power users (BYOK) | Users supply their own API keys; same audit and quota controls | Planned |
| Enterprise | Isolated provider accounts per customer; Crawbl manages routing | Planned |
Skills and Marketplace
Skill Categories
| Category | Trust Level | Status |
|---|---|---|
| First-party default | Full trust | Phase 1 |
| Curated first-party marketplace | Full trust | Phase 3 |
| Community-verified | Restricted sandbox | Phase 3 |
| Unreviewed submissions | No execution | Phase 3+ |
- Skills access capabilities via MCP, not raw credentials
- Unreviewed uploads are never executable in production
- Community skills always run in a stricter sandbox than first-party skills
Agent Federation (Phase 4)
Cross-user agent-to-agent communication. Swarms become more valuable when they can collaborate.
- Always opt-in; private swarm by default
- Requires explicit consent from both parties
- Scoped permissions, revocable at any time
- Every exchange goes through backend mediation with full audit trail
Implementation details about the Agent Runtime and multi-agent architecture live in Agent Runtime Overview.