Personal Agents: What They Are, Where They Stand, How to Choose

The user sends a line, the software sends a line back.

The user picks a daily time; the system pushes a briefing on schedule.

A new email arrives or a price changes; the system wakes up and checks.

After a round, the software decides to look again in half an hour.

The goal has an explicit definition of done, and actions happen only after independent approval.

Alarm: what wakes it

The system first needs a way to be woken. A scheduled time, a new email, or a change on a web page can all serve as the alarm.

Duty room: where the work continues

Once awake, it needs somewhere to keep working. That background room must stay open; closing the interface on a phone or computer must not affect it.

Gatekeeper: who lets it through

Finally, someone has to decide whether this round sends a single message or actually sends the email on the user's behalf. The two carry very different costs.

Path one: send a message

This path spends the user's attention. A wrong message reads as a puzzling interruption; a few of those and the user turns notifications off, after which genuinely important messages never get through.

So it is allowed in only three cases: something really changed, a decision must be made by a person, or there is a result a person can use.

Path two: actually do something

This path spends permissions, accounts, and money. An email cannot be recalled once sent, and a calendar change can send someone on a wasted trip, so the default posture should be to do nothing.

The system may act only when standalone rules explicitly allow it and the permission matches this one action.

Confirm the trigger came from a scheduled time or a real event. Polling on a timer is allowed only when no push source exists, and the polling rate must be capped.

The system compares what it saw this time with last time in a definite way; if nothing changed it stops right there, without even waking the model.

Only three cases get through: a person needs to act, the result is usable, or approval is needed. "I have a suggestion" should be off by default.

The system remembers what it already reported, and caps repeats on the same item, nighttime interruptions, and triggers per project.

Sending messages, writing files, and reaching external services are all forbidden to begin with, then opened item by item for a specific task.

The model holds only a reference token; the real credential is filled in at the boundary on its behalf, and only the token shows up in logs.

The user's consent is scoped precisely to "send this email to this person" and expires after a single use.

The confirmation box does not appear inside the chat window, and the "agree" the user clicks does not pass through the model.

The system records what it did and what it intends to do in a tamper-evident log the user can inspect at any time.

The figures come from the CaMeL paper's results on a public benchmark. Its approach writes the user's instructions into a fixed procedure first, so external content can only fill in data and cannot change the procedure.

What these numbers mean

Moving the decision out of the model means the software finishes fewer tasks; that is the price paid for safety. Our recommendation is to grade by consequence: reading a public web page can be lenient, sending an email must be strict, and there is no need to apply one rule to everything.

The paper's code is labelled by its authors as a research artifact, and they state they do not intend to maintain it long term, so its value lies mainly in the idea; a product needs an implementation with a maintenance commitment.

Meta describes it as software that gets things done: the user states a goal, it breaks the work into steps and acts across apps, keeps working after the user closes the app, and comes back for permission before sensitive actions.

A security researcher demonstrated publicly that an ordinary program on the computer could quietly change a client setting and redirect voice data and login credentials elsewhere. The problem lay in the high-privilege desktop app; the cloud isolation was not breached, and Meta shipped a fix.

Meta released a new model emphasising that it does not give up on long tasks and carries memory across sessions, and released an open-weight model for local use, with the vendor recommending a device with 24–32 GB of VRAM.

Public sources do not state availability or compliance status in mainland China, and this report makes no inference about it.

Three things Meta admits

• The company says plainly in its security write-up that prompt injection remains an unsolved industry problem and that Muse cannot stop every attack.
• The company offers bounties of up to US$300,000 for valid vulnerability reports, with up to US$130,000 for "successfully deceiving the system to affect a single user."
• Limiting employee access to user data currently relies on internal policy; confidential virtual machines that even the vendor cannot see into are still on the roadmap.

Two publicly reported incidents

A user who had not opened the app for two days received a proactive message from the assistant claiming that "the mailbox is not connected and the email could not be found." Meta confirmed to the press that this was a product defect producing a fabricated message, unrelated to privacy; the user abandoned the product even after the fix.One wrong proactive message can take trust to zero.

Another third-party report said the system was found regularly building profiles of "everyone in the user's life" in the background, including people who never used the product and had no chance to refuse. Background work the user cannot see feels closer to surveillance.

Option one: get it running first

Assemble known, reasonably mature components to produce a result, which suits a first check of whether this kind of system is useful at all. The cost is several processes running side by side on different upgrade schedules.

