Workweaver is one operating layer: Zara shapes intent into Missions, the Mission Calendar releases work into TimeBlocks, Operational Context loads the right memory and permissions, and Decision Trace records what happened. Here's what's shipped, what's partial, and what's planned.
Zara turns intent into ready work, checks existing Skills, proposes release timing, and keeps active Missions, approvals, and quick actions in one workspace.
Planned and executed work is tied to goals through the Mission Calendar. TimeBlocks are the release units for governed execution, manual release, or explicit autonomy policy.
Operational Context loads evidence, WorkMemory, Skills, tool state, and permissions before action. Decision Trace records the side effects, approvals, and outcomes that follow.
Company context for Zara and connected agents. WorkMemory is a
bundled surface of the one Workweaver product at
/memory/, not a separate SKU or subdomain.
One Connectors surface for all integrations. The first-run lane surfaces the most common tools, with deeper connectors available on the same substrate.
OAuth-backed, backend-verified integrations surfaced by default.
Canonical hub for discovering, connecting, and managing all integrations. Backend-verified OAuth flows. All connectors discoverable through a single surface after sign-in.
Telegram, Microsoft Teams, and Zoho Cliq remain guided rollout or organization-specific bridges until the claim matrix has stronger evidence.
Trust is built into the execution model, not bolted on after the fact. These are shipped capabilities, not planned features.
High-risk actions require explicit human approval. Mission approval state is normalized across backend and frontend. Approvals are captured in the Evidence Ledger with actor timestamps.
Suppression rules (email, SMS, WhatsApp, voice), pacing controls, and bounce/complaint handling. Cadence v0 provides a persistent operational ledger for campaigns with pause, resume, stop, skip, and retry.
Inline learning auto-wired into task execution. Durable skill registry with version mutation and rollback. In-product review, approve, reject, and rollback for prompt and version changes.
Three default entry points that execute the full path: research, draft, approve, send, proof. Custom workflow authoring is still in guided rollout and not yet the default self-serve path.
Reads live systems on a schedule, assembles the day's priorities, and delivers a visible briefing with proof. Runs on inbox, calendar, and team context.
Triages email and calendar pressure together, suggests next moves, and keeps approvals visible. Reduces the daily inbox review to a clear summary.
Follows up from CRM truth, messages on approved channels, and keeps the mission, proof, and approvals in one chain. Research to draft to approved send.
Workweaver is explicit about what's shipped and what isn't. These areas are functional but not fully complete.
Uses Kimi as the primary non-voice reasoning path with Grok as the fallback. When provider credentials are unavailable the surface degrades to a deterministic scaffold with explicit warnings.
Returns identity_status=partial with explicit
channel results (email, phone, calendar). External provider
credential completeness still needed for full elevation.
Data exists in the backend Evidence Ledger. Customer-facing retrieval and rendering continues to get deeper before stronger visual proof claims are published.
WhatsApp runtime and Slack/Teams/Cliq bridges exist. Mobile operations are incomplete. Desktop and edge-device control are not in scope.
Clear boundaries are part of the product's design. These are deliberate exclusions, not missing features.
Browser automation is available for designated web tasks via a sandboxed executor. No local desktop, native application, or system-level process control.
There is no local agent that runs on your laptop, phone, or IoT device. Execution is cloud-first by design for security and auditability.
Workweaver will not send messages, update CRM records, or modify calendar entries without explicit human approval. This is a design constraint, not a limitation.
Start with Zara now. Use the waitlist only when you need guided rollout access or a staged workspace launch.
Talk to Zara