Anti-Pattern Giant System Prompt: prompt del sistema gigante

Idea en 30 segundos

Giant System Prompt es un anti-patrón donde se intenta poner casi toda la lógica del agente en un único system prompt grande.

Como resultado, las instrucciones empiezan a entrar en conflicto, las prioridades se vuelven poco claras y el comportamiento del modelo se vuelve inestable. Esto aumenta latency, cost y el riesgo de regresiones después de cambios pequeños.

Regla simple: el system prompt debe ser corto y estable, y la lógica variable debe ir a bloques de ruta, capas policy y validación output en código. El system prompt debe definir rol y reglas base, pero no contener toda la lógica de negocio del sistema.

Ejemplo del anti-patrón

El equipo construye un agente de soporte y va agregando reglas nuevas en un solo system prompt.

Con el tiempo, ese prompt se convierte en un bloque gigante de instrucciones para todos los escenarios a la vez.

SYSTEM_PROMPT = """
You are support agent.
- Always be brief.
- Always provide detailed step-by-step explanation.
- Never call tools unless user asks.
- For payment issues always call get_payment_status.
- Reply only in strict JSON.
- Prefer natural text if JSON looks unnatural.
... hundreds of lines ...
"""

response = agent.run(
    system_prompt=SYSTEM_PROMPT,
    user_message=user_message,
)

En este esquema, el modelo ve demasiadas instrucciones con prioridades en competencia:

always_be_brief + give_step_by_step_explanation
json_only + prefer_natural_text
never_call_tools + always_call_payment_tool

Para este caso, es mejor tener un prompt base corto y bloques route-specific separados:

system_prompt = BASE_PROMPT + ROUTE_PROMPTS[route]

En este caso, un giant prompt añade:

• conflictos entre reglas
• mantenimiento difícil tras cambios
• formato y tono inestables en la respuesta

Por qué aparece y qué sale mal

Este anti-patrón aparece con frecuencia cuando el equipo quiere "resolver todo rápido con prompt" sin una frontera clara entre instrucciones, policy y lógica runtime.

Causas típicas:

• cada incidente nuevo se "arregla" con una línea más en system prompt
• falta modularidad: un prompt para todas las rutas
• las reglas policy viven en texto del prompt, no en código
• no hay responsables claros ni versionado de bloques prompt

Esto produce problemas:

• conflicto de instrucciones - el prompt contiene reglas contradictorias al mismo tiempo
• comportamiento inestable - la misma solicitud puede dar estilo y formato diferentes
• mayor latency y cost - un prompt largo aumenta tokens en cada run
• fragilidad de cambios - una edición pequeña puede romper otros escenarios
• debug difícil - cuesta entender qué regla se aplicó realmente

Señales típicas de producción de que el system prompt ya es demasiado grande:

• un cambio de regla causa regresión en otra ruta
• cost per request sube por un prompt largo y sin cambios
• el equipo no puede explicar rápido la prioridad entre dos instrucciones en conflicto
• tras una edición pequeña del prompt, cae el success rate en parte de los casos

La elección de herramienta, formato y estilo es parte de la inference del LLM. Cuando hay demasiadas instrucciones heterogéneas en el prompt, crece la cantidad de interpretaciones posibles y el modelo elige más veces una regla que encaja formalmente, pero no es la mejor para esa ruta.

Cuando este esquema crece, sin trace ni visualización de ejecución se vuelve difícil entender qué bloque prompt se usó en un run específico y qué regla influyó en el comportamiento del modelo.

Enfoque correcto

Empieza con un system prompt corto y estable que defina rol y reglas base. Mueve la lógica variable a bloques de ruta, policy gates y verificaciones output en código.

Marco práctico:

• mantén un BASE_PROMPT pequeño para reglas compartidas
• agrega ROUTE_PROMPTS solo para tipos de tarea concretos
• implementa policy y límites en código, no en un texto gigante
• valida output y mide el impacto de cambios (por ejemplo, mejora de success rate sin aumento fuerte de latency y cost per request)

Por ejemplo, el formato de respuesta debe verificarse con schema validation antes de devolver el resultado.

BASE_PROMPT = """
You are a support agent.
Follow safety and output rules.
"""  # stable instructions shared across all routes

ROUTE_PROMPTS = {
    "payment": "Use payment policy. Return strict JSON.",
    "refund": "Use refund policy. Ask clarifying question if needed.",
}

def run_support_agent(user_message: str):
    route = classify_intent(user_message)  # simple classifier or rules
    system_prompt = BASE_PROMPT + "\n\n" + ROUTE_PROMPTS[route]

    response = agent.run(
        system_prompt=system_prompt,
        user_message=user_message,
    )

    if not validate_output(response):  # schema / required fields / safety checks
        return stop("invalid_output")

    return response

En este esquema, las reglas se vuelven más transparentes: es más fácil actualizar una ruta concreta y hay menos probabilidad de romper escenarios vecinos.

Prueba rápida

Si estas preguntas se responden con "sí", tienes riesgo giant-system-prompt:

• ¿Un system prompt intenta cubrir casi todos los escenarios a la vez?
• ¿Una edición pequeña del prompt suele causar regresiones laterales en otros casos?
• ¿Es difícil determinar qué regla tiene mayor prioridad en un conflicto?

Cómo se diferencia de otros anti-patterns

Overengineering Agents vs Giant System Prompt

Too Many Tools vs Giant System Prompt

Agents Without Guardrails vs Giant System Prompt

Autoevaluación: ¿tienes este anti-patrón?

Revisión rápida del anti-pattern Giant System Prompt.
Marca los puntos para tu sistema y revisa el estado abajo.

Revisa tu sistema:

FAQ

Q: ¿Un system prompt largo siempre es malo?
A: No. El problema no es la longitud por sí sola, sino la monoliticidad y los conflictos. Si el prompt crece pero sigue modular y con prioridades claras, los riesgos son mucho menores.

Q: ¿Cuándo conviene mover una regla del prompt al código?
A: Cuando la regla es crítica para seguridad, costos o estabilidad de formato. Esas restricciones deben implementarse como verificaciones runtime explícitas, no solo como instrucción textual.

Q: ¿Cómo pasar de giant prompt a esquema modular sin gran refactor?
A: Empieza en pequeño: extrae BASE_PROMPT, añade 1-2 bloques route-specific para los casos más frecuentes y mueve gradualmente reglas policy del prompt a gates en código.

Qué sigue

Anti-patterns relacionados:

• Overengineering Agents - cuando la complejidad crece más rápido que el valor.
• Too Many Tools - cuando el ruido en la selección de herramientas vuelve inestable el comportamiento.
• Agent Everywhere Problem - cuando se usa un agente incluso para tareas deterministas.

Qué construir en su lugar:

• Allowed Actions - cómo fijar límites de acción en código.
• Routing Agent - cómo separar rutas y dar instrucciones relevantes.
• Policy Boundaries in Architecture - cómo mover policy del prompt a límites arquitectónicos explícitos.