Giving an assistant useful context is different from giving it authority to act. A personal agent can make that distinction easy to overlook because the interaction feels like a conversation, while the consequences may involve accounts, messages and commitments.
What happened
Meta announced Muse on 8 September 2026 as a personal AI agent that can work on a user’s behalf across applications. The company described a dedicated virtual machine, interaction through the Muse app or WhatsApp, and user control over how much access the agent receives. The announcement is a statement of the product’s design and intended capabilities, not independent proof of its security or reliability. Meta’s explanation is available here.
The relevant management question is broader than one product: how should permission work when an assistant can move from discussing a task to carrying it out?
Why it matters
A request such as organising a business trip contains several possible actions. Looking at dates, comparing travel options, drafting an itinerary and paying for a booking require different levels of authority.
If those permissions are bundled into one broad connection, the user may struggle to understand what they have delegated. A clear interface should make the consequential steps visible before they occur. The organisation should also know which account owns the action and where its record will be kept.
I would start a workplace pilot with a permission map. List the information the assistant may read, the changes it may prepare and the commitments it may execute. Identify the actions that need a person to approve a specific proposal.
That map should reflect the actual tools and accounts involved. A written instruction to be careful is weaker evidence than a demonstration that the agent cannot access unrelated material or execute an unapproved transaction.
The bigger shift
My reading is that personal agents make access management part of everyday delegation. A manager may be accustomed to assigning a colleague an outcome and relying on shared judgement about its limits. Software needs boundaries that remain understandable when it encounters an unexpected situation.
The design also needs an end. A temporary task should not automatically become permanent access. When a project finishes, a person changes role or an account is disconnected, someone must verify what permissions remain.
Revocation deserves a practical test. Stop the assistant during an isolated trial and check whether pending actions can still run. Confirm what information remains available and whether another linked service retains access. These are proposed acceptance checks, not a claim that Muse fails them.
A business should make responsibility equally clear. Employees need an approved route for reporting an unintended action without having to diagnose the technical cause first. The process owner can then reconstruct the sequence and decide whether to pause the workflow.
These questions fit within the CEO’s guide to AI governance: access, authority and accountability should be designed together.
My take
The attraction of a personal agent is understandable. Coordinating routine work can consume attention that people would prefer to spend elsewhere.
I would begin with a task where the assistant can prepare useful work while a person retains control over external commitments. Review the actual record of what it read, changed and attempted, including a deliberately interrupted run.
Expand its mandate only when the organisation can explain those actions clearly and revoke the authority reliably. The most useful agent relationship is one in which the person understands both what has been delegated and how to take it back.
Sources
Read our editorial policy for our approach to sourcing, analysis and corrections.
Let’s put these ideas to work.
Planning a leadership event, developing your team or rethinking your strategy? Let’s discuss how I could support your organisation through a keynote, executive workshop or advisory engagement.
Book a Call with Prof.Christian