Google's Antigravity SDK lets you assemble your own agent hub

I have wanted this thing for months. Not the SDK exactly, but the small dignity of running an agent inside my own hub and being able to answer, at any point, "what is it doing right now?". Google's Antigravity SDK, published on September 8, 2026, is the piece I was waiting for: the same runtime that powers Antigravity 2.0 and the Antigravity CLI, exposed as a library you can wire into your own control plane.

If you are on a platform team that has been quietly weighing "adopt a managed agent platform" against "build our own hub and keep control of the trust boundary", this changes the shape of that conversation. You are no longer choosing between the polished commercial box and a wall of glue code.

What the SDK actually is

Google frames the choice honestly. For teams that want turnkey deployment and governance, the pitch is still Gemini Enterprise Agent Platform. The SDK is for the other camp: developers with bespoke workflows or custom execution engines, building lightweight agent hubs from the ground up. What they get is the runtime engine used inside Antigravity 2.0 and its CLI, published as a library. When the core runtime is updated, agents built on the SDK inherit those changes automatically.

The runtime supports Gemini 3.1 Pro and Gemini 3.8 Flash, and the announcement centres on a Python API.

The four pieces I care about

Google groups the SDK around four building blocks, and each one maps onto a real pain I have hit trying to run agents in production workflows.

Start with skills. A skill in the Antigravity SDK is a folder with a SKILL.md file, and the runtime picks them up from filesystem paths you pass in, then injects them into the agent's prompt dynamically. No external registry to babysit. If you have ever shipped a prompt-template package and regretted the release process, you will feel the difference on your first commit.

Next, the built-in file tools. The SDK ships LIST_DIR, FIND_FILE, SEARCH_DIR, VIEW_FILE, CREATE_FILE and EDIT_FILE, and they execute only inside directories you list in the workspaces parameter, governed by declarative safety policies such as policy.workspace_only(). Operations outside the authorized paths are blocked. This is the part I would have hand-rolled badly. Having it as a first-class config item saves an entire class of near-misses.

Then the session trajectories. Every conversation carries a save_dir and a conversation_id, and the runtime persists full turn trajectories, tool receipts and artifacts under traj-<conversation_id>. Reattach a session by passing the same id back in. Anyone who has tried to reconstruct what an agent actually did from a scrollback buffer will read the trajectory docs first.

Last, the lifecycle hooks. Async hooks fire at session start, before and after each tool call, and at session end. The pre_tool_call_decide hook is the human-in-the-loop gate: your code can approve, modify or reject a tool call before it runs. Hooks also broadcast telemetry over WebSockets, which is how the Google post frames the dashboard use case: watch multiple agents live and steer them when they drift.

There is a small extra treat in the response API. A single model response exposes three concurrent async iterators: response for the visible tokens, response.thoughts for the internal reasoning deltas, and response.tool_calls for typed tool events. If you want a UI that shows the agent's thinking in one pane and its actions in another, that is the shape you want.

Where it fits, and where I would still hesitate

The best fit is a platform team that already knows what an agent hub should feel like for its developers, and just wants a runtime that will not fight them. The declarative workspace policies mean you can hand a hub to a product team without also handing them a paved road to shell out.

I have two honest reservations. The SDK is Python in this announcement, so a JVM or Go platform team is looking at a sidecar or a wait. And it is a Google runtime built to run Gemini models. If your compliance story requires model portability, an SDK that lists two Gemini variants as its supported models is a signal to plan for that boundary early.

What I am watching next

Two things. Whether the trajectory format is stable enough to use as a compliance artifact (auditors love a directory of receipts, as long as the schema does not drift on them). And whether other agent runtimes take the "skills are directories" shape seriously. If they do, prompt packaging finally starts to look like software, and CI teams stop shipping prompts through backchannels.

If you try it, tell me what your first hook did. Mine will be a boring one: log to the same aggregator every other service already writes to, so on-call has one place to look.