Testing Meta's New AI Agent Muse: I Let It Negotiate With My Money

Meta has launched a personal AI agent called Muse — and it doesn't just answer questions. It actually gets things done: opening browsers, filling out forms, sending emails, and even haggling on your behalf. A YouTube creator put Muse through three real-world tasks: buying something, negotiating a lower internet bill, and the most intriguing one — having it negotiate with his own separate AI agent. Here's a full breakdown of the test and what it revealed.

What Is Muse: A Personal Agent Running in the Cloud

Muse is Meta's personal AI agent, announced on September 8th and gradually rolling out in the US across iPhone, Android, Web, and WhatsApp. What sets it apart from ordinary chat assistants is how it runs: each user gets a dedicated virtual computer in Meta's cloud, fully isolated — other people's agents can't access yours.

Muse runs on Meta's own model, Muse Spark, and can operate a browser, fill out forms, and negotiate on your behalf. The key design principle: it asks for your confirmation before sending an email or spending money. It also remembers things you've told it before. There's also a Mac app that can control other applications with your permission, and glasses support is reportedly coming in the next few months.

Before starting, the tester shared only three pieces of information with Muse — said just once: his budget cap for a used Quest 3 was $250; any used item must come with the original charger; and he only takes calls on Thursday afternoons. None of these would appear in any subsequent instructions — if Muse needed them later, it would have to remember them on its own.

Muse Spark is Meta's base model fine-tuned specifically for agentic tasks. It's derived from the Meta Llama family and has been specially trained for multi-step planning, tool use, and long-context memory. Unlike general-purpose conversational models, agentic models must maintain "task state" within a single interaction — remembering which step they're on and which sub-goals are still pending — which places higher demands on context window efficiency and instruction-following ability. The dedicated cloud virtual computer design solves the "persistence" problem for agents: on a typical mobile app, a task dies when the system kills the app in the background. Moving the execution environment to the cloud turns the phone into just an interface terminal, decoupling task lifecycle from device state — which is the underlying reason Muse can keep running after the app is closed.

Task 1: Buy a Used Quest 3 and Negotiate the Price

The first task: find a used Quest 3 on Facebook Marketplace for under $250, with a charger included — contact the seller, negotiate the price down, and come back for confirmation before any purchase. After giving the instruction, the tester closed the app entirely — not minimized, closed. On a normal assistant, that would mean the task is dead. But Muse's task kept running on that invisible cloud computer.

Since Muse currently can't navigate into Marketplace on its own, the tester had to manually paste the product link, and the final send still required a human click — that falls under "still needs my involvement." But what was truly impressive was the memory test: the three pieces of information shared just once, before the app was killed, still held — all three, intact.

The negotiation results were compelling: the listing price was $320, Muse opened at $210, the seller countered at $270 — and Muse proactively asked about the charger, which wasn't mentioned anywhere in the current task instructions. Memory was doing real work here. Muse then proposed a counteroffer of $240, but didn't finalize it on its own — it paused and displayed a confirmation prompt waiting for approval. Meta had claimed it would "ask for your consent before spending money," and this was direct verification.

Task 2: Negotiating a Lower Internet Bill and Reading Work Connectors

The second task: draft an email to the internet provider seeking a renewal discount. The setup: four-year customer, monthly bill jumped from $52 to $71, competitor is offering $39, and the threat to switch by end of month if no retention deal. Muse drafted the email in four minutes. The tester made light edits — shorter, with a specific cancellation date added — and again, Muse stopped before sending and waited for confirmation.

The tester also tested Muse's listed work connectors — GitHub, Notion, Granola, and Box. He asked Muse to pull the last three commits from his AI tutoring project repository and create a new Notion page with plain-language summaries — one paragraph per commit, no code.

The result was three clear, readable paragraphs. Muse even inferred the intent behind the second commit — something the tester admitted he might not have been able to articulate himself. It read the commit messages and made a reasonable interpretation.

Task 3: Two AI Agents Negotiating With Each Other

The most interesting part of the test: having Muse talk to the tester's own separate AI agent. That agent acts as a gatekeeper for his calendar — anyone who wants to book time has to go through it first. Since Muse now has its own email address, the tester instructed it to email his scheduling agent to book a 20-minute call sometime next week — and specifically: don't accept anything less than 20 minutes without checking first.

The back-and-forth between the two agents was fascinating. Muse proactively suggested Thursday afternoon — which was exactly the time the tester had mentioned for calls, a detail not included anywhere in the current task instructions. The calendar agent countered with 15 minutes. Muse declined — and didn't compromise on its own or come back to ask for guidance. It simply held the 20-minute line. In the end, the two agents exchanged four emails, the tester clicked "approve" twice, and the call was on the calendar.

Two AI agents collaborating via email represents an early practical form of a Multi-Agent System. In academic and industry contexts, multi-agent frameworks typically rely on specialized protocols (like OpenAI's Swarm or Anthropic's MCP) to let agents share structured messages. This test bypassed all of that and used ordinary email as the communication channel — demonstrating that protocol-level interoperability isn't a hard prerequisite as long as both sides can read and write email. More noteworthy is the "delegation chain" problem: each agent operates within an authorization boundary set by its own user, and the negotiation is essentially two sets of authorization rules colliding — the 20-minute floor reflects one user's preference, the counter-offer reflects the other's calendar density. These four emails represent a small-scale stress test of the open question: how can agents reach an agreement without overstepping their authority?

Scores and Key Observations

The tester scored across three dimensions: 2 tasks completed fully autonomously, 2 tasks still requiring human involvement, and 0 tasks it couldn't handle at all. Throughout the entire process, Muse asked for confirmation exactly four times.

A clear pattern emerged: every single action involving money or something done in his name was brought back to him for approval first. This isn't a sign of limited capability — it's precisely the fundamental rule you'd set for a human assistant. Meta has baked it directly into the product.

The tester's most anticipated next step is Muse coming to the glasses, merging "can negotiate" with "can see" — Meta says that's still months away. As for this test: the Quest got bought, the charger was in the box, and the calendar has a new entry. It successfully negotiated with another AI agent. Whether that's the future or an extremely clever form of talking to yourself is worth sitting with.

The "stop and confirm" mechanism used in this test is known in AI safety circles as the Human-in-the-Loop (HITL) design principle. The core logic: for irreversible or high-risk operations — sending money, publishing content as the user, making commitments — the system should force a human approval checkpoint before execution, rather than letting the model decide on its own. This principle sits in the same safety architecture category as "takeover requests" in autonomous driving and "final physician confirmation" in medical AI. For consumer-grade AI agents, the HITL challenge lies in calibrating the granularity: too many confirmation requests causes "alert fatigue," where users start clicking "allow" mindlessly and render the safety mechanism useless. Too few, and real harm can occur without the user realizing. In this test — four confirmations total, two specifically for money or identity-affecting actions — the trigger threshold appears to be within an acceptable range, though real-world performance at scale remains to be seen.