Option two: get the authorization layer right first

Use a plugin-based runtime as the execution and authorization base: a cleaner architecture and an authorization boundary that is easier to audit, but slower to learn and you have to accept preview-level instability. The two routes can follow one another: get it running, then migrate the execution layer over.

Daily office work and scheduled briefings

If the goal is simply a briefing each day, generated documents, and messages pushed into a group chat, a commercial workbench is enough, and the cost of standing up a resident system of your own is hard to recover.

Watching for outside changes

If you want a reaction the moment a new email arrives, and want the software to schedule its own re-checks, add a resident trigger layer and leave the delivery work with the platform you already have.

Touching real accounts and money

If the software is to send real email and change real calendars, the architecture needs an independent authorization layer first. This report advises against entering this stage until all five acceptance criteria at the end of this chapter pass.

Get time triggers and event triggers working first; no outbound actions at this step.

Configure change comparison, de-duplication, and a notification budget, and confirm that a failed check raises an explicit error.

Let the software propose when to re-check, with the scheduler bounding it from above and below. This step is what moves you from level two to level three.

Give the long-term goal an explicit definition of done, then hand over permissions in the order: read-only, draft, out-of-band approval, action.

Many products currently rely on a sentence in the prompt telling the software not to message when nothing changed. A more reliable approach writes it as a system rule: how often the same item may be raised, no nighttime interruptions, and an explicit "no notification needed" record when nothing is new.

With nobody at the computer, a task waits indefinitely for confirmation; to keep it running, designers often turn approval off entirely. Give each request a bounded window and treat a timeout as a no, and both ends are covered.

Anything advanced over several days should state in advance what counts as done, and be able to show evidence on completion. An open-source project already makes this a core mechanism; it deserves to be standard configuration for this category.

Users should be able to list everything the software has done and intends to do, and stop it with one click. The kind of unnoticed background profiling described in third-party reports should have left a record in the interface all along.

The script that observes external changes runs for long periods with the main program's full permissions by default. It should get the same isolation as the main program, plus a one-click kill switch.

A complete form currently has to be assembled from four layers with no official integration protocol between them. A shared contract for triggering, goals, authorization, and execution would sharply lower the cost of assembling a working system.

Vendor wording and published specs

For example Meta's description of product behaviour on its launch page, trigger rules stated in official documentation, and officially published VRAM requirements. This material can be checked directly.

Index sites, community docs, and media

Such material offers leads, but this report did not obtain the corresponding first-party pages. Wherever it is cited, the text says so explicitly, and readers should not treat it as a vendor commitment.

This report's own judgement

The grading framework, the mechanism summaries, and the option comparisons all fall here. They were put together by this report to help readers interpret the material; none of this grading appears in vendor documentation.

First-party vendor material

Meta Newsroom's Muse launch page and subsequent model announcements, the Muse Security architecture article, and Meta developer documentation; WorkBuddy official product documentation and Tencent Cloud product documentation; OpenAI's Pulse launch announcement.

Official open-source project material

Official repository documentation and docs for OpenClaw, Hermes Agent, OpenMuse, DeepSeek Harness, nearai/ironclaw, QwenPaw, and others; the DeepSeek Harness SAFETY.md and architecture documents.

Academic papers and research artifacts

The CaMeL team's prompt-injection defence paper presented at SaTML 2026 and its public code repository; the Muse Glimmer 30B model card.

News and third-party checks

The Register's reporting on the client vulnerability, Futurism's reporting on the hallucinated notification, and descriptions of product details from several index sites and Chinese-language media. All of this is treated as second-hand in the text.

What is not possible yet

• "Confidential computing where even the service vendor cannot see user data" is still on Meta's roadmap.
• One-time payment credentials bound to a payment method, with a capped amount and expiry, are proprietary commercial capabilities with no equivalent in the open-source combination.
• Internal trials at big-company scale, attack exercises, and public bounty validation are hard for an individual or small team to reproduce.

What this report could not find

• Vendors have not published false-positive rates for proactive messages, real task success rates, or retention data, nor any specific threshold for how often a message may be sent.
• The real-world speed of small models at 8 GB VRAM and long context was not measured for this report.
• End-to-end latency and cost once the components are assembled, whether certain plugins are official, and feature differences between regional versions are not answered by public sources.