Antigravity's /run-workflow writes the Python that runs your agent fleet: 7 mechanics, the parallel() failure mode, and when /swarm is the better call

Google rolled Dynamic Workflows into Antigravity this week. You type /run-workflow plus a task, and the agent writes a short Python script that starts other agents for you, in parallel or in sequence, and collects a structured result from each one. The docs are live now, and the feature is available on Google AI Pro and Ultra plans in both the Antigravity App and the CLI.

I read the full documentation page before writing this, and most of it is a calm description of primitives. The interesting parts are what the design implies about context, permissions, and failure handling. Here is what stood out.

What the agent actually writes

When you run /run-workflow, the agent reads its built-in run-workflow skill and generates a Python script for your task. Antigravity shows you the script and asks you to approve it, unless your permission preset already allows it. The workflow then runs in the background in a separate Python process, and when it finishes, the main agent reads the logs and output, then summarizes the results in your conversation.

The example script in the docs is short enough to read in full:

phase("Discover")
files = await agent(
    "List the Python files changed since main. Paths only.",
    schema={"type": "array", "items": {"type": "string"}},
)

phase("Review")
reviews = await parallel(
    files,
    lambda f: agent(
        f"Review {f} for unhandled exceptions. Reply with a one-line verdict.",
        schema={"type": "string"},
        role=f"Review {f}",
        model="flash",
    ),
)

for r in reviews:
    log(r)

Every agent gets its own conversation

Each agent a workflow starts works in its own conversation. File reads, searches, and test logs stay out of your main conversation's context. That is the quiet headline of this release: fan-out work stops paying the context tax on the thread you are actually sitting in.

Results come back through a finish tool that checks each agent's answer against the JSON Schema you passed to agent(). The script receives a parsed value, not prose you regex apart. If you have been following the MCP file transfer draft, this is the same instinct applied to orchestration: keep the bulk bytes out of the model's way, hand around small validated summaries instead.

Agents cannot see the script or each other

Workflow agents are full agents, but they do not see the orchestration script and they do not see each other. The docs state the consequence plainly: the script must give each agent everything it needs in its prompt and ask for a short, well-defined result.

If your reviewers need the coding standard, the script pastes it in or names the file. Implicit context does not travel. This is the same discipline as keeping a tight AGENTS.md or CLAUDE.md, applied per agent instead of per repo, and it is why stale instructions hurt so much: your agent obeys whatever is written down, and in a workflow nothing else exists.

The primitives, and the parallel() failure mode

The building blocks are phase(name) for grouping, log() for output lines, agent() for one-shot or multi-turn agents, parallel(items, fn) for concurrency, pipeline(items, fn) for one-at-a-time ordering, and await trajectory() to read earlier steps of the conversation that existed before the workflow started. There is also an args dictionary for runtime inputs.

The one sentence worth memorizing is about parallel(): if one item fails, the others are canceled. On a 40-file review where one agent trips, the 39 in-flight results die with it. The docs describe no retry and no partial-result mode for that case, so treat a failed item as a whole-phase retry, keep phases small, and reach for pipeline() when ordering matters more than speed.

Model, workspace, and agent type knobs

Three settings do most of the work. model defaults to inherit, and the docs suggest flash_lite or flash for fast, high-volume checks across many files, or pro for deeper reasoning. workspace can be inherit, branch for an isolated Git worktree per agent (the right call when agents edit code in parallel), or share for working copies over shared repository storage. type_name picks the agent type: self, the built-in read-only research agent, or one of your custom subagents.

Multi-turn agents are the subtle one. Assign a = agent(...), then await a(prompt) runs one turn of a conversation that persists across calls, so the reviewer that found the bugs can later be asked to confirm the fixes, with its earlier context intact.

Permissions have two layers

Approving the script is one approval, and the docs note that it covers that exact script: a command prefix rule cannot cover a Python script. The second layer is per agent. Every agent a workflow starts follows your permission preset and asks for approval in its own conversation, and it waits until you answer.

So approving the script does not pre-approve what its agents later do. That split is honest, and it also means an unattended preset delegates both layers at once. Worth knowing before you fan out twenty agents with write access.

When /swarm or Orchestrator is the better call

The docs include a comparison table, and the boundaries are useful. Orchestrator is a single conversation where a planner model routes execution to a lighter model. Subagents are for delegating one task while you keep working. Dynamic Workflows are for predictable, scripted control flow: the same check across a list of files or packages, staged steps in sequence, a reviewer-and-fixer loop where agents return structured results to a script instead of talking to each other.

If your agents need to coordinate while they work, to agree on interfaces or review each other's diffs on a shared message board, that is /swarm territory. A workflow script cannot express peer coordination, because the agents cannot hear each other.

Practical notes for running it

Antigravity bundles its own Python, unpacked on the first workflow run, so there is nothing to install. To use a different interpreter, set ANTIGRAVITY_PYTHON to a Python 3.8 or later on your PATH; if it cannot start, the workflow stops with an error naming the variable. Ask the agent to save a script that works into your project, and it becomes a rerunnable, reviewable artifact sitting next to the code it operates on, which beats a chat transcript you can never quite reproduce.

Two closing cautions. A workflow that starts one agent per file is, by construction, many model calls, so the per-agent model choice is where your cost control lives. And if you used the legacy Workflows feature, it is deprecated, with /migrate-workflows in the App 2.12.0 or later to move it forward.

The shape of this is what I find most interesting: orchestration as generated, inspectable code, with schema-shaped results and isolated contexts. That is a far cleaner contract than hoping a room full of agents talks nicely.