Meta Muse geeft een verrassend concreet antwoord op een vraag die de AI-industrie grotendeels heeft vermeden: waar leeft een persoonlijke AI-agent eigenlijk?
Meta's antwoord is niet “in de chatapp”. Elke Muse krijgt een toegewijde computer in de cloud met opslag, geheugen, een browser, een bestandssysteem, achtergrondtaken en eigen beveiligingsgrenzen. Dat is belangrijk omdat een agent die blijft werken nadat je je laptop hebt gesloten meer nodig heeft dan alleen een krachtig model. Hij heeft een persistente plek nodig om te leven.
Wat is Meta Muse en hoe werkt het?
Meta Muse is een persoonlijke AI-agent die is ontworpen om werk uit te voeren in plaats van alleen vragen te beantwoorden. Hij kan verbonden diensten gebruiken, e-mails versturen, met goedkeuring aankopen doen, informatie over de gebruiker onthouden, aan langetermijndoelen werken en taken op de achtergrond voortzetten.
Het belangrijkste is de architectuur. Muse Spark levert het redeneermodel, maar de agent zelf werkt vanuit Muse Secure VM. Die VM bevat de bestanden en gegevens van verbonden diensten van de gebruiker en geeft Muse een browser, tools, rekenkracht en een persistente werkruimte.
Hierdoor worden twee concepten gescheiden die vaak als één geheel worden behandeld: het model dat redeneert en de computer waarop de agent leeft.
Wat is Muse Secure VM?
Meta beschrijft Muse Secure VM als een toegewijde cloudcomputer voor elke gebruiker. Het is een geïsoleerde virtuele Linux-machine met een eigen browser en voldoende CPU, geheugen en opslag om code te compileren, aangepaste Skills te ontwikkelen, gelijktijdige subagents uit te voeren en cron-taken uit te voeren.
De VM is ook het leidende systeem voor wat een gebruiker in Muse stopt. Bestanden, blijvende applicatiestatus, geheugengerelateerde gegevens en inloggegevens voor verbonden diensten worden bewaard in deze persistente omgeving, in plaats van alleen binnen één modelgesprek te bestaan.
Dat is een ingrijpende architecturale verschuiving. Muse lijkt meer op het geven van een eigen werkstation aan een AI-agent dan op het inbouwen van nog een assistent in de telefoon van de gebruiker.
Waarom heeft een AI-agent een eigen computer nodig?
Een chatbot kan verdwijnen nadat hij een antwoord heeft gegeven. Een nuttige persoonlijke agent kan dat niet. Hij kan wachten op een gebeurtenis, een geplande taak uitvoeren, onafgemaakt werk vasthouden, bestanden bewaren of verschillende subagents coördineren terwijl de gebruiker ergens anders is.
Voor die taken is gewone computerinfrastructuur nodig: een bestandssysteem, procesuitvoering, databases, netwerktoegang, logs, inloggegevens en persistente status. Niets daarvan wordt eenvoudig opgelost door het onderliggende model alleen maar een groter contextvenster te geven.
| Chatassistent | Altijd actieve agent |
|---|---|
| Beantwoordt een prompt | Werkt naar een doel toe |
| Tijdelijke sessie | Persistente status |
| Gespreksgeschiedenis | Geheugen, bestanden en databases |
| Weinig directe acties | Tools, vaardigheden en connectors |
| De gebruiker wacht op een antwoord | Achtergrondtaken gaan door |
| Modelgericht | Runtimegericht |
Dat is de bredere les van Muse: een AI-agent die altijd actief is, wordt een serverwerklast. Het frontier-model kan nog steeds elders draaien, maar de agent heeft er duurzame infrastructuur omheen nodig.
Blijft Meta Muse op de achtergrond doorwerken?
Ja. Meta heeft Muse ontworpen om werk voort te zetten nadat de gebruiker het een doel heeft gegeven, zonder dat de app voor elke stap geopend moet blijven. De speciale VM kan ook gelijktijdige subagents en geplande cron-taken uitvoeren.
Dat verandert de betekenis van ‘persoonlijke AI’. Een taak kan beginnen met een gesprek, als achtergrondtaak doorgaan, wachten op nieuwe informatie, later een andere actie activeren en pas weer naar de gebruiker terugkeren wanneer goedkeuring of een beslissing nodig is.
Voor dat patroon is uptime belangrijk. De computer van de agent moet beschikbaar blijven, ook wanneer de computer van de gebruiker dat niet is.
Waar slaat Muse bestanden, geheugen en de status van de agent op?
Meta zegt dat de speciale VM van de gebruiker fungeert als de bronregistratie voor alles wat in Muse wordt geplaatst. Duurzame applicatiestatus wordt opgeslagen in PostgreSQL buiten de belangrijkste runtimecel van de agent, terwijl bestanden en werkruimtegegevens binnen de omgeving van de speciale VM blijven.
Dit verschilt van volledig vertrouwen op de context van het model. Een model kan oude tokens vergeten, een gesprek inkorten of worden vervangen door een nieuwer model. Persistente bestanden en databases blijven behouden ondanks die veranderingen.
Die scheiding zal waarschijnlijk steeds belangrijker worden voor persoonlijke agents: redeneren kan vervangbaar zijn; duurzame status hoeft dat niet te zijn.
Hoe beschermt Muse wachtwoorden en inloggegevens?
Muse is er bewust van weerhouden de echte inloggegevens te zien die het gebruikt. OAuth-tokens en andere geheimen worden opgeslagen door een afzonderlijke authenticatieservice buiten de runtimecel van de agent, en bewerkingen waarvoor inloggegevens nodig zijn, worden uitgevoerd via strenger gecontroleerde processen.
De browser volgt hetzelfde principe. Wanneer een gebruiker een wachtwoord invoert, kan dit rechtstreeks in beveiligde opslag voor inloggegevens terechtkomen en later in de browser worden geïnjecteerd zonder het wachtwoord bloot te stellen aan de hoofdagent van Muse.
Dit is belangrijk omdat een autonome agent geen onbeperkte toegang hoeft te hebben tot elk geheim dat nodig is om zijn werk uit te voeren. De mogelijkheid om een inloggegeven te gebruiken en de mogelijkheid om een inloggegeven te lezen zijn verschillende machtigingen.
Wat is Meta Muse Sentinel?
Meta plaatst een tweede agent, Sentinel, buiten de runtime van Muse. Sentinel is de autoriteit voor machtigingen voor connectoracties en uitgaand netwerkverkeer: Muse kan een actie voorstellen, maar kan niet eenvoudig zelf bepalen dat de actie is toegestaan.
Dat creëert een nuttige scheiding tussen nadenken over wat er moet gebeuren en de bevoegdheid om het daadwerkelijk uit te voeren. Gevoelige acties kunnen worden geweigerd of ter goedkeuring aan de gebruiker worden voorgelegd, terwijl deterministische systeemgrenzen van kracht blijven, zelfs als Muse een verkeerde beslissing neemt.
Dit is vooral belangrijk omdat promptinjectie een onopgelost probleem blijft. Webpagina's, bestanden en uitvoer van hulpprogramma's kunnen schadelijke instructies bevatten. Daarom behandelt Meta externe gegevens als mogelijk onbetrouwbaar, in plaats van ervan uit te gaan dat het model een aanval altijd herkent.
Is de Muse Secure VM slechts een sandbox?
Het is meer gelaagd dan één container. Binnen elke VM draaien de kernharnas van Muse, de werkruimte, hulpprogramma's en binaire bestanden in een systemd-nspawn runtimecel. Root binnen die cel wordt gekoppeld aan een hostgebruiker zonder verhoogde rechten, terwijl gevaarlijke kernelmogelijkheden en systeemaanroepen worden beperkt.
Beveiligingsgevoelige componenten bevinden zich buiten de runtimecel. Opslag van inloggegevens, uitvoering van connectoren, veiligheidsclassificaties, Sentinel, duurzame PostgreSQL-status en netwerkproxy's zijn van elkaar gescheiden, zodat het compromitteren van de hoofdagent niet automatisch controle geeft over elke beveiligingslaag.
Meta vat het ontwerp goed samen: het juiste mentale model is twee geïsoleerde beveiligingsdomeinen op één machine, niet een AI-agent met onbeperkte root-toegang.
Kan Meta toegang krijgen tot gegevens in de Muse Secure VM?
Met de Secure VM die bij de lancering beschikbaar is, ja, onder bepaalde omstandigheden. Meta zegt dat operationeel beleid de toegang van medewerkers beperkt, maar de huidige architectuur voorkomt technisch gezien niet dat Meta toegang krijgt tot VM-gegevens wanneer dat nodig is om de dienst te ondersteunen, te beveiligen of te beheren.
Dat onderscheid is belangrijk. Isolatie van andere gebruikers en isolatie van de cloudprovider bieden verschillende privacygaranties.
Meta zegt ook dat gesprekken en VM-gegevens niet worden gedeeld met zijn advertentiesystemen, terwijl inferentietrajecten kunnen worden opgeschoond en voor modeltraining kunnen worden gebruikt tenzij de gebruiker zich afmeldt. Dit zijn productbeleidsregels en geen cryptografische garanties.
Wat is Muse Confidential VM?
Meta plant later in 2026 een sterkere Muse Confidential VM. Het doel is de VM zo te versleutelen dat zelfs Meta geen toegang heeft tot de gegevens erin, waarbij het ontwerp extern controleerbaar moet zijn.
Dit onthult een belangrijke privacyhiërarchie:
| Architectuur | Wie beheert de infrastructuur? | Kan de provider technisch toegang krijgen tot de gegevens? |
|---|---|---|
| Standaard cloudagent | Cloudprovider | Doorgaans mogelijk |
| Muse Secure VM | Meta | Mogelijk onder bepaalde omstandigheden |
| Muse Confidential VM | Meta | Ontworpen om toegang cryptografisch te voorkomen |
| Zelfgehoste agentserver | Gebruiker | Hangt af van de gebruikte services en modelverbindingen |
‘Cloud’ en ‘privé’ zijn dus geen tegenpolen. De echte vragen zijn: wie beheert de machine, wie beheert de versleutelingssleutels, wat verlaat de machine en welke componenten worden vertrouwd?
Is een thuisserver een alternatief voor Muse Secure VM?
Architectonisch kan een thuisserver veel van dezelfde persistente taken uitvoeren: online blijven, bestanden bewaren, databases draaien, RAG-indexen hosten, agentgeheugen opslaan, containers uitvoeren, automatisering plannen en back-ups bewaren. Dat betekent niet dat een thuisserver Muse automatisch nabootst.
Het beveiligingsmodel van Muse omvat runtime-isolatie, credential-surrogatie, beperkt uitgaand netwerkverkeer, onafhankelijke beleidsafdwinging, classificatiemodellen en goedkeuringspoorten. Een Docker-container simpelweg toegang geven tot een homedirectory en meerdere API-sleutels is niet hetzelfde.
Het voordeel van een thuisserver is anders: eigendom en controle over de persistente laag. Gebruikers kunnen bepalen waar bestanden, databases, Skills, logs en services worden opgeslagen, terwijl ze nog steeds cloudmodellen kunnen aanroepen wanneer inferentie op frontierniveau nuttig is.
Cloud-Vm versus thuisserver: waar moet een agent die altijd online is draaien?
De keuze draait minder om de ruwe AI-prestaties dan om operationele prioriteiten. Een beheerde VM neemt het onderhoud weg en kan beveiliging nauw integreren met het product. Een thuisserver biedt meer controle over persistente gegevens en self-hosted services, maar maakt de gebruiker verantwoordelijk voor isolatie, updates, back-ups en toegangsbeleid.
| Vereiste | Beheerde beveiligde VM | Thuisserver |
|---|---|---|
| 24/7-beschikbaarheid | Sterke match | Sterke match |
| Geen infrastructuuronderhoud | Sterke match | Zwakke match |
| Lokaal bestandsbeheer | Beheerd door de provider | Sterke match |
| Aangepaste self-hosted services | Platformafhankelijk | Sterke match |
| Geïntegreerde beveiligingscontroles | Sterke match | Afhankelijk van de gebruiker |
| Frontier-cloudmodellen | Native | Kan op afstand worden verbonden |
Een hybride architectuur kan uiteindelijk praktischer zijn dan cloud- en lokale infrastructuur als wederzijds uitsluitende opties te behandelen. Privégegevens en persistente services kunnen op infrastructuur blijven die de gebruiker beheert, terwijl geselecteerde context naar een frontiermodel gaat wanneer de kwaliteit van de redenering de afweging waard is.
Heeft een altijd actieve AI-agent een krachtige GPU nodig?
Niet noodzakelijk. Muse laat zelf zien waarom ‘agentserver’ en ‘inferentieserver’ niet als synoniemen moeten worden beschouwd.
| Agentbelasting | Vereiste lokale GPU |
|---|---|
| Bestandsopslag | Geen |
| PostgreSQL en geheugen | Geen |
| Cron-taken | Geen |
| API- en MCP-services | Geen |
| Skills en scripts | Meestal geen |
| RAG-opslag en -opvraging | Meestal geen of laag |
| Embeddings | Optionele versnelling |
| Lokale inferentie op frontier-schaal | Mogelijk zeer hoog |
Een agentcomputer heeft persistentie nodig voordat hij massale inferentiehardware nodig heeft. Opslag, databases, netwerken, automatisering en beschikbaarheid zijn nuttig, zelfs wanneer het belangrijkste redeneermodel in de cloud draait.
Wat onthult Meta Muse over de toekomst van persoonlijke AI?
Het interessantste dat Meta voor Muse heeft gebouwd, is misschien niet Muse Spark. Misschien is het wel de beslissing om de agent een eigen computer te geven.
Die architectuur erkent iets belangrijks: zodra AI verschuift van het beantwoorden van vragen naar het onderhouden van doelen, bedienen van tools, opslaan van geheugen en onbemand werken, wordt het model slechts één onderdeel. De agent heeft ook een duurzame plek nodig voor zijn toestand en services.
De toekomstige persoonlijke AI-stack kan daarom worden opgesplitst in twee vervangbare lagen: een redeneermotor en een agentcomputer. De redeneermotor kan van Meta, OpenAI of Anthropic zijn, of een lokaal model. De persistente computer kan een beheerde cloud-VM, een privé beheerde thuisserver of een hybride combinatie daarvan zijn.
Muse's antwoord is een speciale computer in Meta's cloud. De bredere les is duurzamer: altijd actieve AI heeft een plek nodig om te wonen.
Veelgestelde vragen
Draait Meta Muse lokaal?
Nee. Muse draait in een speciale virtuele machine in de cloud van Meta. De Muse-app of webinterface maakt verbinding met die externe agentomgeving.
Draait Meta Muse altijd?
Muse is ontworpen voor werk op de achtergrond en langdurige taken, en de VM kan geplande cronjobs en gelijktijdige subagents uitvoeren. Afzonderlijke taken zijn nog steeds afhankelijk van machtigingen, de beschikbaarheid van services en het uitvoeringsbeleid van Muse.
Is Muse Secure VM een afzonderlijke fysieke computer?
Nee. Het is een speciale virtuele machine, wat betekent dat de gebruiker een geïsoleerde virtuele computeromgeving krijgt in plaats van een speciale fysieke server.
Waar slaat Meta Muse zijn geheugen op?
Meta zegt dat de speciale VM het bronsysteem voor Muse-gegevens is. Duurzame applicatiestatus wordt opgeslagen in PostgreSQL, terwijl andere bestanden en werkruimtegegevens in de VM-omgeving van de gebruiker blijven.
Kan Meta gegevens in Muse Secure VM zien?
De lanceringsversie verhindert technisch niet dat Meta toegang krijgt tot VM-gegevens wanneer dat nodig is om de service te exploiteren, ondersteunen of beveiligen. Meta zegt dat operationeel beleid de toegang beperkt. De geplande Confidential VM moet Meta zelf er cryptografisch van weerhouden de gegevens te lezen.
Kan Muse mijn wachtwoorden zien?
Meta heeft Muse zo ontworpen dat de hoofdagent geen echte wachtwoorden of inloggegevens van gekoppelde services ontvangt. Geheimen worden apart opgeslagen en aan geautoriseerde bewerkingen verstrekt zonder ze rechtstreeks aan de agent bloot te stellen.
Wat doet Muse Sentinel?
Sentinel is een afzonderlijke machtigingsagent die connectoracties en netwerktoegang beoordeelt. Muse kan een actie voorstellen, maar Sentinel bepaalt of deze wordt toegestaan, geweigerd of ter goedkeuring aan de gebruiker voorgelegd.
Kan een persoonlijke AI-agent op een homeserver draaien?
Ja. Een homeserver kan permanente agentonderdelen hosten, zoals bestanden, databases, geheugen, RAG-systemen, Skills, tools, automatisering en back-ups. Het nabootsen van de isolatie en bescherming van inloggegevens van een beheerd systeem zoals Muse vereist aanvullende beveiligingstechniek.
Heeft een AI-agentserver een GPU nodig?
Niet voor veel agenttaken. Bestanden, databases, geheugen, automatisering, API-services, RAG-opslag, logboeken en back-ups kunnen allemaal zonder krachtige GPU worden uitgevoerd. De GPU-vereisten hangen vooral af van de vraag of de server ook lokaal AI-inferentie uitvoert.
Is een homeserver privéer dan Muse Secure VM?
Het kan de gebruiker meer controle geven over de infrastructuur en gegevens, maar lokaal hosten is niet automatisch veilig of privé. Rechten, externe toegang, API's van derden, inferentie in de cloud, inloggegevens, back-ups en de netwerkconfiguratie bepalen nog steeds welke gegevens de server kunnen verlaten.
Tech & AI HUB
Meer om te lezen

Welke invloed heeft downsampling van tijdreeksen op anomaliedetectie in een slimme woning?
Ontdek hoe bucketbreedte, aggregatie, anti-aliasing, ontbrekende gegevens, gebeurtenisduur en retentie op meerdere schalen de detectie van afwijkingen in slimme woningen beïnvloeden.

Hoe combineert een bezettingsraster zwakke signalen van een slim huis?
Leer hoe ruimtelijke cellen, sensormodellen, log-odds-updates, verval, gecorreleerd bewijs en drempelwaarden zwakke signalen uit huis omzetten in bezettingsschattingen.

Hoe beïnvloedt fotometrische normalisatie het clusteren van privégezichten?
Bekijk hoe verlichtingscorrectie gezichtscrops, embeddings, clust afstanden, drempelwaarden, overnormalisatie en de evaluatie van privéfotozoekopdrachten verandert.

