Personal AI Agents Compared: Dots, Muse, Cue and Grok

Dots, Muse, Cue and Grok Team Bots all offer ongoing assistance, but they are not interchangeable products. Some act for an individual, one emphasizes shared team configuration, and access ranges from staged rollout to invite-only early use. Choose from the job and permission boundary you need, not from a generic claim that an agent can do everything.

This dated chapter keeps its original context; our maintained frontier model guide covers current API prices, access limits, and workload selection.

Written October 1, 2026 and dated September 30, 2026, using the dated announcements cited below. Later product developments are outside this article’s scope.

We compared vendor announcements dated through September 30 across runtime, app access, approvals, pricing and availability. Sources were checked October 1. This is a documentation comparison, not a hands-on benchmark. A missing detail means the cited material did not establish it, not that the product lacks the feature.

The chronology matters. Dots was announced September 29. Personal Muse launched September 8, followed by separate enterprise and small-business announcements on September 28 and 29. Manus introduced Cue within its September 28 Manus 2.0 announcement. Grok Team Bots entered public beta September 28.

The Manus 2.0 announcement names Cue as a standalone personal-agent app. Do not transfer the broader product’s local-computer or automation claims into Cue without supporting documentation. Likewise, the earlier Grok Bot launch describes the underlying cloud design, while the Team Bots announcement supplies the team access and sharing rules.

Meta’s small-business announcement adds business connections and confirms US and Canada access. That does not turn the separate Enterprise Platform into the same consumer product. Keep the identity and administration requirements of the offering you intend to use.

A budget, a permission and an approval are different controls. A budget limits expenditure; a permission determines what a tool can reach; an approval authorizes a particular action or class of actions. An agent may satisfy one condition without satisfying the others. Ask the vendor or inspect current documentation for the exact workflow you intend to run.

Use a harmless pilot to test the boundary that matters. If a task must prepare a message and wait, check that behavior with a test recipient and no sensitive content. Inspect the activity record and the cancellation path. Our permission-default guide explains why a clear instruction should be paired with bounded access.

Do not substitute model API prices for the cost of an agent product. The product may include computer time, tools, subscriptions or different usage allowances. A label such as free early access also does not make purchases performed by an agent free. Record actual accepted-task cost once a controlled trial is available.

The published evidence does not justify a lowest-price winner. It does support a practical eligibility screen: can your account access the product, can it connect the required inputs, and are the permission and review mechanisms sufficient for the task?

Pick one task with a fixed input and an observable finish. Compare the quality of the result, the handling of uncertainty and the time spent supervising it. A persistent agent should be evaluated on complete assignments, including interruptions and denied actions, rather than a single impressive demonstration.

Our dots guide provides a first-task contract, and the runtime comparison provides technical boundary questions. The AI transformation service helps teams design such a pilot.

Four offerings announced within a month invite a side-by-side table, and the table goes wrong wherever it treats different things as the same. The illustrative comparisons below each do that once. They are patterns drawn from the announcements, not reviews anyone has published.

Each comparison answered a question the sources do not, which is why the conclusion puts access first, controls second and complete outcomes third. The screen in the next section is that order written out.

The first two are errors of scope and date that the chronology paragraph in the first section already guards against; the second two are errors of substitution, a model price for a product price and an invitation for an entitlement. All four are made before any agent runs a task, which is the point of screening before comparing: a table built on them would rank four products on facts that are not about those products, and a pilot chosen from it would test the wrong offering under the wrong assumptions.

The cost section says the evidence supports a practical eligibility screen rather than a winner, and the screen has four questions in order. Can your account reach the product: the market, the plan, the beta or invite requirement, and for team offerings the administration and identity requirements, taken from the access column rather than from the plan name. Can it connect the inputs the task needs, with the connections limited to that task. Are the published controls sufficient for the task, read with the three distinctions the controls section draws: a budget limits spend, a permission decides what a tool can reach, and an approval authorizes an action, and an agent may satisfy one without the others. And does a harmless pilot confirm the boundary that matters: a message prepared and held, the activity record showing the attempt, and the cancellation path working.

An illustrative screen for a team that wants a weekly competitor brief reads: access, two of the four offerings available in the team’s market and plan today, one in enterprise beta needing an administrator, one by invitation; inputs, the three public sources connectable on both available offerings; controls, one offering publishes an approval rule for external messages and one does not, with the gap recorded as a gap rather than as absence; pilot, the brief prepared and held on the first offering with the record showing the held message, the second untested pending the control documentation. The comparison that follows is between the offerings that passed, on complete assignments.

The screen keeps unpublished details visible, as the takeaways ask. A missing price or an undocumented approval policy is written as missing at the step where it mattered, which is the form in which it can be checked later when the vendor publishes it.