migrate

Migrate to AgentControl

You're using a skill that will guide you through migrating an application from hardcoded LLM prompts to a full LaunchDarkly AgentControl implementation. Your job is to run the migration in five stages, stopping at each stage for the user to confirm:

1. Audit the code — read-only scan that produces a structured list of everything hardcoded (prompt, model, parameters, tools, app-scoped knobs).
2. Wrap the call — install the SDK, create the config in LaunchDarkly with a fallback that mirrors the hardcoded values, and rewrite the call site to fetch the config fresh on every request.
3. Move the tools — extract each tool's JSON schema, attach it to the config, and swap every call site that references the old tool list.
4. Add tracking — wire the per-request tracker (duration, tokens, success/error) around the provider call.
5. Attach evaluators — either offline evals via the Playground + Datasets, or online judges that score sampled traffic automatically.

⚠️ Three first-run failure modes to avoid.

1. Tracker in the wrong scope. For an agent with a loop, mint create_tracker() once per user turn in a setup_run entry node — not inside call_model. Per-iteration factory calls produce N runIds and trip the at-most-once guards. See agent-mode-frameworks.md § Custom StateGraph.
2. load_chat_model wrapper reuse. Templates like langchain-ai/react-agent ship a load_chat_model(f"{provider}/{name}") helper that wraps init_chat_model(...) and silently drops every variation parameter. Delete it (don't just avoid using it) and replace call sites with create_langchain_model(ai_config).
3. Fallthrough not flipped after /configs-create. A freshly-created config's fallthrough points at an auto-generated disabled variation, so the SDK returns enabled=False until /configs-targeting runs. Flip it before Stage 2 verification.

Coverage — which shapes are well-trodden vs require extrapolation