# Vision for tusq.cloud ## Mission tusq.cloud is the shortest path from "we have a codebase" to "our product is AI-native in production." It exists for the product and engineering leaders who have already decided they are going to ship an AI-native version of their product and refuse to spend six months building the infrastructure to do it. ## The bet Every incumbent SaaS company is about to face a version of itself rebuilt by a smaller team with a conversational interface on top. The incumbent's advantage is existing product logic. Its disadvantage is the time it takes to expose that logic safely to agents, embed it into new interfaces, run it across environments, and operate it at production scale. tusq.cloud compresses that time from quarters into weeks. This is a product and engineering problem, not a compliance problem. Governance is part of the product because you cannot ship without it, not because it is the pitch. ## The promise A customer adopts tusq.dev, reviews the generated manifest, and connects it to tusq.cloud. From that moment: - A hosted runtime executes capabilities safely across environments. - An embedded assistant, command palette, or MCP endpoint is live. - Traces, replays, approvals, and environment rollouts are running. - The product and engineering team iterates on AI behavior at the same cadence they iterate on the product. No internal build. No six-month detour. No in-house AI platform team. ## What tusq.cloud is tusq.cloud is the managed control plane that wraps the tusq.dev engine with: - multi-environment hosted execution - tenant-aware identity and credential handling - approvals and confirmation workflows - session traces and replay - version registries and rollout controls - hosted MCP endpoints - embedded assistant and widget delivery - dashboards for reliability, drift, and usage It is the operating system around the engine. It is what makes the engine runnable by a real team at real scale. ## The buyer and the pitch The buyer is the VP of Engineering or Head of Product who has looked at an AI-native competitor and done the math on building the equivalent internally. They have concluded it takes two or three engineers six months and will still be worse than what a specialized team can ship. The pitch to that buyer is direct: "Your existing product is your advantage. tusq.dev turns it into capabilities. tusq.cloud puts those capabilities in front of users in weeks. You will not rebuild your AI stack; you will rent the part that does not differentiate you and keep iterating on the part that does." Security and compliance buyers matter, and tusq.cloud has to pass their review. But the sale is made in engineering and product, not in the security review. ## Why a hosted product must exist Even a strong OSS engine does not run itself in production. Real deployment creates problems that are operational, not conceptual: - mapping end-user identity into tool execution across tenants - rotating credentials without leaking them into traces - isolating execution between environments and customers - retaining traces long enough to debug failures months later - gating risky capabilities behind approval workflows that product and engineering actually use - surfacing drift between manifest versions across environments - shipping embedded interfaces with brand, theme, and rollout controls - staying online Every one of those is worth solving once, centrally, rather than by every customer separately. That is the commercial logic of the cloud product. ## The product domains ### 1. Environments and rollout Organizations, projects, dev/staging/production, repository and manifest bindings, role-based access. The substrate that makes everything else predictable. ### 2. Registry and versioning Manifests, tools, skills, and domain agents stored with full version history, approval state, promotion flow, and diffs. Obvious answers to "what is running where, and who approved it." ### 3. Hosted execution Tenant-aware runtime that resolves intent into capabilities, applies policy, obtains credentials, executes tools safely, handles retries, streams where needed, records traces, and returns attributable results. ### 4. Approvals and governance Product, engineering, and security each get workflows that match how they actually work. Approvals are fast for common cases, strict where side effects are large, and always inspectable. ### 5. Traces, replay, and diagnostics Every meaningful interaction is inspectable and replayable. Why did the agent do this. Which tool ran. Which policy decided. Which version was active. What changed between runs. This is a first-class surface, not a log viewer. ### 6. Hosted MCP and interfaces Hosted MCP endpoints for external AI clients. Embedded widgets, command palettes, and inline surfaces for end-user interfaces. Environment-aware rollout so a change hits staging before production. ### 7. Reliability and usage analytics Top capabilities, failure modes, approval bottlenecks, drift, and latency. The layer that turns "we shipped an AI interface" into "we know what our AI interface is doing and what to build next." ## Why we move fast This product is being built by a team using AI to write code. Our customers are racing competitors using AI to rewrite their products. The category is being defined in months. That shapes the roadmap: - Hosted MCP endpoints are day one, not phase five. - Replay and approvals ship alongside execution, not after. - Embedded widgets exist from the start so a customer can prove the system in front of users in a single week. - Environment and rollout controls are never optional, because you cannot claim to be a production platform without them. - Enterprise controls follow quickly because the buyers we want require them. The historical pattern of "ship the control plane, then slowly add governance, then slowly add distribution" is too slow. We collapse the timeline. ## The OSS and cloud boundary tusq.dev stays genuinely useful on its own. The engine is not crippled. A team that wants to self-host every piece of this can do so and should. tusq.cloud wins because: - it removes the operational work that no customer wants to own - it runs a hosted MCP fleet that external AI clients can consume at scale - it aggregates trace data across environments to make drift and failure visible in ways a single self-hosted instance cannot - it turns policy, approvals, and rollout into workflows the whole team uses, not a config file one person edits - it gives the business the support, reliability, and evidence that production deployments require The boundary is operational, not conceptual. That is the defensible split. ## What tusq.cloud is not - It is not a chatbot admin panel. If it feels like one, the product is underbuilt. - It is not a wrapper over the OSS runtime. If it could be replaced by a docker-compose, it has not justified itself. - It is not an AI safety product. Safety is required. Speed is the pitch. - It is not neutral about opinions. It makes opinionated choices about how AI-native products should ship so customers do not have to. ## Pricing logic Pricing follows usage the customer controls: environments, execution volume, retained traces, hosted MCP usage, team seats, advanced workflows, and enterprise features. Early customers should never feel punished for experimenting. Revenue scales with production adoption, not with pilot activity. ## North-star customer outcome Three weeks after adoption: - The customer has a live AI-native interface in front of real users. - Their internal product and engineering team is iterating on it weekly. - Their external partners and AI clients consume the same capabilities through a hosted MCP endpoint. - Their security team has the evidence they need without a dedicated integration. - Their competitors are still designing the system the customer already shipped. That is the outcome the product is built to deliver. ## Vision for maturity At maturity, tusq.cloud is the default way SaaS companies ship AI-native interfaces on top of existing products. It is the layer a VP of Engineering names when asked how they got to production so quickly. It is the system external AI clients reach to actually do something useful inside a SaaS product. It becomes obvious, in retrospect, that the companies that survived the AI-native transition were the ones that treated their existing product logic as the asset and moved first to expose it. ## Final statement tusq.cloud is the managed control plane that turns tusq.dev from a powerful open-source engine into a production system a real team can run. It exists so the SaaS companies with the most product logic stop losing to the startups with the fastest interfaces. The open-source engine is the weapon. The cloud product is how it gets fired in time.