Migrate Dialogflow CX (DFCX) agents to CXAS (Customer Experience Agent Studio) agents. Use this skill when the user mentions DFCX migration, migrating agents, converting DFCX to CXAS, porting agents, agent migration, or post-migration optimization/consolidation. Four independently runnable scripts: migrate.py (1:1), stage_1.py (variable dedup + consolidation), stage_2.py (instruction state machines + tool mocks + lint + report), stage_3.py (rewires consolidated topology from source dep graph; only needed when stage_1 ran consolidation). State persists between scripts via <target>_ir.json so each can run / re-run / resume independently.
Migrate Dialogflow CX (DFCX) agents to CXAS (Customer Experience Agent Studio) agents. Use this skill when the user mentions DFCX migration, migrating agents, converting DFCX to CXAS, porting agents, agent migration, or post-migration optimization/consolidation. Four independently runnable scripts: migrate.py (1:1), stage_1.py (variable dedup + consolidation), stage_2.py (instruction state machines + tool mocks + lint + report), stage_3.py (rewires consolidated topology from source dep graph; only needed when stage_1 ran consolidation). State persists between scripts via <target>_ir.json so each can run / re-run / resume independently.
DFCX to CXAS Migration
Four small scripts, one persistent IR bundle:
Script
What it does
Runtime
Output
migrate.py
1:1 conversion of every selected playbook/flow into the IR, and deploys base resources only (app, variables, tools). Agent deployment is DEFERRED to stage_1.py so large sources don't exceed the CXAS 100-agent cap — the compiled agents are saved in <target>_ir.json, not pushed. Pass --no-consolidate to push the full 1:1 agent set immediately (only safe below ~100 agents).
Loads the IR bundle, runs CXASOptimizer.optimize_stage1 (variable dedup) and Gemini structural consolidation (N→M agent grouping). This is the first agent push to CXAS — only the consolidated (N→M) agents are deployed; the raw 1:1 originals are never pushed (consolidate() drops them and the pre-consolidation snapshot is used transiently for the integrity check only, never persisted). CXAS Version (dedup) and (consolidation).
0.0.2
0.0.3
~15 min
Updated <target>_ir.json, <target>_grouping.json
stage_2.py
Loads the IR bundle, runs CXASOptimizer.optimize_stage2 (instruction state machines + tool mocks). Pushes via update-pass deploys. CXAS Version 0.0.4. Re-generates unit tests. Lints. Writes the audit report.
Only after Stage 1 consolidation. Rewires the consolidated agents' parent → children topology by mapping the SOURCE DFCX dep graph onto the new groups (rather than relying on what the synthesized PIF XML happened to reference) according to Spoke-Hub architecture style. Sets app root_agent to the is_root group. Idempotent — safe to re-run. CXAS Version 0.0.5.
~10 sec
Updated <target>_ir.json stage history; CXAS app's child_agents set per group
State flows through <target>_ir.json (a Pydantic IRBundle containing the MigrationConfig, source DFCXAgentIR, target MigrationIR, stage history, and version checkpoints). Each stage loads it from disk, mutates it, and writes it back. No re-fetching or re-compiling between stages.
When to use this skill vs. the CLI directly
This skill (InquirerPy prompts + HTML pre-flight preview + Gemini model picker) is the right entry when you want to interactively drive a migration with rich pre-flight context. The same MigrationService.run_stage* methods this skill calls are also exposed via the canonical CLI for scripted / CI use:
The skill, the dashboard, and the E2E / Checkpoint commands all go through the sameMigrationService.run_stage_1/run_stage_2/run_stage_3 methods — pick whichever entry point matches your workflow.
Prerequisites
# Ensure cxas_scrapi is installed editable (so this skill picks up local changes)
pip install -e .
# Auth
gcloud auth application-default login
gcloud auth list # confirm the account has read on source + admin on target
InquirerPy is required for the interactive prompts (matches the agent-foundry skill):
pip install InquirerPy
Driving the flow interactively (from Claude)
When invoked through Claude, lead the user through one question at a time. The scripts will prompt for missing inputs via InquirerPy, but you should pre-collect:
GCP project ID (target — where the new CXAS app will live).
Location — default us. Do NOT default to global — it does not work for CXAS apps in most projects.
Source agent — DFCX agent ID (full resource name) or path to a local .zip export.
The skill is a thin orchestrator. Every migration / optimization step lives in src/cxas_scrapi/migration/ and is reachable via MigrationService.run_stage_* methods, so the same logic powers all three entry points: this skill, cxas migrate dfcx (interactive TUI), and non-interactive command modes (--run / --optimize).
_shared.py — InquirerPy variants of project/location prompts, source loader, and MigrationConfig assembly; plus pure delegations to MigrationCLI for check_auth, run_dependency_analysis, select_resources, show_visualizations.
The stage scripts now import the promoted modules directly:
from cxas_scrapi.migration.data_models import IRBundle
(plus html_preview in migrate.py and phase_tracker) and call sites use the
canonical model names (IRBundle, phase_tracker.PhaseTracker,
html_preview.generate_html_report) — no re-export shim layer.
The skill's stage scripts (migrate.py / stage_1.py / stage_2.py / stage_3.py) are now ~80-200 line shells: parse args → restore service from bundle → call the matching MigrationService.run_stage_* → print summary. There is no orchestration logic left in the skill — only InquirerPy prompts and the HTML preview that's specific to the skill's pre-flight UX.HTML preview that's specific to the skill's pre-flight UX.
IR bundle (<target>_ir.json)
The unit of state shared across the three scripts. Pydantic IRBundle model:
{"schema_version":"1","created_at":"2026-05-14T15:30:00","config":{/* MigrationConfig */},"source_agent_data":{/* DFCXAgentIR — needed for tool-mock context */},"ir":{/* MigrationIR — mutated by each stage */},"stage_history":[{"phase":"migrate","status":"ok", ...},{"phase":"stage1","status":"ok", ...}],"app_url":"https://ces.cloud.google.com/...","version_checkpoints":[["0.0.1","Stage 1: ..."]],"grouping":{/* present if Stage 1 ran consolidation */}}
Killing a stage script mid-run leaves the bundle untouched (only persisted on success). Re-running picks up where the last successful stage left off.
Pre-flight HTML preview
migrate.py generates <target>_tree_preview.html in ~5 seconds after source loading. Open it in any browser to see:
Topology graph (graphviz SVG when dot is on PATH; Mermaid fallback otherwise).
Per-playbook and per-flow Rich trees.
migrate.py --preview-only exits after the preview without running the migration.
Troubleshooting
create_app returns 404 / 501 / MethodNotImplemented — your --location is wrong. CXAS apps in most projects live in us, not global. Pass --location us.
AlreadyExists: App with same display name — pick a different --target-name. Old runs leave deployed apps behind even on partial failure.
Stage 1 / Stage 2 fail with No IR bundle found — run migrate.py first to produce <target>_ir.json, or pass --ir-bundle <path> explicitly.
Synthesis (Stage 1 consolidation) hangs on Gemini — fixed with per-group asyncio.wait_for(timeout=600s) in structural_consolidator.synthesize_instructions. Override via SYNTHESIS_TIMEOUT_S env var. Hung groups fall back to the concatenated instruction.
gemini-2.5-flash-001 not found during AI augment — the Gemini call uses locations/global for the model; sometimes that endpoint is project-restricted. The migration continues with empty AI descriptions. Pick a different --model if you need them.
