Migrar un agente cloud a local sin romperlo
Migrar a local no es cambiar una URL y celebrar. Cambian latencia, contexto, tool calling, calidad, observabilidad y límites de hardware. Hazlo por etapas y conserva una salida de emergencia.
Objetivos de aprendizaje
- Inventariar dependencias cloud antes de migrar.
- Probar compatibilidad de prompts, tools y contexto.
- Decidir qué queda local y qué mantiene fallback externo.
En cristiano: fallback. Es una ruta alternativa cuando el modelo local no basta: puede ser otro modelo local, vLLM en GPU o un proveedor cloud con aprobación y trazas.
Terminal
migration_matrix:
tasks:
classify_email:
target: "local"
model: "ollama/qwen2.5:7b"
risk: "low"
draft_legal_reply:
target: "hybrid"
local_first: true
cloud_requires_approval: true
edit_codebase:
target: "local_with_review"
requires_tests: true Idea clave. Migra primero tareas tolerantes a error: clasificación, borradores, resúmenes internos. Deja decisiones críticas para híbrido hasta tener evals.
Pruebas antes de cambiar producción
- Mismo input contra cloud y local.
- Comparar calidad, latencia y formato.
- Probar tool calling mínimo.
- Medir contexto real y truncado.
- Registrar fallos que exigen fallback.
Cuidado. Si el agente dependía de tool calling robusto, el modelo local puede fallar aunque responda bien en chat. Prueba tools antes de migrar flujos con acciones.
Comprueba que funciona. Ejecuta 30 tareas reales antiguas contra local y etiqueta: correcta, aceptable con edición, incorrecta, no sabe, formato roto. Sin esa tabla, migrar es fe.
Guardar y reabrir el proyecto.
Migrar bien no significa apagar la nube de golpe. Significa mover lo que ya puede vivir local, medirlo y dejar frontera clara para lo que todavía necesita más calidad.