Managed Agents API stawia agenta w sandboksie Google.
SDK stawia go u Ciebie. To ta sama platforma, dwie różne odpowiedzi na pytanie „gdzie to się wykonuje”.
We wpisie o Managed Agents API agent uruchamiał się jednym callem w izolowanym środowisku Google — wygodnie, ale wykonanie i dane przechodziły przez infrastrukturę, której nie kontrolujesz. Antigravity SDK to druga odpowiedź: ten sam agent harness, ale uruchamiany na Twojej własnej infrastrukturze. Jeśli budujesz coś, co z powodów compliance, kosztowych albo architektonicznych musi zostać u Ciebie — to jest ta powierzchnia.
Czym jest Antigravity SDK
Antigravity SDK to zestaw bibliotek programistycznych dający programmatic control nad agent harness — tym samym, który napędza desktopowy Antigravity i terminalowe agy. Pozwala definiować własne zachowania agentów i hostować je na własnej infrastrukturze. Dostępny jako biblioteka Pythona — antigravity-sdk-python na GitHubie, instalacja przez pip install google-antigravity.
Kluczowa cecha architektoniczna to rozłączenie modelu od runtime: model przychodzi od Google przez API, ale środowisko wykonawcze i dane są Twoje. To jest dokładnie ta linia, która oddziela SDK od Managed Agents.
Rozłączenie modelu od runtime — czemu to ważne
W klasycznym ustawieniu „agent w chmurze dostawcy” wszystko jest po jednej stronie: model, wykonanie, dane, sandbox. Wygodne, ale oznacza, że Twoje dane i Twój kod przepływają przez infrastrukturę dostawcy.
SDK rozcina to na dwie warstwy. Model (inteligencja agenta — Gemini, przez API) zostaje po stronie Google. Runtime(gdzie agent faktycznie się wykonuje, jakie pliki czyta, jakie narzędzia woła, gdzie ląduje stan) zostaje u Ciebie. Agent „myśli” zdalnie, ale „działa” lokalnie, w środowisku, które kontrolujesz.
To ma konkretne konsekwencje:
- Dane nie opuszczają Twojej infrastruktury w zakresie wykonania — model dostaje to, co mu podasz, ale agent operuje na Twoich systemach, nie w cudzym sandboksie.
- Kontrolujesz środowisko — biblioteki, dostępy, sieć, polityki. Nie jesteś ograniczony do tego, co przewidział sandbox dostawcy.
- Bierzesz odpowiedzialność — za bezpieczeństwo wykonania, izolację, sprzątanie stanu. To, co przy Managed Agents robił harness Google, tu robisz Ty.
SDK kontra Managed Agents — pełna tabela wyboru
To jest decyzja, którą warto podjąć świadomie na początku, bo determinuje architekturę.
| Antigravity SDK | Managed Agents API | |
|---|---|---|
| Model | Google (API) | Google (API) |
| Runtime | Twoja infrastruktura | Sandbox Google |
| Dane przy wykonaniu | U Ciebie | W środowisku Google |
| Konfiguracja | Pełna, Twoja | Minimalna |
| Odpowiedzialność za sandbox | Twoja | |
| Próg wejścia | Wyższy | Minimalny (jeden call) |
| Kiedy | Compliance, wrażliwe dane, własne środowisko | Najszybsza droga do działającego agenta |
Reguła kciuka: jeśli musisz odpowiedzieć „gdzie wykonał się ten agent i czyje dane przez niego przeszły” przed audytorem albo działem bezpieczeństwa — SDK. Jeśli budujesz funkcję produktową i izolacja po stronie Google Ci wystarcza — Managed Agents.
Co budujesz na SDK
SDK jest dla przypadków, w których potrzebujesz agenta jako trwałego elementu własnego systemu, nie jako wywołania usługi:
- Agenty osadzone we własnym backendzie — działające obok Twojego kodu, z dostępem do Twoich wewnętrznych systemów na Twoich zasadach.
- Custom agent behaviors — własne definicje zachowań, wykraczające poza to, co daje gotowy harness; szablony agentów dostępne też w AI Studio.
- Integracja z MCP — SDK wspiera podłączanie agentów do zewnętrznych źródeł danych przez MCP (mamy osobny wątek o MCP), więc agent zbudowany na SDK wpina się w ten sam ekosystem narzędzi co reszta.
Gdzie SDK styka się z enterprise
Dla organizacji SDK rzadko stoi sam — jest częścią mostu między lokalnym budowaniem a wdrożeniem w chmurze. Google spina to przez Gemini Enterprise Agent Platform (ewolucję Vertex AI): budujesz lokalnie na SDK, wdrażasz do chmury z governance, session memory, audytem i kontrolą dostępu. Warstwa protokołów jest wspólna, więc agent zbudowany lokalnie nie wymaga przepisania pod produkcję.
To jest istotne, jeśli myślisz o agentach w kontekście firmowym: SDK to nie ślepa uliczka „działa u mnie, ale nie w produkcji” — to początek ścieżki, która ma swój ciąg dalszy w enterprise.
Co z tego wynika
Antigravity SDK to powierzchnia dla tych, którzy nie mogą albo nie chcą oddać wykonania agenta dostawcy. Model zostaje od Google, runtime i dane zostają u Ciebie — z całą kontrolą i całą odpowiedzialnością, jaką to niesie. To dokładne przeciwieństwo Managed Agents, i właśnie dlatego te dwie powierzchnie najlepiej rozumieć razem: to nie konkurenci, to dwa końce jednej osi „gdzie wykonuje się agent”.
Wybór między nimi nie jest techniczny — jest o tym, gdzie w Twojej architekturze leży granica zaufania i odpowiedzialności. Reszta platformy (desktop, agy, Enterprise Platform) to różne wejścia do tego samego harness; SDK jest tym, które oddaje Ci najwięcej kontroli.
Pojęcia ze słownika: Antigravity SDK · Managed Agents w Gemini API · Antigravity 2.0 · Antigravity CLI (agy) · Gemini 3.5 Flash
