The Manager You Didn't Apply For

Six products shipped or materially expanded in the past two weeks: Dots from OpenAI, Muse from Meta, Gemini agent from Google, Sesame, Tab, and Ghost. They share one architecture. Each keeps persistent context, runs in a private execution environment, works in the background, and takes instructions through conversation.

Most coverage sorts them by interface: voice, chat, SMS, eyewear, local hardware. Interface tells you how you'll talk to the agent. It doesn't tell you what the agent will cost you. Sort them instead by something none of the six measures: how much of your time each one consumes to operate safely.

All six hand you a management job. The useful comparison is what that job involves at each one.

Five costs of delegation

Give a persistent agent a goal and walk away, and you pick up five supervisory costs. Where each product sits on each cost tells you more than a feature comparison will.

Specification clarity: how precisely you have to describe what you want before the agent can act without misreading you. Dots and Sesame both accept natural-language goals, and Sesame lets you define "skills" with triggers and schedules. Neither publishes a structured constraint schema. Anticipating the edge cases the agent won't ask about is your job.

Permission configuration: how much time you spend deciding what the agent can and can't touch. Muse has the most explicit architecture in the set. A component called Sentinel evaluates each proposed action before execution, and permission grants are scoped by duration: one-time, session, task, time-bounded, or perpetual. Tab's terms describe transaction-level protections (stop if terms change, don't silently retry a charge). Sesame documents that Gmail sending requires approval but doesn't say whether Calendar creation or deletion gets the same treatment. Ghost's founder told TechCrunch that users will control autonomy levels, but the product hadn't shipped at the time of writing.

Ghost belongs in this comparison anyway. Its $11M bet on dedicated local hardware is an architectural commitment with supervisory consequences, because local execution changes permission and recovery characteristics in ways a cloud agent can't replicate. Whether that matters in practice is speculative until units ship.

Monitoring attention: how often you need to check whether the agent is stuck, waiting, or doing something you didn't expect.

Exception handling: what happens when something goes wrong mid-task.

Recovery: what happens after something has already gone wrong, when the agent has taken a real-world action you now need to undo or compensate for.

The products diverge on the first two. On the last three they converge, and what they converge on is very little. Exception handling shows it most clearly. Muse classifies certain actions as "hard to undo" and stops before executing them, but doesn't disclose how it classifies. Gemini's spend cap can pause a project when costs pile up. Tab stops a transaction if terms change. Each of these is a single tripwire. None amounts to an exception model: no product describes how the agent escalates a mid-goal failure, what information you get to make the call, or what the other steps do while the exception is pending.

Cross-service recovery doesn't exist yet

I reviewed public documentation, engineering disclosures, terms, founder interviews, and available user reports for all six products. None of them describes consequence-aware planning across services. High confidence on that for the five that have shipped.

Several can coordinate applications. Gemini agent can create subagents and coordinate parallel or sequential work across Gmail, Sheets, Slides, and enterprise tools, which is the strongest orchestration claim in the set. Dots can pursue a goal through connected applications, spawn tasks, and schedule recurring work. Muse keeps a visible goal plan in a Goals tab.

Orchestration and consequence-aware planning are different problems, though. Take a goal that requires booking a flight, reserving a hotel, blocking a calendar, and sending a confirmation email. A consequence-aware planner decides what to commit to first based on what's hardest to reverse. The flight has a 24-hour free cancellation window. The hotel charges immediately. The email, once sent, is sent. The calendar block is trivially reversible. So the calendar goes first and the email goes last, and before anything starts, the planner already knows what compensating action exists for each step if a later one fails.

Distributed systems engineering solved this conceptually a long time ago. The pattern is called a saga: a way of coordinating transactions across microservices where compensating actions are defined in advance. If step 3 fails, you run the reverse of step 2, then the reverse of step 1, in order.

Personal agents have nothing equivalent. OpenAI's documentation says plainly that some completed actions cannot be undone. Muse's VM backup restores your local computer state, not the emails, bookings, or purchases the agent made through external services. Tab's transaction protections are the most specific in the set, but they cover individual transactions, not the goal those transactions serve. Sesame's terms authorize the agent to "perform actions on your behalf" once you connect a service, and put the responsibility for checking output on you.

So when a multi-service goal partially completes and a later step fails, the user inherits the recovery. You end up as the saga coordinator.

What early users are finding

Two weeks of user evidence is thin. Read what follows as directional: moderate confidence in the pattern, low confidence in any single report.

The Muse permission incident is the sharpest signal. The Guardian reported that a Marketplace seller selected "Allow Always" when Muse asked to handle his Marketplace messages. He expected the agent would still ask before accepting offers or sharing his address. It didn't. Muse negotiated a sale, disclosed his home address, told the buyer he was home, and arranged a pickup, all without further notice. Meta said its investigation found Muse followed instructions and correctly requested permission. The user said "Allow Always" didn't mean what he understood it to mean, and that a later conversational correction ("stop sharing my address") didn't take effect when friends tested it.

That's the permission-configuration cost in its plainest form. The control plane held a standing permission, the user's mental model didn't match it, and the mismatch produced an irreversible real-world consequence: a stranger showed up at his house.

Dots: the babysitting problem. A user running three daily workflows across SharePoint, scheduling software, and a job-tracking system reported repeated authentication failures, manual file transfers, unexplained pauses, and jobs sitting silently until someone noticed. In a separate thread, users described Dots hitting a problem, stopping without notification, and resuming only after the user caught it and intervened. One user dropped a real-estate workflow after spending more time troubleshooting than manual searching would have taken.

Counter-evidence exists. A user who spent a day stress-testing Dots found that when a Dot needed permission to spawn additional reviewers, it kept doing the work itself while it waited. Others reported successful email monitoring, flight bookings, and insurance comparisons. The product works. What's unresolved is how much attention it costs to keep it working.

Muse: silent status divergence. An independent tester who fired 120 simultaneous subagent requests into a single Muse session found that among the 33 workers successfully created, one workload couldn't be independently confirmed. The root record said "running," the interface showed an error, and the combined answer never reached the user. A separate artifact update produced no progress events for 32 minutes and then completed successfully. Visible silence didn't distinguish a slow success from a hang.

The intervention is cheap. Knowing one is needed is the expensive part.

Anthropic has separately documented cases of agents taking unintended actions. That's evidence from outside this six-product set that supervisory-cost failures are a category pattern, not one company's implementation problem.

Supervisory cost by product

Look at the right three columns. That's where the management burden concentrates, and it's where the products have the least to offer.

Where the category goes from here

On novelty: high confidence this is a new category, not a variation on existing assistant patterns. Chat is synchronous and ends with the session. A tool is user-initiated and handles one task. A persistent personal agent is a standing delegation with real-world authority that keeps acting after you leave, and the consumer AI space hasn't shipped that before.

The products are competing on capability expansion: more app connections, more services, longer-running goals. Adoption will be decided by supervisory cost. And the hardest version of the problem, cross-service coordination with consequence-aware recovery, is precisely the one that maximizes management burden, because it asks you to understand the interactions between services, cancellation policies, and timing windows that the agent itself doesn't model.

The platform split in this set makes that harder. Three of the six belong to platform companies, and OpenAI, Meta, and Google each control large service ecosystems. Google stands out. It owns Gmail, Calendar, Drive, Flights, and Maps, so it could build consequence-aware planning inside its own services far more tractably than across third-party boundaries, since it controls the APIs, the cancellation logic, and the state on both sides. That same position gives it a reason to keep coordination inside its walls, because intra-ecosystem coordination that works is a reason to stay in the ecosystem. The three independents (Sesame, Tab, Ghost) need cross-service coordination to justify existing, and they lack the integration depth to build consequence-aware recovery across services they don't control. Moderate confidence on where this lands: the companies best positioned to solve the hardest supervisory-cost problem have the weakest incentive to solve it across boundaries, and the ones with the strongest incentive lack the position to solve it safely.

Tab comes closest to acknowledging recovery, at the transaction level. Its explicit uncertainty rule ("stop if terms change") is the most specific safety commitment in the set. Transaction-level safety still isn't goal-level recovery, and Tab's terms leave returns, disputes, and reversals with the user and the merchant.

I wrote in Issue 14 that intervention before planning is cheap, interruption during execution gets progressively more expensive, and correction after an external effect turns into a compensating-action problem rather than an inference problem. The products that win this category will be the ones that plan execution order around reversibility before they act, so there's less to correct after commitment.

The metric that would show you which product is actually winning is human supervisory minutes per safely completed goal. No product's documentation, company blog, or reviewer's framework reports it. Until someone measures it, discount capability claims.