> For the complete documentation index, see [llms.txt](https://dappos.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dappos.gitbook.io/docs/dappos/xbubble/what-is-xbubble.md). # What Is xBubble? xBubble is DAPPOS's flagship low-prompt AI product. It is designed for users who want to access cutting-edge AI productivity without becoming expert AI operators. Instead of asking every user to learn how to prompt, compare models, assemble tools, configure APIs, write Skills, manage runtime environments, and repeatedly test outputs, xBubble moves much of that operational complexity into the system. xBubble lets users complete tasks with simpler prompts by automatically building and dispatching task-specific AI agents. It turns short requests into deliverable work across image and video, websites, documents, research, automation, and scheduled solutions. #### A Product Built Around User Goals The product thesis is simple: Users state the goal.\ xBubble handles the AI operation. This does not mean removing user intent. Users still describe what they want, provide context, define preferences, and decide whether the result is useful. xBubble does not replace the user’s goal-setting role. Instead, xBubble reduces the technical and procedural burden that usually sits between a user’s goal and a usable AI result. In a normal AI workflow, a user may need to make a long chain of operational decisions: * Which model should be used? * How should the prompt be structured? * Which Skill, tool, API, or agent should be connected? * What runtime environment is needed? * How should intermediate results be checked? * What should happen when the output fails? * How should the workflow be reused next time? For technical users and AI power users, these decisions can be part of the workflow. For most users, they become friction. The more powerful AI becomes, the more users may need to understand model behavior, tool behavior, context design, and failure recovery in order to get stable results. xBubble is built to reduce that friction. #### From AI Capability to AI Operation Many AI products give users access to powerful models, but access alone is not enough. A user still has to operate the model correctly. This is where xBubble focuses. Model choice, prompt structure, Skill writing, tool selection, runtime setup, API configuration, and result testing move from users into the system wherever possible. The user still defines the task, but the system takes over more of the operational work required to complete it. In this sense, xBubble is not only a prompt interface. It is a product layer for operating AI capabilities on behalf of the user. #### Bubble Engine and Bubble Pilot At the architecture level, xBubble is built around two systems: Bubble Engine and Bubble Pilot. **Bubble Engine** Bubble Engine is the system that builds AI solutions. For a given task type, Bubble Engine can generate task-specific solution variants, test them, evaluate outputs, and turn stronger execution paths into reusable SOPs. Its role is to learn how a task should be solved, package that solution, and improve it over time as better execution paths are discovered. **Bubble Pilot** Bubble Pilot is the runtime dispatch layer. It reads a user request, identifies the task type, checks whether a suitable SOP exists, and routes the task to the best available solution. If no specialized SOP fits, the request can fall back to a more general execution path. Its role is to use the right AI solution for the user’s current request. **SOPs as the Link** SOPs connect Bubble Engine and Bubble Pilot. Bubble Engine creates and improves SOPs. Bubble Pilot selects and runs them. An SOP gives xBubble a reusable execution path for a specific type of task. When a request matches a verified SOP, the user does not need to manually configure the model, tool chain, runtime, APIs, MCPs, and execution logic. #### More Than a Generic AI Chat Interface xBubble is different from a generic AI chat interface. A generic interface gives users access to model capability, but often leaves users responsible for operating that capability. Users must decide how to prompt, which tools to connect, how to test the result, and how to recover from failure. xBubble is designed to package AI capability into task-specific workflows. The goal is to help users get closer to finished work with fewer prompts, less trial-and-error, and a lower learning curve. #### More Than a Skill Marketplace xBubble is also different from a simple marketplace of isolated tools or Skills. An xBubble SOP is not only a Skill. It can package the Skill, runtime environment, APIs, MCPs, model selection, and execution logic required for a specific task type. This matters because real AI output quality often depends not only on the prompt, but also on the surrounding environment: * Which model is selected * Which tools are available * Which APIs are connected * Which runtime environment is used * How the task is executed * How the output is evaluated * Whether the workflow has been tested for the task type By packaging these elements together, xBubble aims to reduce the number of configuration decisions that users must make themselves. #### xBubble in the DAPPOS Ecosystem In the DAPPOS ecosystem, xBubble serves as the flagship general AI productivity product. It applies DAPPOS’s AI operating system approach to everyday and professional workflows such as documents, slides, websites, images, videos, research, automation, scheduled tasks, and Bubble Code workflows. As models, coding agents, APIs, MCPs, and tool ecosystems continue to evolve, xBubble’s role is to make these capabilities easier to operate through reusable, task-specific AI solutions. xBubble is built for users who know what they want, but do not want to learn how AI is operated. AI should learn AI.\ AI should use AI.\ Users should state goals.