Coding-agent workflows need a migration plan

Google's May update says Gemini CLI proved the terminal works well for agentic tasks, but users now need multiple agents, shared backend state, and a toolchain that does not stop at one local shell. Antigravity CLI keeps the familiar pieces, including skills, hooks, subagents, and extensions, but moves the center of gravity into the Antigravity platform.

That is reasonable product strategy. It is also a useful warning for anyone who glued their work to one agent surface. If your daily workflow depends on a specific CLI account tier, hidden backend, plugin format, or hosted sandbox, you do not really own the workflow yet. You own a habit that might need to move next quarter.

The fix is not to avoid vendor tools. That would be silly. The fix is to keep a plain-language runbook beside every useful agent workflow: what task it performs, what files or systems it may touch, what command starts it, what output proves success, and where the work should go if the preferred tool disappears.

OpenAI's Codex changelog for June 18 is a good snapshot of where this is going. Record & Replay on macOS can turn a demonstrated workflow into a reusable skill, with Computer Use enabled. Codex also added thread handoff between local and remote hosts, so a task can move to a matching project on another connected machine and continue there.

That is a big hint. The agent is not just writing code anymore. It is learning a sequence of actions, replaying it, and moving the thread between execution environments. Once that is normal, the old question, "which CLI did you use?" matters less than "can the job survive a host change?"

The June 2 Codex update points in the same direction. OpenAI says more than 5 million people use Codex weekly, with non-developers making up about 20 percent of users and growing faster than developers. Role-specific plugins and Sites are not just developer candy. They turn agent work into something analysts, marketers, operators, designers, and managers can touch. More people touching the workflow means more handoffs, more permissions, and more chances for a fuzzy run to become an expensive mess.

Anthropic has been pushing a slightly different shape: keep the agent close to real tools, then expose the work in ways other people can follow. The Claude Agent SDK docs describe agents that can read files, run commands, search codebases, use the web, edit code, ask user questions, spawn subagents, and keep session context. The working loop is simple: gather context, act, verify, repeat.

VentureBeat reported this week that Claude Code Artifacts bring live, shareable dashboards and interactive workspaces to Team and Enterprise users. The detail worth stealing is not the branded canvas. It is the idea that the agent's intermediate work should become visible enough for a teammate to inspect, not trapped in a scrollback buffer on one person's machine.

That changes the operator bar. A good agent workflow should leave enough structure that someone else can reopen it later and know what happened. If the only explanation is "the agent figured it out in my terminal," the setup is still a demo, even if the code works.

Start with the task, not the tool. Write the job in one paragraph. Name the allowed files, services, and commands. Name the one result that counts as done. If the task cannot be stated without naming the vendor, it is probably not portable yet.

Then capture the environment. Which repo? Which branch or worktree? Which browser profile? Which credentials are deliberately absent? Which network domains are allowed? This can be a short Markdown file. It does not need enterprise ceremony. It just needs to save future-you from reconstructing the weird little setup from memory.

Finally, keep a receipt and a fallback. The receipt should include the command or task ID, files changed, tests or checks run, sources used, and known failures. The fallback should say what to try if the preferred agent surface stops working: local CLI, cloud runner, browser agent, human script, or do nothing because the risk is not worth it. That last option is underrated.

Cass Bell sees the platform risk first. Her read: a useful workflow that only exists inside one vendor's affordances is not a workflow yet. It is a hostage with a nice UI. Copy the recipe before the product team renames the kitchen.

Ivy Chen cares about rollout. If a team adopts a new agent platform, the pilot should include the boring offboarding path: who owns failed runs, how work gets replayed somewhere else, and what happens after business hours when the agent cannot reach the system it expects.

Priya Rao wants the migration measured. Run the same three chores before and after the move. Track pass rate, wall-clock time, human corrections, and cost. If the new surface feels better but scores worse, you bought nicer wrapping paper.