What agentic flow development needs

## The human must deploy — that is the problem

Every write lands as an undeployed editor change and stops there. A human has to click **Deploy** and say so before the agent can see whether anything worked.

That makes the human the transport between every edit and its consequence. One page took six of those round-trips — three of them only to find the change was wrong.

The agent has to deploy its own code. And the deploy has to report readiness, or the agent is still guessing when to look:

- guessing `wait_ms` before checking a rendered page
- telling a mid-restart `502` from a real failure
- polling the database to see whether a migration ran

## Then the two read/write primitives

### `get_flows`

Read the whole config, one call, no browser.

Today: the editor-mirroring `flow_building_*` tools, or take a snapshot.

### `set_flows`

Write it back, one call.

Today, creating 27 nodes cost:

| | |
| --- | --- |
| Rejected `add_nodes` attempts | 5 |
| `set_links` calls | 7 |
| `set_wires` calls | 2 |
| Round trips | ~15 |
| Resent payload | ~50k tokens |

For what is one `POST /flows` with a JSON body.

Start by tracing the existing flow_building_* tools and the POST /flows endpoint, then compare how add_nodes, set_links, and set_wires currently assemble a flow. The issue's proposed get_flows, set_flows, and agent-controlled deploy need a defined entry point and acceptance criteria before implementation can begin; done should include readiness reporting after deployment.

Written by the indexing model from the issue text.