Zbudowanie własnego agenta to orkiestracja, sandbox, zarządzanie stanem, infrastruktura.
Managed Agents zwija to do jednego wywołania API. To najbardziej niedoceniona część Antigravity 2.0.
Z pięciu powierzchni platformy Antigravity ta przeszła przez prasę najciszej — przykryta nagłówkami o Gemini Spark i Omni. A dla kogoś, kto buduje agenty w produkt, jest być może najważniejsza. Bo zmienia pytanie „jak zbudować i utrzymać infrastrukturę agentową” w „jak zawołać agenta tak, jak wołam chat completion”.
Czym jest Managed Agents API
Managed Agents to tier wewnątrz Gemini API, w którym pojedynczy call uruchamia w pełni postawionego agenta w izolowanym sandboksie Linux. Agent sam ogarnia wieloetapowe rozumowanie, wywoływanie narzędzi, wykonywanie kodu, przeglądanie sieci i zarządzanie plikami — a Ty nie piszesz ani linijki kodu orkiestrującego. To ten sam agent harness, który napędza desktopowy Antigravity i terminalowe agy, tylko udostępniony jako usługa zarządzana.
Najkrótsza definicja, jaką spotkałem: wynajmujesz hostowany, sandboxowany agent harness z trwałym środowiskiem — zamiast go budować.
Jak to działa
Model pracy jest deklaratywny, nie imperatywny. Nie programujesz przepływu — opisujesz agenta i go wołasz.
1. Zdefiniuj zachowanie. Dwa pliki w naturalnym języku: AGENTS.md (jak agent ma działać, jaka topologia) i SKILL.md(co potrafi). To te same prymitywy, które znasz z agy i z całego ekosystemu agentowego — opis intencji, nie skrypt.
2. Zarejestruj jako managed agent. Agent zostaje zarejestrowany po stronie Google.
3. Zawołaj przez Gemini API. Jeden call. Pod spodem Google stawia izolowany sandbox Linux, w którym agent wykonuje zadanie — z trwałym stanem (persistent environment), więc kolejne wywołania mogą kontynuować, a nie zaczynać od zera.
Klucz jest w tym, czego tu nie ma: nie ma Twojego serwera, na którym agent się wykonuje, nie ma Twojego kodu orkiestrującego subagenty, nie ma Twojej obsługi sandboxa i czyszczenia stanu. To wszystko jest po stronie harness.
Co dostajesz w jednym wywołaniu
Agent uruchomiony przez Managed Agents API ma od razu zestaw zdolności, które normalnie składałbyś tygodniami:
- Wieloetapowe rozumowanie — planuje i wykonuje zadanie złożone z wielu kroków, nie pojedynczą odpowiedź.
- Tool calling — wywołuje narzędzia, w tym przez MCP (mamy osobny wątek o MCP).
- Wykonywanie kodu — w izolowanym środowisku, nie na Twojej maszynie.
- Przeglądanie sieci — agent sięga po dane z internetu w trakcie zadania.
- Zarządzanie plikami — czyta i zapisuje w swoim sandboksie.
To jest różnica między „mam model językowy i muszę dobudować wokół niego całą resztę” a „mam agenta, który już to wszystko potrafi i czeka na cel”.
Managed Agents kontra SDK — która powierzchnia jest Twoja
Łatwo pomylić Managed Agents API z Antigravity SDK, bo oba dają programistyczny dostęp do agentów. Różnica jest jedna i fundamentalna — gdzie wykonuje się agent.
SDK = model od Google (przez API), ale runtime i dane u Ciebie, na Twojej infrastrukturze. Pełna kontrola, pełna odpowiedzialność.
Managed Agents = model i runtime po stronie Google. Agent wykonuje się w sandboksie Google, nie na Twoim serwerze. Mniej kontroli, znikoma konfiguracja.
Wybór jest klasycznym „rent vs build”: SDK, gdy musisz trzymać wykonanie i dane u siebie (compliance, wrażliwe dane, własne środowisko). Managed Agents, gdy chcesz najszybszą drogę od pomysłu do działającego agenta i nie masz powodu hostować go samodzielnie.
Kiedy to ma sens
Managed Agents obniża próg wejścia w agentowe funkcje z miesięcy do minut — i to jest realna wartość, jeśli:
- budujesz agenta jako element produktu i nie chcesz utrzymywać infrastruktury wykonawczej,
- potrzebujesz izolacji wykonania (kod agenta nie dotyka Twoich systemów), a nie chcesz sam stawiać sandboxów,
- zależy Ci na trwałym stanie między wywołaniami bez budowania własnej warstwy persystencji.
Kiedy nie: gdy regulacje albo wrażliwość danych wymagają, by wykonanie i dane zostały na Twojej infrastrukturze — wtedy SDK, nie Managed Agents.
Druga twarz: pięć minut do produkcji ma swój cennik
Tu uczciwa nuta, bo „jeden call zamiast miesięcy” brzmi zbyt gładko. Wygoda usługi zarządzanej ma swoją cenę — i nie chodzi tylko o opłaty. Oddajesz Google wykonanie agenta, jego sandbox i jego stan; w architekturze, gdzie model jest Google, runtime jest Google, a Twoje dane przepływają przez środowisko, którego nie kontrolujesz, pojawia się pytanie o odpowiedzialność, koszt przy skali i zależność od jednego dostawcy. Rozkładamy to od strony bezpieczeństwa i kosztów w analizie „drugiej twarzy Managed Agents” — warto przeczytać przed wdrożeniem produkcyjnym.
To nie jest argument przeciw. To jest argument za świadomym wyborem: Managed Agents kupuje Ci czas, ale płacisz kontrolą.
Co z tego wynika
Managed Agents API to powierzchnia, która zmienia agenta z projektu infrastrukturalnego w wywołanie API. Definiujesz zachowanie w AGENTS.md i SKILL.md, rejestrujesz, wołasz — resztę (sandbox, wykonanie, stan) bierze na siebie harness Google. Dla zespołu, który chce dostarczyć agentową funkcję, a nie zbudować platformę pod nią, to jest najkrótsza droga w całej platformie Antigravity.
Pozostaje pytanie, gdzie agent ma się wykonywać — u Ciebie czy u Google. To jest dokładnie linia podziału między SDK a Managed Agents, i to jest temat osobnego wpisu o SDK, w którym wykonanie i dane zostają po Twojej stronie.
Pojęcia ze słownika: Managed Agents w Gemini API · Antigravity SDK · Antigravity 2.0 · Antigravity CLI (agy) · Gemini 3.5 Flash
