Platform Roadmap & Design Principles
Dwizi is built as infrastructure for AI tools — from non-technical users creating their first tool, to power users running production-grade AI workflows.
This roadmap outlines what is coming next, but more importantly, why the platform looks the way it does today.
Many current “limitations” are intentional design decisions that prioritize security, clarity, and determinism.
Design Philosophy (Read This First)
Dwizi is opinionated by design.
- Tools are ephemeral by default
- Execution is explicit
- State is opt-in
- Infrastructure is invisible
This keeps the platform safe, predictable, and easy to reason about — especially when tools are used by AI systems.
As Dwizi evolves, new capabilities are added without breaking this mental model.
Near-Term Platform Expansions
Persistent State (Opt-In)
Today Dwizi runtimes are ephemeral. Files written to disk are discarded after execution.
This ensures:
- No hidden state
- No cross-run contamination
- Predictable behavior for AI tools
What’s Coming
A native Store API for:
- Simple key-value data
- Small structured payloads
- Explicitly scoped persistence
Persistence will be:
- Optional
- Explicit in code
- Auditable
Why This Matters AI tools should not accumulate hidden state by accident. Dwizi makes persistence a conscious choice.
Scheduled Execution
Today Tools run only when called via HTTP.
What’s Coming Native scheduling:
- Cron-style execution
- Human-readable schedules (“every weekday at 9am”)
- Time-based triggers for AI workflows
Why This Matters This enables:
- Background AI agents
- Periodic data collection
- Autonomous but controlled execution
Asynchronous & Event-Driven Runs
Today All executions are synchronous (request → response).
What’s Coming Asynchronous execution modes:
- Fire-and-forget runs
- Webhook callbacks
- Event-based triggers
Why This Matters Not all AI tools fit a request/response model. Dwizi will support long-running and background workloads without sacrificing safety.
Power User & Enterprise Capabilities
Custom Execution Environments
Today Dwizi provides hardened Node.js and Deno runtimes.
Planned Direction Support for custom execution environments via:
- Uploaded Dockerfiles
- Pre-approved runtime templates
Important This will be gated and optional.
Dwizi’s default experience will remain:
- Zero configuration
- TypeScript-first
- Secure by default
Why This Matters Enterprises need flexibility. AI platforms need guardrails. Dwizi provides both.
Command-Line Interface (CLI)
Today Tools are managed via the Web UI and API.
What’s Coming
A first-party CLI (dwizi) to:
- Deploy tools from local code
- Manage environments
- Automate workflows
Why This Matters This enables CI/CD, reproducibility, and advanced workflows without changing the core platform model.
Operational & Governance Features
These features are required for enterprise adoption and large teams.
Usage & Observability
- Execution counts
- Runtime metrics
- Streaming visibility
Billing & Cost Controls
- Usage-based billing
- Team-level limits
- Predictable cost envelopes
Auditability
- Team audit logs
- Configuration history
- Execution traceability
Relation to AI Tooling & MCP
Dwizi is designed to support:
- AI tools
- Agent frameworks
- Model Context Protocol (MCP)
- JSON-RPC style execution patterns
Each Dwizi tool:
- Exposes a stable URL
- Accepts explicit inputs
- Produces deterministic outputs
- Executes in an isolated runtime
This makes Dwizi suitable as infrastructure for AI tools, not just a developer platform.
What Dwizi Will Not Become
Dwizi is intentionally not:
- A general-purpose VM host
- A long-running application platform
- A replacement for traditional backend servers
Dwizi exists to run tools, not services.
Roadmap Summary
Dwizi is evolving toward:
- Controlled state
- Event-driven execution
- Enterprise-grade governance
- AI-native infrastructure primitives
All without compromising:
- Simplicity
- Safety
- Clarity