Meta Muse: kolejny słodziak AI, ale z własnymi gadżetami

Do OpenAI dots i Grok Bot dołącza Muse od Meta. Kolejny osobisty agent ma pamiętać, pomagać i pracować wtedy, gdy zajmujemy się czymś innym. Czym agent różni się od asystenta i chatbota, wyjaśnia poradnik o agentach AI dla firm. Big tech najwyraźniej uznał, że każdy człowiek potrzebuje własnego cyfrowego słodziaka. Jeszcze trochę i zamiast porównywać modele, będziemy dyskutować, który z naszych agentów najładniej siedzi na biurku.

W przypadku Muse to ostatnie zdanie staje się zaskakująco dosłowne. Muse Gadgets pozwala połączyć agenta z urządzeniami i budować własne interfejsy: ekrany, przyciski, czujniki oraz rozszerzenia na ESP32 lub Raspberry Pi. I właśnie to uważam za naprawdę fajny pomysł. Agent nie musi na zawsze pozostać kolejną zakładką w przeglądarce. Źródło: Muse Gadgets.

Czym jest Muse i skąd bierze się jego „osobisty” charakter?

Meta zaprezentowała Muse 8 września 2026 roku jako agenta wykonującego zadania w aplikacjach i przeglądarce. Otrzymuje własne środowisko komputerowe w chmurze, może kontynuować zleconą pracę po zamknięciu aplikacji i wracać do użytkownika z wynikiem lub prośbą o zgodę. Według komunikatu Muse jest udostępniany w USA w aplikacjach na iOS i Androida oraz na muse.ai, a w większości zastosowań działa bez opłat, z płatnymi planami subskrypcji dla bardziej wymagających. Użytkownik może kazać Muse „zapomnieć” konkretne informacje, a dla poczty wybiera, czy agent tylko ją czyta, czy także wysyła wiadomości. To opis funkcji vendora, nie wynik mojego testu. Źródło: komunikat premierowy Meta.

Twórcy opisują ciągłą rozmowę, pamięć, osobne rozmowy poboczne, cele i podgląd aktywności. Użytkownik może nadać agentowi imię i własny wygląd. Awatar nie jest tu przypadkową dekoracją: ma ułatwić kontakt z czymś, co towarzyszy nam dłużej niż przez jedno pytanie. Źródło: opis projektu Muse.

To podobna obietnica jak w pozostałych artykułach cyklu: mniej ponownego tłumaczenia kontekstu, więcej delegowania wyniku. Różnica, która najbardziej mnie interesuje, zaczyna się przy sprzęcie. Skoro agent zna zadanie, dlaczego jedynym sposobem kontaktu z nim ma być otwieranie aplikacji, wybieranie rozmowy i pisanie kolejnej wiadomości?

Stan na 6.10.2026: wrześniowy komunikat Meta o Muse dla małych firm wskazuje dostępność w USA i Kanadzie. Nie traktuję tego jako potwierdzenia dostępności produktu i wszystkich integracji w Polsce. Możliwość przeczytania kodu SDK również nie oznacza automatycznie dostępu do usługi na własnym koncie. Źródło: Muse for Small Business.

Muse Gadgets: agent dostaje ekran, przycisk i kontakt z otoczeniem

Najciekawsza jest możliwość dopasowania urządzenia do konkretnej sytuacji. Na biurku przydatny bywa mały ekran pokazujący stan zadania. W kuchni — widoczna lista zakupów. Przy warsztacie — fizyczny przycisk, który pozwala przekazać krótką uwagę bez szukania telefonu. To przykłady zastosowań, nie obietnica, że każdy z nich działa bez konfiguracji.

Repozytorium Muse Gadgets zawiera SDK i firmware dla ESP32 oraz SDK dla Linuksa. Urządzenie wymaga tokenu SDK i sparowania z aplikacją Muse; instrukcja wskazuje tryb deweloperski w ustawieniach urządzeń. Kod można modyfikować, aby dodać obsługę własnego sprzętu i poleceń. Źródło: repozytorium projektu.

Warto rozdzielić trzy części takiego rozwiązania: usługę agenta, oprogramowanie połączenia oraz samo urządzenie. Mała płytka obsługuje lokalny interfejs i funkcje sprzętowe. Nie oznacza to, że cały Muse i jego model działają na ESP32 albo że gadżet zachowa wszystkie możliwości bez internetu. Własna obudowa nie przenosi automatycznie agenta z chmury na nasze biurko.

ESP32: własny ekranik i urządzenie do jednego zadania

ESP32 jest interesującą drogą do niewielkiego gadżetu z wyświetlaczem, przyciskiem lub czujnikiem. W dokumentacji projektu znajdziemy konfiguracje różnych płytek, między innymi Waveshare z okrągłym AMOLED, M5Stack StickS3, urządzenia Seeed reTerminal z e-papierem oraz Home Assistant Voice Preview Edition. Obsługiwane funkcje zależą od konkretnej płytki i jej pamięci. Źródło: dokumentacja ESP32 Device SDK.

Przykładowo ekran e-papierowy pasuje do informacji, która zmienia się rzadko: planu dnia czy listy spraw. Niewielki wyświetlacz przy komputerze może sygnalizować, że agent czeka na decyzję. Przycisk ogranicza liczbę kroków potrzebnych do rozpoczęcia krótkiej interakcji. To wybór sposobu korzystania, a nie konkurs na liczbę funkcji upchniętych w najtańszej obudowie.

Jest też szczegół, który łatwo zgubić w efektownym pokazie: mikrofon i głośnik nie gwarantują gotowej, pełnej rozmowy głosowej. README ESP32 opisuje wysyłanie notatki głosowej i odpowiedzi tekstowe; odczytywanie odpowiedzi na głos można rozbudować przez usługę syntezy mowy. Dokumentacja zaznacza również, że część płytek bez PSRAM nie obsługuje tunelu do sieci domowej. Trzeba sprawdzić funkcje wybranego wariantu, zamiast przenosić je z demonstracji innego urządzenia. Źródło: możliwości i ograniczenia firmware.

Raspberry Pi: więcej swobody i konkretne uprawnienia

Linux Device SDK daje inną klasę możliwości. Po instalacji i sparowaniu Muse może wykonywać polecenia na komputerze, odczytywać oraz zapisywać pliki i sprawdzać stan urządzenia. Raspberry Pi staje się więc miejscem wykonania lokalnych narzędzi, a nie tylko ekranem. Dokumentacja wymienia też możliwość dodawania komend i przekazywania wiadomości do Muse z lokalnych programów. Źródło: Linux Device SDK.

To otwiera drogę do własnych integracji: od powiadomienia o stanie kopii zapasowej po połączenie z Home Assistant. Wymaga jednak przygotowania odpowiedniej usługi lub polecenia. „Można zbudować” jest tu uczciwszym opisem niż „wszystko już działa”. Właśnie możliwość budowania uważam za zaletę: użytkownik nie musi czekać, aż vendor przewidzi jego bardzo konkretny pomysł.

Granica dostępu jest istotna i dobrze opisana w README: Muse działa z uprawnieniami konta wybranego podczas instalacji. Jeśli to konto może używać sudo, agent również otrzymuje tę możliwość. Do eksperymentu wybrałbym osobne urządzenie i konto z zakresem odpowiadającym zadaniu. Nie potrzeba administracji całym domowym serwerem, żeby pokazać na ekranie trzy sprawy na dziś. Źródło: uprawnienia Linux SDK.

Home Link i urządzenia, które już mamy

Muse Home Link ma łączyć Muse z domowym Wi-Fi i zgodnymi urządzeniami, w tym własnymi projektami udostępniającymi lokalne HTTP API. Strona wymienia przykłady obsługi światła, telewizora czy drukarki przez umiejętności społeczności — zależnie od konfiguracji. To nie jest zapewnienie zgodności z każdym urządzeniem podłączonym do routera. Źródło: Muse Gadgets.

Ta sama strona opisuje Home Link jako ofertę dla aktywnych subskrybentów Muse w USA, po jednym urządzeniu, z wysyłką zapowiedzianą na październik. Osobny gadżet HDMI do telewizora jest oznaczony jako zapowiedź. Rozdzielam te statusy od projektów, których kod już udostępniono. Nie ma tu podstaw do obiecywania polskiej dostawy ani gotowego produktu telewizyjnego. Źródło: warunki i katalog gadżetów.

Własny projekt: zacząłbym od spokojnego ekranu, nie centrum dowodzenia domem

Mój modelowy pomysł to niewielki ekran na biurku pokazujący trzy aktualne sprawy oraz przycisk do dodania krótkiej notatki. To propozycja projektu, nie opis urządzenia, które zbudowałem. Ważniejsze od animowanej buźki byłoby to, czy ekran oszczędza otwierania aplikacji i nie zamienia się w kolejny strumień powiadomień.

Część projektu	Decyzja przed budowaniem
Ekran	Krótka lista, czas ostatniej aktualizacji i czytelny stan połączenia
Przycisk	Jedna jasno określona funkcja, np. rozpoczęcie notatki
Dane	Tylko informacje przeznaczone do pokazania osobom w pobliżu
Brak sieci	Widoczna informacja, że dane mogą być nieaktualne
Odbiór	Czy po tygodniu urządzenie nadal pomaga, zamiast tylko ładnie wyglądać?

Najpierw sprawdziłbym sam przepływ informacji, później dodał obudowę i dopracował wygląd. Pozwala to uniknąć klasycznej pułapki majsterkowicza: mamy pięknie wydrukowaną obudowę, trzy wersje płytki i zero odpowiedzi na pytanie, po co codziennie tego używać.

Własne projektowanie może oznaczać zmianę układu ekranu, dodanie przycisku, napisanie polecenia albo stworzenie obudowy. Nie wymaga od razu projektowania elektroniki od zera. Największą wartością jest możliwość dopasowania formy do sytuacji, zamiast dopasowywania całej sytuacji do telefonu.

Otwarty kod nie oznacza nieograniczonej platformy komercyjnej

SDK udostępniono na Apache 2.0, z wyjątkami dla wskazanych elementów, między innymi awatara. Dostęp do Muse przez token podlega jednak osobnym warunkom. Aktualny regulamin przeznacza tokeny do użytku osobistego i niekomercyjnego, ogranicza liczbę powiązanych urządzeń oraz dystrybucję. Nie daje ogólnego pozwolenia na sprzedaż własnej linii urządzeń z Muse. Projekt i tokeny są ponadto udostępniane bez zobowiązania do utrzymania wspieranej platformy deweloperskiej. Źródła: licencja repozytorium, warunki tokenów SDK.

To ważne rozróżnienie dla osoby, która po weekendowym prototypie zobaczy pomysł na produkt. Możliwość modyfikacji kodu i warunki korzystania z usługi to dwa osobne zagadnienia. Do własnych eksperymentów kierunek jest ciekawy; komercjalizacja wymaga sprawdzenia aktualnych warunków i potrzebnych zgód.

Dlaczego uważam, że inni też pójdą w tę stronę?

Moim zdaniem połączenie osobistego agenta z własnymi gadżetami to bardzo dobry kierunek i spodziewam się, że inni vendorzy pójdą podobną drogą. To moja prognoza, nie informacja o ogłoszonych planach OpenAI czy xAI. Nie twierdzę, że Dots lub Grok Bot mają już odpowiednik Muse Gadgets.

Widzę trzy powody. Po pierwsze, fizyczny interfejs skraca drogę między potrzebą a działaniem. Naciśnięcie przycisku czy spojrzenie na ekran wymaga mniej uwagi niż wejście do aplikacji. Po drugie, urządzenie można umieścić tam, gdzie pojawia się potrzeba: przy drzwiach, w kuchni, na biurku. Po trzecie, otwarcie części narzędzi dla twórców pozwala sprawdzić więcej pomysłów, niż zmieści się w planie jednego zespołu produktowego.

Nie każda funkcja potrzebuje modelu. Zegar nadal może odmierzać czas bez konsultacji z cyfrowym kolegą. Agent staje się ciekawy tam, gdzie przydaje się kontekst, zmienne polecenie albo połączenie kilku źródeł. Dobrze zaprojektowany gadżet powinien tę zdolność udostępniać wygodniej, a nie dopisywać „AI” do czynności, którą od lat wykonuje zwykły przycisk.

To również inna wizja sprzętu niż jedno urządzenie mające zastąpić telefon. Bardziej przekonuje mnie wiele małych, użytecznych punktów kontaktu z agentem. Nie muszą wszystkie mówić, świecić i prosić o uwagę. Czasem najlepszy cyfrowy słodziak to taki, który spokojnie pokazuje potrzebną informację i przez resztę dnia daje człowiekowi spokój.

Dots, Grok Bot i Muse: ten sam trend, inne akcenty

Firmowy odpowiednik tego kierunku widać w Microsoft Project Solara: agent ma być dostępny przez urządzenia dopasowane do sytuacji pracy. Muse i Solara nie są tą samą platformą ani zapowiedzianą integracją. Łączy je jednak ciekawy kierunek: przeniesienie kontaktu z agentem poza jedno okno czatu.

Dots opisałem przez pamięć i ciągłość zadań (tam też porównuję mechanizmy pamięci i zgód trzech agentów), a Grok Bot przez delegowanie pracy i współpracę botów. Muse dodaje do tego cyklu szczególnie interesujący temat fizycznego interfejsu, który użytkownik może współtworzyć.

Nadal warto rozumieć zasady działania. Meta opisuje oddzielny mechanizm Sentinel zatwierdzający dostęp i działania poza środowiskiem Muse. Nie należy mylić go z NVIDIA Sentry ani wyciągać wniosku, że dowolny własny gadżet automatycznie dziedziczy wszystkie zabezpieczenia wbudowanych integracji. Źródło: architektura bezpieczeństwa Muse. Szerszy problem granic autonomii opisuje osobny przewodnik bezpieczeństwa agentów.

Na poziomie pomysłu jestem jednak zdecydowanie na tak. Kolejny sympatyczny awatar sam w sobie nie zmienia wiele. Możliwość zbudowania dla agenta własnego, przydatnego miejsca w codziennym otoczeniu już może. Więcej takich zastosowań znajdziesz w filarach „AI w codziennej pracy” i „Meta AI”.