Tus prompts en producción no son config. Son código.
El lunes por la tarde cambias tres palabras del system prompt. "Eres un asistente de facturación" pasa a ser "Eres un asistente experto en facturación". Suena mejor. El staging lo pruebas con diez casos, todos bien. Haces deploy.
El jueves, el equipo de contabilidad te dice que hay 47 facturas mal clasificadas. Revisas los logs: no hay ninguna excepción. El código es idéntico. Solo cambiaron tres palabras.
Este escenario ocurre en el 100% de los equipos que tratan sus prompts como configuración y no como código.
Por qué un prompt es código de producción
El código determinista tiene un contrato claro: misma entrada, misma salida. Si cambias parseFecha(), los tests fallan o pasan. Lo ves inmediatamente.
Un system prompt no es determinista. Es una instrucción que el modelo interpreta, y esa interpretación cambia según el contexto, el documento de entrada, y la versión exacta del modelo. Cuando modificas el prompt, no estás editando lógica de negocio. Estás cambiando el comportamiento estadístico de un sistema que decide qué hacer.
Tres palabras de diferencia pueden significar que el modelo, ante un documento ambiguo, tome decisiones distintas. No en el caso principal que siempre testeas: en el 5% de casos de borde que el cliente encuentra cada semana.
Los equipos que entienden esto gestionan sus prompts con el mismo rigor que el código: versionado semántico, deploy controlado, rollback automático, audit log. Los equipos que no lo entienden hacen hotfixes reactivos cada vez que algo sale mal.
Los cuatro errores más comunes en gestión de prompts
1. El prompt vive en una variable de entorno o en un .env
Un .env no tiene historial. No sabes quién cambió qué ni cuándo. Si hay un problema en producción, no puedes correlacionarlo con un cambio de prompt específico. Los prompts deben vivir en un sistema con versionado explícito.
2. Se cambia el prompt de producción directamente
Sin staging para el prompt. Sin canary. Sin evals previos. El cambio entra directo al 100% del tráfico. El primer aviso es una queja de cliente.
3. No existe un audit log de cambios
¿Quién aprobó la versión actual? ¿Cuándo se desplegó? ¿Qué diferencia tiene con la anterior? Sin este log, depurar un incidente de producción tarda horas en lugar de minutos.
4. Las versiones no son semánticas
"prompt_v2_definitivo_final" no es versionado. v1.3.2 sí lo es: major para cambios de comportamiento incompatibles, minor para mejoras compatibles, patch para correcciones menores.
Implementación: un prompt registry en TypeScript + Supabase
La solución más práctica para equipos medianos: una tabla en Supabase que actúa como registry central de prompts.
-- migration: create prompt_registry table
create table prompt_registry (
id uuid primary key default gen_random_uuid(),
agent_id text not null, -- "invoice-extractor", "support-bot"
version text not null, -- semver: "1.3.2"
content text not null, -- el system prompt completo
traffic_pct integer default 100, -- % de tráfico que recibe esta versión
is_active boolean default false,
deployed_by text,
deployed_at timestamptz default now(),
eval_score numeric, -- último score de evals (0–1)
notes text
);
-- índice para consulta rápida del prompt activo
create index idx_prompt_registry_active
on prompt_registry(agent_id, is_active, traffic_pct);
El cliente TypeScript que carga el prompt correcto:
import { createClient } from "@supabase/supabase-js";
const supabase = createClient(
process.env.SUPABASE_URL!,
process.env.SUPABASE_SERVICE_KEY!
);
interface PromptVersion {
version: string;
content: string;
traffic_pct: number;
}
export async function getActivePrompt(agentId: string): Promise<string> {
const { data, error } = await supabase
.from("prompt_registry")
.select("version, content, traffic_pct")
.eq("agent_id", agentId)
.eq("is_active", true)
.order("traffic_pct", { ascending: false });
if (error || !data?.length) {
throw new Error(`No active prompt found for agent: ${agentId}`);
}
// Si hay dos versiones activas (canary), distribuir tráfico
if (data.length === 2) {
const rand = Math.random() * 100;
return rand < data[1].traffic_pct
? data[1].content // versión canary
: data[0].content; // versión estable
}
return data[0].content;
}
Este patrón permite tener dos versiones activas simultáneamente: la estable con el 90% del tráfico y la canary con el 10%, sin ningún cambio en el código del agente.
Canary deployment para prompts
El flujo de un cambio de prompt controlado:
1. Crear nueva versión en registry (is_active: false)
2. Ejecutar evals contra el golden dataset → score ≥ 0.90
3. Activar con traffic_pct: 10 (canary)
4. Monitorizar 24h: eval_score, error_rate, latencia
5. Si score mantiene → escalar a 50% → 100%
6. Si score cae → rollback automático (is_active: false)
El script de rollback automático, integrado en el job de monitoreo:
import Anthropic from "@anthropic-ai/sdk";
const anthropic = new Anthropic();
async function monitorCanary(agentId: string) {
const score = await runEvalSuite(agentId, "canary");
if (score < 0.90) {
// Desactivar la versión canary
await supabase
.from("prompt_registry")
.update({ is_active: false })
.eq("agent_id", agentId)
.lt("traffic_pct", 100);
console.error(
`[ROLLBACK] ${agentId} canary score ${score} < 0.90 — revertido a versión estable`
);
}
}
Este es exactamente el tipo de infraestructura que en DAILYMP configuramos desde el inicio de cada proyecto de agentes IA, no como parche después del primer incidente.
Por qué esto se conecta con tus evals
El prompt registry sin evals es un sistema de versionado sin criterio de calidad: sabes qué cambió pero no sabes si el cambio fue bueno. Si todavía no tienes un golden dataset para evaluar tus agentes en producción, empieza por ahí.
La cadena completa es:
evals definen el umbral de calidad
→ prompt registry gestiona las versiones
→ canary controla la exposición
→ rollback automático si el score cae
→ audit log explica qué ocurrió
Cualquier eslabón que falta hace el sistema frágil. Muchos equipos tienen el agente funcionando pero no tienen ninguno de estos cinco.
Lo que separa el prototipo del sistema mantenible
Un agente sin gestión de prompts es un sistema que funciona mientras nadie lo toca. Cada cambio de prompt es un evento de riesgo sin red de seguridad.
Con un registry sencillo, semver explícito y un canary del 10%, cada cambio de prompt pasa por el mismo rigor que un deploy de código. El rollback tarda segundos, no horas. El audit log responde "¿quién cambió esto y cuándo?" en una consulta SQL.
El coste de montar esta infraestructura en un proyecto nuevo es de horas. El coste de añadirla después del primer incidente grave es de días de trabajo reactivo, más la confianza del cliente.
Si tienes agentes en producción con prompts que se cambian sin control, podemos auditar el estado actual y montar la infraestructura correcta: