inner loop
redeploy to test
Edit, build an image, push, redeploy, wait for it to come up — then check.
a2a dev hot reload
Edit, save, watch it reload in ~2s — then check.
save · reload · repeat
Hot reload your AI agent in about two seconds.
The inner loop for agents shouldn't be a deploy pipeline. `a2a dev` watches your local files, and every time you save, the change re-syncs and the running agent hot-reloads within roughly two seconds — on your scale-to-zero cloud dev box or on your own machine. No rebuild, no redeploy. Just edit, save, and see it.
edit · save · ~2s reload · no redeploy
0s
reload after save
0
rebuilds per change
redeploys to iterate
the problem
Redeploying to test one line kills the loop.
The way most teams iterate on a deployed agent is a CI cycle: change a file, build an image, push it, redeploy, wait for the rollout, then finally check. Repeat that for every handler tweak and every prompt edit and the inner loop is measured in minutes, not seconds. Iterating locally against mocks is faster but diverges from what actually runs in the cloud — so you end up choosing between speed and fidelity.
A rebuild-and-redeploy cycle per change turns iteration into minutes of waiting.
Local mocks are fast but drift from the runtime you actually deploy.
Re-running a single tool call means re-triggering through a redeployed endpoint.
The build-and-ship pipeline is the wrong tool for trying one edit at a time.
the a2a way
A live-reload loop, not a CI cycle.
`a2a dev` watches your files and reloads the agent in place on every save — about two seconds, no image build and no redeploy. Run it against the cloud dev box at a public URL or locally with --local, re-invoke tools from the /_dev console, and iterate against the same runtime you deploy.
Save, and it's already reloadingThe loop runs on the cloud dev boxOr reload entirely on your machineA dev console to re-invoke toolsNo rebuild, no redeploy per changeThe reloading runtime is the shipping runtime
Save, and it's already reloading
`a2a dev` watches your local files. Every save re-syncs the change and the running agent hot-reloads within about two seconds. There's no build step to sit through and no deploy to trigger — you edit, you save, you see it.
The loop runs on the cloud dev box
Each save rsyncs over SSH to your scale-to-zero cloud dev box, which reloads in place and serves at a public URL — https://<agent>-devbox.a2acloud.io. You get real cloud networking and secrets while keeping a local-feeling edit loop.
Or reload entirely on your machine
`a2a dev --local` runs the same watch-and-reload loop on your laptop — in Docker by default, or with --host-runtime to skip the container. Toggle it with --reload / --no-reload. Same reloader, no round trip.
A dev console to re-invoke tools
The dev console at /_dev lets you fire tool calls against the freshly reloaded agent. Change a handler, save, and re-run the exact invocation from the console — the reload-then-check step is right there in the browser.
No rebuild, no redeploy per change
This is a live-reload dev loop, not a CI cycle. You're not baking an image and pushing it through a pipeline to test one line — the file sync and in-process reload replace the whole build-and-ship round trip while you iterate.
The reloading runtime is the shipping runtime
The runtime that hot-reloads your saves in dev is the same runtime you deploy to production. What you iterate against and what you ship are the same thing — the fast loop doesn't drift from what actually runs.
side-by-side
Redeploy-to-test cycle vs. ~2s hot reload.
to see a change
redeploy to test
A full rebuild and redeploy cycle for every line you want to try.
a2a dev hot reload
A file save. The watcher re-syncs and the box reloads in place.
where it runs
redeploy to test
Locally against mocks, or a slow deploy to a shared cloud env.
a2a dev hot reload
The cloud dev box at a public URL, or --local — same reloader either way.
re-running a tool
redeploy to test
Re-trigger through your own harness or a redeployed endpoint.
a2a dev hot reload
Fire the invocation again from the /_dev console after each reload.
dev vs prod
redeploy to test
Dev shim diverges from the container image you actually deploy.
a2a dev hot reload
The reloading runtime is the runtime you deploy — parity, not a stand-in.
dimension
redeploy to test
a2a dev hot reload
inner loop
Edit, build an image, push, redeploy, wait for it to come up — then check.
Edit, save, watch it reload in ~2s — then check.
to see a change
A full rebuild and redeploy cycle for every line you want to try.
A file save. The watcher re-syncs and the box reloads in place.
where it runs
Locally against mocks, or a slow deploy to a shared cloud env.
The cloud dev box at a public URL, or --local — same reloader either way.
re-running a tool
Re-trigger through your own harness or a redeployed endpoint.
Fire the invocation again from the /_dev console after each reload.
dev vs prod
Dev shim diverges from the container image you actually deploy.
The reloading runtime is the runtime you deploy — parity, not a stand-in.
questions
Frequently asked.
How does hot reload work for AI agents on a2a cloud?
`a2a dev` watches your local files and, on every save, rsyncs the change over SSH to your cloud dev box, which hot-reloads the running agent in place within about two seconds. There's no image rebuild and no redeploy in the loop — the file sync plus an in-process reload is the whole cycle, so a save is all it takes to see the new behavior.
How fast is the reload after I save a file?
Roughly two seconds from save to the reloaded agent being ready. Because it's a live-reload loop rather than a build-and-deploy pipeline, you're waiting on a file sync and an in-process reload, not on an image build or a rollout. That's the point: a fast inner loop where editing a handler and re-running it feels immediate.
Can I hot-reload the agent locally instead of on the cloud box?
Yes. `a2a dev --local` runs the same watch-and-reload loop on your machine — in Docker by default, or with --host-runtime to run directly on the host. You can toggle reloading with --reload / --no-reload. The reloader is the same whether the loop runs on the cloud dev box or locally.
Do I have to rebuild or redeploy to test a change?
No. That's the whole distinction — `a2a dev` is a live-reload dev loop, not a CI cycle. You don't bake an image and push it through a pipeline to try one edit. You save the file, the watcher re-syncs it, and the runtime reloads in place. Rebuild and redeploy belong to shipping, not to iterating.
Is the dev runtime the same as what I deploy to production?
Yes. The runtime that hot-reloads your saves during `a2a dev` is the same runtime you deploy to production, so what you iterate against and what you ship don't drift apart. The /_dev console lets you re-invoke tools against the reloaded agent, and the behavior you confirm there is the behavior that runs in prod.
keep reading
Related guides.
All guides live in the guides index.
fast inner loop
Save the file. The agent's already reloaded.
a2a cloud gives every agent a live-reload dev loop: `a2a dev` watches your files and hot-reloads within about two seconds — on a scale-to-zero cloud dev box at a public URL, or locally with --local. Re-invoke tools from the /_dev console, iterate against the same runtime you deploy, and skip the rebuild-and-redeploy round trip while you work. No CI cycle to try one edit.