Omni moved your AI agent to the cloud. The platform team came with it.

"Stop babysitting your AI agents." 1

That is the pitch for Omni, xpander's new agent-building product. On August 17, xpander announced general availability of its enterprise agent platform alongside a $7.5 million seed round, with Omni as the platform's built-in "AI forward-deployed engineer." 2

The useful translation is smaller and more interesting: Omni turns a business outcome into an agent, a frontend, and a cloud runtime. The catch is that the laptop babysitting does not disappear. It becomes connector setup, permission design, data review, runtime policy, and a bill that the public launch page declines to quantify.

Omni starts with an outcome rather than a blank agent configuration. You describe something like a Redshift analyzer or a customer-escalation hub, and the product is supposed to design the frontend, create the backend agent, attach the tools and data, and produce a first live surface. The official documentation describes the flow as five steps: describe the outcome, design the application, connect the model and tools, run the work through tracked tasks, then present the result in shareable surfaces such as reports and dashboards. 3

That is a decent product decision. Most agent builders make the user think in terms of prompts, tools, and chains before the user has decided what the work should look like. Omni starts with the thing a team wants to hand to another team. The frontend is the bait: chat, live status, reports, charts, forms, and approvals arrive as part of the application shell. 4

The backend is where the friendly chat ends. The builder still has to supply the model, system prompt, skills, tools, data access, and execution engine. A Redshift analyzer needs a Redshift connector, access to the right schemas, and a charting skill. A support workflow needs access to ticket and CRM systems. The docs say to keep those capabilities focused because a smaller permission surface is easier to trust and govern. 4

The quickstart makes the sequence plain. A new user needs an xpander account, chooses the xpander-cloud environment and OpenClaw runtime, enables tools such as web search or email, authorizes connectors such as Slack, and publishes the configuration before the changes take effect. The monitor then exposes messages, tool calls, and usage metrics. 5

The problem xpander is attacking is real. Its launch post says agents running on employee laptops leave the company without a clear view of what each agent accessed, which tools and APIs it used, who authorized an action, or whether the workflow can be reused by anyone else. The pitch is to move that work into infrastructure the company can govern, audit, and share. 2

The architectural answer is a control plane. xpander says its platform supplies an agent registry, approved connectors and MCP servers, a policy engine, runtime profiles, model and budget controls, plus logs for runs, traces, tool calls, approvals, costs, and failures. It can run in the cloud, a private VPC, or an air-gapped environment. 6

That is useful infrastructure. It is also the part of the product that makes the phrase "stop babysitting" wobble. The laptop was never the whole problem. The laptop was simply where the permissions and failure modes were easiest to ignore. Move the agent to a cloud runtime and somebody still has to decide which systems it can reach, which data boundaries apply, which actions need approval, how much it may spend, and what happens when a run stalls.

Omni can automate the construction of that workflow, but the customer still owns the definition of a safe workflow. A product that asks "which systems should I connect?" has already admitted the real job. The agent is not autonomous at the boundary where the work becomes consequential. The boundary has been turned into a setup question.

The hosted version also changes who handles the work's raw material. xpander's privacy policy says platform content can include prompts and responses, text, files, documents, photos, images, metadata, and content sent through the platform or resulting APIs. It also says xpander may receive personal information from third-party services used with the platform. 7

The policy gives Google Workspace data a tighter promise: information from Gmail, Drive, Calendar, Docs, Sheets, and Meet is used at inference time to fulfill a user's request and is not used to train or improve generalized or third-party models. For individual users outside a corporate customer, the same policy says xpander may use personal information to train and refine its AI models. Selected language models and other service providers also process data according to their own policies. 7

That is a more complicated data path than the launch slogan suggests. The customer chooses the agent's tools and model, but the customer also has to understand which prompts, files, API results, and connector data pass through xpander and its model providers. The policy's strongest guarantees apply to specific data classes and customer contexts. They do not turn every connected service into a private local process.

The terms push even more responsibility back to the buyer. They define customer data to include code, information, configuration, and prompts; grant xpander and its subprocessors rights to access, use, process, copy, download, store, distribute, and display that data to maintain, develop, and provide the service; and tell the customer to ensure it has the necessary permissions. The terms also say customers should not transfer personal data or specially protected data to the service, while making human review and verification the customer's responsibility for AI outputs. 8

This is the structural roast: Omni sells a cleaner front door for agent creation while the back office remains a normal enterprise integration project. The product may make that project faster. It does not make the project optional.

The public launch post says teams can try xpander for free and describes pricing as usage-based, tied to what agents accomplish, with no seat fees or builder fees. Product Hunt labels Omni as having free options. Neither public page supplies a numeric rate card for the hosted Omni experience. 12

That pricing choice matches the product's shape. A usage meter can make an occasional agent cheap to try, while long-running tasks, repeated failures, model comparisons, background workflows, and large connector payloads turn the same product into an operating expense. The launch material tells buyers that the meter follows outcomes. It leaves the reader to ask how outcomes are counted before committing a real workflow.

The access path is also split. Omni is presented as a generalist agent that works across Slack, WhatsApp, Telegram, email, and its own interface, while the broader platform targets enterprises that need governed infrastructure, private systems, self-hosting, model choice, and audit trails. 23

That gives Omni two different buyers. One is a technically capable team that wants a faster route from a request to a working internal app. The other is a platform or security group that wants to standardize how agents run. The first buyer wants less setup. The second buyer becomes the setup.

Omni is not a new model or a new category of execution engine. xpander describes it as an experience built on the same universal harness as the rest of its platform. That harness is supposed to connect different models and frameworks, run agents in controlled environments, handle tool calls and sandboxed code, preserve memory, recover from failures, and expose the resulting traces and costs. 2

The new part is the packaging. Omni puts a forward-deployed engineer persona in front of that runtime and lets a user describe the desired application in ordinary language. The company has tried the underlying pattern inside its platform already; this launch turns the control plane into the product experience and makes the first conversation feel like the implementation plan.

That is why the product is easy to like and easy to misunderstand. The chat is a better starting point than a blank agent console. The generated app can expose a real workflow instead of another answer box. The infrastructure underneath still asks for the same decisions that every serious agent deployment asks for. A fluent build conversation can hide those decisions from the first screen, but it cannot make them disappear from production.

Omni is a useful front end for teams that already have a real workflow, the right connector owners, and someone prepared to measure runtime cost and review permissions. Its outcome-first builder, live surfaces, task monitoring, multi-model support, and controlled deployment options address the exact mess that desktop agents leave behind. 36 But the product's promise is backwards at the point that matters: it does not end agent babysitting, it relocates it into a platform team, a data-processing chain, and an undisclosed usage meter. Try it when the connector map and failure budget already exist. Otherwise, Omni moved your agent to the cloud and brought the platform team with it.