# tusq.cloud tusq.cloud is the managed control plane for Tusq: the hosted layer that helps SaaS teams ship safe, production-grade AI interfaces on top of their existing products without rebuilding their stack. The open-source engine lives in `tusq.dev`. That engine discovers product capabilities from code, APIs, schemas, and runtime behavior, then compiles those capabilities into governed tools, skills, and agent surfaces. tusq.cloud commercializes the hard operational layer around that engine: multi-tenant execution boundaries, policy administration, approvals, hosted MCP endpoints, observability, replay, analytics, identity mapping, secrets handling, and team workflows. The boundary matters. tusq.cloud is not meant to replace the open-source core. It is meant to make the hard parts of running AI-enabled product infrastructure safe, fast, collaborative, and reliable enough for real businesses. ## What tusq.cloud is tusq.cloud is the hosted product for teams that want: - a secure control plane for AI-callable product capabilities - hosted execution infrastructure for governed tool use - dashboards for traces, reliability, approvals, and drift - team management, access control, and audit workflows - managed MCP endpoints and widget delivery - a commercial support and SLA surface In short: `tusq.dev` is the engine, and `tusq.cloud` is the managed operating system around that engine. ## What problem it solves Modern SaaS companies already have most of the product value they need: - business logic behind APIs - role models and permission systems - data models and workflows - domain semantics encoded in code - customer-facing operations such as billing, refunds, provisioning, reporting, and approvals What they often do not have is a safe way to expose that existing logic through AI-native interfaces. If they rush, they risk: - unsafe action execution - overpowered assistants - bad permission boundaries - no audit trail - no replay capability - no clear approval path - brittle wrappers around unstable prompts tusq.cloud solves that by giving them a managed platform for: 1. importing or syncing capability definitions produced by tusq.dev 2. governing those capabilities with policies and approvals 3. executing them inside a controlled hosted boundary 4. observing and replaying behavior like software, not magic 5. distributing AI-native interfaces through embedded widgets and MCP ## Product thesis Every SaaS company is becoming an AI product whether it wants to or not. The market is shifting from: - navigation -> intent - clicks -> outcomes - page flows -> conversations and command palettes - manual operator work -> AI-assisted execution The winning companies will not necessarily be the ones that rewrite everything first. They will be the ones that convert the product logic they already own into safe, composable, AI-callable capabilities faster than competitors can replace them. tusq.cloud exists to accelerate that shift without forcing every customer to become an AI infrastructure company. ## Core product promise With tusq.cloud, a SaaS company should be able to: 1. connect one or more repositories through tusq.dev or a guided onboarding path 2. review and approve a capability manifest 3. apply security and policy rules to those capabilities 4. publish governed tools, skills, and domain agents 5. enable an embedded assistant, hosted MCP endpoint, or partner-facing integration 6. inspect traces, approvals, failures, and drift in a dashboard 7. iterate with confidence because everything is observable and replayable The product remains their product. tusq.cloud becomes the hosted AI action layer on top. ## How tusq.cloud fits with tusq.dev ### tusq.dev owns - codebase ingestion and discovery - capability manifest generation - tool and skill compilation - self-hosted local runtime - self-hosted MCP server - basic widget and integration primitives - plugin-based extensibility ### tusq.cloud owns - hosted multi-tenant runtime boundaries - secrets vaulting and short-lived credential issuance - policy administration UI - approval and escalation workflows - session traces and replay storage - reliability and usage analytics - team and environment management - registry management and version history - hosted MCP endpoints - widget delivery infrastructure - enterprise controls and support This separation should stay crisp. Customers should be able to understand exactly what they get by self-hosting and exactly what they gain by moving to the cloud product. ## Product pillars ### 1. Governed execution Every tool call that matters should be governed by: - the acting identity - the tenant context - policy rules - confirmation or approval requirements - side-effect classification - scope-limited credentials - audit logging The point is not just to "make AI work." The point is to make AI behavior acceptable inside real businesses. ### 2. Observability and replay AI infrastructure without debuggability is not infrastructure. tusq.cloud should let customers inspect: - what the user asked - what the agent inferred - which tools were considered - which tools were executed - what arguments were passed - what failed - which policy blocked or allowed the action - how a newer version differs from an older one Replay should be a first-class product surface, not an afterthought. ### 3. Distribution tusq.cloud should make it easy to ship AI-native interfaces into production: - embedded chat widgets - command-palette experiences - optional voice surfaces - inline contextual actions - hosted MCP endpoints for AI clients - future marketplace-style distributions where appropriate ### 4. Operations The managed product must remove operational pain, not just repackage the OSS: - credential lifecycle management - execution isolation - hosted policy workflows - environment separation - trace retention - scale, uptime, and reliability ### 5. Team workflows Real adoption requires collaboration: - product teams need to review capability manifests - engineering teams need to approve schemas and boundaries - security teams need policies and audit exports - support and operations teams need to inspect agent behavior tusq.cloud should be as much a collaboration surface as an execution surface. ## Primary users ### Engineering leaders They need a practical path to make an existing SaaS product AI-native without launching a rewrite. ### Product leaders They want AI surfaces that feel like part of the product, not bolted-on bots. ### Platform and security teams They care about scoped execution, policy enforcement, auditability, data handling, and operational boundaries. ### Growth-stage SaaS teams They want speed, but they do not want to build their own AI control plane from scratch. ### Enterprise SaaS teams They need hosted guardrails, approvals, environment management, and evidence for security reviews. ## Core surfaces ### Control plane The central hosted dashboard should let teams: - onboard repositories and environments - import or sync manifests - review generated tools and skills - manage versions - configure policies - inspect traces - approve or reject risky actions - administer teams and environments ### Hosted runtime The runtime should support: - tenant-aware execution - environment isolation - tool invocation with scoped credentials - rate limiting and retries - idempotent write handling where available - streaming and long-running task support - policy and approval checks before execution ### Hosted MCP Each tenant should be able to expose a hosted MCP endpoint backed by its approved and policy-governed capability set. The hosted MCP layer is one of the strongest commercial surfaces because customers get distribution into the broader AI ecosystem without running their own MCP infrastructure. ### Widgets and distribution The cloud product should host: - widget bundles - theme settings - embed configuration - environment-aware rollout controls - analytics around widget behavior and tool use ### Analytics and reliability Core analytics should include: - session volume - tool-call success rate - failure categories - approval rates - blocked-action rates - latency by tool - drift frequency - top-used capabilities - fallback and escalation patterns ## Security model tusq.cloud has to be credible on security from day one. Baseline expectations: - tenant isolation by design - strict credential scoping - short-lived tokens where possible - secrets never exposed in logs - configurable redaction - encryption at rest and in transit - role-based team access - environment separation - audit exports - configurable retention The messaging should stay concrete. Customers will trust explicit boundaries and real controls more than broad AI safety claims. ## Commercial logic tusq.cloud is where Tusq can justify commercial pricing because it hosts the expensive and operationally difficult parts: - secure hosted execution - observability and replay storage - hosted MCP infrastructure - version registries - policy workflows - team and tenant management - enterprise audit and compliance features - operational reliability and support The OSS project should remain real and valuable. The cloud product should win because it saves time, reduces risk, and enables production usage, not because the OSS is artificially weakened. ## What success looks like A successful tusq.cloud deployment should feel like this: - the customer connects their codebase - the manifest is generated and reviewed - risky actions are properly gated - a brand-native assistant goes live - customers use it to complete real product tasks - security can inspect who did what and why - engineering can replay failures - product can see which capabilities matter most - the customer expands the surface with confidence instead of fear ## Near-term roadmap ### Phase 1: hosted control plane foundation - organizations, workspaces, environments - manifest import and review - tool and skill registry UI - basic hosted traces - basic policy model ### Phase 2: governed hosted execution - execution runtime - tenant identity mapping - secrets handling - confirmation and approval flows - hosted MCP endpoints ### Phase 3: analytics and trust - replay - diffs between versions - reliability dashboards - drift visibility - audit export workflows ### Phase 4: interface delivery - widget hosting and configuration - theme tokens and branding - environment-aware rollout - command-palette and inline surfaces ### Phase 5: enterprise and ecosystem - stronger policy packs - admin workflows - marketplace and partner distribution - advanced compliance and support features ## Positioning Tusq is not a chatbot vendor. Tusq is the agent enablement and governance layer that turns a SaaS product's existing business logic into safe, observable, AI-callable capabilities. Within that story: - `tusq.dev` is the open-source engine - `tusq.cloud` is the managed control plane and commercial product ## Status This directory should become the home of the managed product, its docs, onboarding flows, dashboard, hosted runtime surfaces, and commercial packaging. The job of this repository is to make the product boundary sharp before implementation begins, so the architecture, messaging, and OSS/commercial split stay coherent as the system grows.