Published in: agentes de ia

Context Engineering: diseña el contexto, no el prompt

Author Diego Parada

Published on: 21 de junio de 2026

Context engineering es el conjunto de técnicas para seleccionar, comprimir y priorizar la información que un LLM recibe en cada llamada. Parece una diferencia semántica frente a prompt engineering, pero en la práctica es la diferencia entre un agente que funciona en producción y uno que se degrada a las pocas decenas de turnos. Andrej Karpathy resumió este cambio de paradigma en pocas palabras cuando señaló que la habilidad crítica del próximo ciclo no era escribir mejores instrucciones, sino diseñar el contexto de forma deliberada.

Esta guía cubre los fundamentos y la implementación práctica de context engineering para builders que ya tienen un agente de IA para empresas en producción o que están a punto de desplegarlo. Verás por qué el context window es el recurso más caro de un sistema LLM, qué componentes lo forman, cómo evitar el context rot y cómo implementar caching, summarization y sliding window con código real. En Baigency hemos aplicado estas técnicas en producción con agentes de soporte, ventas y automatización de backoffice.

Esta guía asume familiaridad con APIs de LLM (OpenAI, Anthropic), Python y los fundamentos de IA agéntica. Si acabas de empezar con agentes, lee primero el post sobre arquitectura agéntica y vuelve aquí.

¿Qué es context engineering y por qué reemplaza al prompt engineering?

Context engineering es la disciplina de diseñar, estructurar y gestionar dinámicamente toda la información que entra en el context window de un LLM en cada inferencia. Va más allá del prompt engineering clásico, que se centra en la redacción de instrucciones estáticas, y aborda el ciclo completo de vida del contexto: qué entra, en qué orden, con qué peso relativo y cuándo se descarta o comprime.

El cambio no es cosmético. En 2023, los agentes eran experimentos con 2-3 herramientas y conversaciones cortas. En producción 2025/2026, un agente de soporte puede tener un system prompt de 4.000 tokens, definiciones de 30 tools, 20 turnos de historial, fragmentos de documentación recuperados por RAG y memoria episódica comprimida de sesiones anteriores. La suma supera fácilmente los 100.000 tokens en cada llamada. Aquí el prompt engineering clásico —«escribe mejores instrucciones»— es insuficiente. Lo que determina la calidad del output es qué información está disponible, dónde está colocada y qué no está.

Phil Schmid (Hugging Face) formalizó este concepto en su post de referencia, que define context engineering como «the practice of providing the right information, in the right format, at the right time». La clave es que los tres elementos son igual de importantes: no basta con que la información sea correcta si llega tarde o está mal formateada para que el modelo la use.

La diferencia práctica entre prompt engineering y context engineering se puede ver en esta tabla:

El in-context learning —la capacidad de un LLM de adaptar su comportamiento basándose en ejemplos dentro del context window— depende completamente de qué contexto proporcionas. Si el contexto está mal gestionado, el modelo no aprende de los ejemplos correctos en tiempo de inferencia, sino de los ruidosos o irrelevantes que llenaron el espacio disponible.

El context window: el recurso más caro de un LLM

El context window es la cantidad máxima de tokens que un LLM puede procesar en una sola llamada, incluyendo tanto el input (prompt + historial + tools + documentos recuperados) como el output que genera. GPT-4o tiene 128.000 tokens. Claude 3.5 Sonnet llega a 200.000. Gemini 1.5 Pro alcanzó 1 millón de tokens.

Estos números enormes crean una ilusión peligrosa: «si cabe todo, meto todo». El error tiene tres dimensiones:

• Coste: los modelos se facturan por token. Un agente que procesa 200.000 tokens por llamada puede costar 50-100x más que uno que gestiona 20.000 con el contexto correcto.
• Latencia: más tokens de input = más tiempo hasta el primer token de output (TTFT). En agentes conversacionales, una latencia de 8-12 segundos es inaceptable.
• Degradación de calidad: el paper Lost in the Middle (Liu et al., 2023) demostró que los LLMs son significativamente peores recuperando información de la zona central del context window. La información relevante enterrada en el medio de un prompt de 100.000 tokens es efectivamente invisible para el modelo.

Esto tiene una implicación directa de diseño: el context window no es un buffer infinito sino un recurso con retornos decrecientes que hay que gestionar activamente. El trabajo del context engineer es maximizar la relación señal/ruido en cada token que ocupa ese espacio.

La ventana de contexto tiene una estructura implícita de importancia. Los modelos prestan más atención al inicio (system prompt, instrucciones) y al final (mensaje más reciente del usuario). El centro tiende a degradarse en precisión. Un context engineer diseña sus artefactos sabiendo esto: las instrucciones críticas van arriba, el mensaje del usuario va abajo, y el historial del medio se comprime o resume.

Componentes del contexto: system, tools, memoria, RAG, historial

Un context window de producción tiene cinco componentes diferenciados, cada uno con su propio coste en tokens y su propio impacto en el comportamiento del modelo.

System prompt

El system prompt define la identidad, las restricciones y el modo de operación del agente. Es el único componente verdaderamente estático en la mayoría de implementaciones. En context engineering, el objetivo no es escribir el system prompt más largo o detallado, sino el más denso en información útil por token. Un system prompt de 6.000 tokens lleno de instrucciones redundantes o escenarios edge-case raramente usados malgasta espacio que podría ocupar contexto dinámico relevante. La heurística: si una instrucción nunca ha cambiado el output en tus tests, probablemente no la necesitas.

Tool definitions

Las definiciones de tools (function calling) se inyectan automáticamente en el context window con cada llamada. En agentes complejos, 30-50 herramientas pueden sumar 15.000-25.000 tokens antes de que el usuario haya escrito una sola palabra. La estrategia correcta es tool selection dinámica: en lugar de pasar todas las tools disponibles, un router inicial clasifica la intención del usuario y solo pasa al LLM las 5-8 herramientas relevantes para esa intención. El Model Context Protocol proporciona una arquitectura estándar para este tipo de selección dinámica.

Memoria y estado

Los LLMs no tienen memoria nativa entre llamadas. En un agente con estado —como los que se construyen con LangGraph— la memoria se gestiona externamente y se inyecta en el contexto. Existen tres niveles: memoria en sesión (el historial de la conversación actual), memoria episódica (resúmenes de sesiones anteriores) y memoria semántica (hechos sobre el usuario o el dominio). Cada nivel tiene un coste distinto en tokens y una frecuencia de uso distinta. La gestión de memoria es, en la práctica, el problema más complejo del context engineering en sistemas de larga duración.

Documentos recuperados por RAG

Los fragmentos recuperados por un pipeline de retrieval augmented generation pueden ser los más ruidosos del contexto. Un retriever que devuelve los top-10 chunks más similares semánticamente puede incluir información contradictoria, duplicada o marginalmente relevante. El context engineer define: cuántos chunks, de qué tamaño máximo, con qué umbral de similitud mínima, en qué posición dentro del prompt, y si se reranking post-retrieval antes de inyectar.

Historial conversacional

El historial crece con cada turno. Sin gestión activa, después de 20 turnos el historial puede ocupar el 60% del context window, desplazando información más relevante. La solución no es truncar de forma bruta (se pierden referencias importantes) sino comprimir inteligentemente mediante summarization y sliding window, que se cubren en la siguiente sección.

Estrategias: priorización, compresión, summarization, sliding window

Hay cuatro estrategias principales para gestionar el contexto activamente. En la práctica, un agente de producción usa combinaciones de las cuatro según la fase de la conversación.

Priorización y truncado selectivo

La estrategia más simple: asignar un nivel de prioridad a cada componente del contexto y, cuando el total supera el umbral, descartar los componentes de menor prioridad. El sistema prompt siempre es máxima prioridad. El mensaje más reciente del usuario también. El historial antiguo y los chunks de RAG con baja similitud son candidatos a eliminación. Esta estrategia es computacionalmente barata pero puede provocar pérdida de información cuando los turnos más antiguos son semánticamente necesarios para interpretar el turno actual.

Summarization de historial

En lugar de truncar, los turnos antiguos se resumen mediante una llamada LLM auxiliar (generalmente un modelo más barato) y el resumen reemplaza al historial completo. Esta técnica preserva la continuidad semántica a un coste en tokens mucho menor. La implementación más sencilla usa LangChain ConversationSummaryBufferMemory, que mantiene los últimos N turnos completos y resume todo lo anterior:

from langchain.memory import ConversationSummaryBufferMemory
from langchain_openai import ChatOpenAI

# Modelo auxiliar barato para summarization
summarizer_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

memory = ConversationSummaryBufferMemory(
    llm=summarizer_llm,
    max_token_limit=2000,       # tokens antes de resumir
    return_messages=True,
    memory_key="chat_history",
)

# Simular acumulación de historial
from langchain.schema import HumanMessage, AIMessage

turns = [
    ("¿Cuál es el límite de peticiones de la API?", "El límite es 1000 req/min en el plan Pro."),
    ("¿Y en el plan Starter?", "En el plan Starter el límite es 100 req/min."),
    ("¿Cómo puedo aumentar el límite?", "Puedes aumentarlo upgradeando al plan Enterprise."),
    ("¿Cuánto cuesta el Enterprise?", "Desde 499€/mes con facturación anual."),
    ("¿Hay periodo de prueba?", "Sí, 14 días sin necesidad de tarjeta de crédito."),
]

for human, ai in turns:
    memory.save_context({"input": human}, {"output": ai})

# El historial ahora está resumido si supera max_token_limit
print(memory.load_memory_variables({})["chat_history"])

El resultado: una conversación de 5 turnos que ocuparía ~800 tokens se convierte en un resumen de ~150 tokens sin perder los hechos clave (límites del plan, precios, prueba gratuita).

Sliding window

La sliding window es una política que mantiene siempre los últimos K turnos completos en el contexto, descartando los anteriores. Es la estrategia más simple y la más usada en chatbots conversacionales donde la continuidad a largo plazo no es crítica. Su debilidad: si el usuario hace referencia a algo dicho en el turno N-K, el agente no tendrá esa información. Se combina habitualmente con summarization: se mantiene el resumen de todo lo anterior + los últimos K turnos completos.

from collections import deque
from typing import List
from openai import OpenAI

client = OpenAI()

def sliding_window_chat(
    system_prompt: str,
    messages_history: deque,
    new_user_message: str,
    window_size: int = 10,
    model: str = "gpt-4o-mini",
) -> str:
    """
    Mantiene los últimos window_size turnos (humano+AI = 2 mensajes por turno).
    Descarta el historial más antiguo cuando se supera el límite.
    """
    # Añadir el nuevo mensaje del usuario
    messages_history.append({"role": "user", "content": new_user_message})

    # Aplicar sliding window: max window_size * 2 mensajes (humano + AI)
    max_messages = window_size * 2
    trimmed = list(messages_history)[-max_messages:]

    # Construir el payload completo
    payload = [{"role": "system", "content": system_prompt}] + trimmed

    response = client.chat.completions.create(
        model=model,
        messages=payload,
    )

    assistant_message = response.choices[0].message.content

    # Guardar la respuesta en el historial
    messages_history.append({"role": "assistant", "content": assistant_message})

    return assistant_message


# Uso
history: deque = deque(maxlen=20)  # maxlen como segunda línea de defensa
system = "Eres un asistente técnico especializado en APIs de pago."

r1 = sliding_window_chat(system, history, "¿Cuál es el límite de peticiones?")
r2 = sliding_window_chat(system, history, "¿Cómo calculo el coste mensual?")
print(f"Turno 1: {r1[:80]}...")
print(f"Turno 2: {r2[:80]}...")
print(f"Mensajes en ventana: {len(history)}")

Context rot: cuando más contexto empeora el output

Context rot es la degradación progresiva de la calidad de las respuestas de un LLM a medida que el contexto se acumula sin gestión. No es un término académico formal, sino un patrón de fallo reconocido por practitioners: el agente empieza a contradecirse, a ignorar instrucciones del system prompt o a generar respuestas que mezclan información de turnos distintos de forma incoherente.

El mecanismo es múltiple. Por un lado, el efecto Lost in the Middle: cuando el context window supera cierto umbral, la información en la zona central deja de influir proporcionalmente en el output. Las instrucciones críticas del system prompt, que estaban al inicio, siguen teniendo peso; el mensaje más reciente del usuario también. Pero el historial del turno 10 en una conversación de 40 turnos queda efectivamente eclipsado.

Por otro lado, el contexto acumulado introduce contradicciones semánticas. Si el usuario cambió de opinión sobre un requisito en el turno 5 y luego en el turno 15, ambas versiones coexisten en el historial. El modelo puede sintetizar una respuesta que intenta satisfacer ambas, que no satisface ninguna.

Los síntomas de context rot son reconocibles en producción:

• El agente empieza a ignorar restricciones del system prompt que seguía correctamente al inicio de la sesión.
• Las respuestas se vuelven más largas y menos precisas, mezclando información de distintos puntos de la conversación.
• El agente «olvida» el objetivo de la tarea y empieza a responder preguntas laterales.
• Aparecen alucinaciones que extraen hechos del historial de forma incorrecta.

La prevención del context rot es la motivación principal detrás de las estrategias de compresión y summarization. En los agentes de IA para empresas que construimos en Baigency, monitorizamos la longitud del contexto en cada turno y activamos summarization automática cuando el historial supera el 40% del context window disponible. Esta heurística conservadora mantiene el rendimiento estable incluso en sesiones largas.

La evaluación de agentes con LLM as judge es la herramienta más efectiva para detectar context rot en producción: un evaluador externo compara las respuestas del agente en los primeros turnos de una sesión con las de los turnos finales y detecta degradación sistemática.

Caching de contexto: prompt caching en Anthropic y OpenAI

El prompt caching es una funcionalidad de la API que permite reutilizar segmentos del context window que no cambian entre llamadas, evitando que el modelo los procese de nuevo y reduciendo significativamente el coste y la latencia. Es la optimización de context engineering con mayor impacto inmediato en producción.

Anthropic implementa el caching con un marcador explícito cache_control que el developer coloca en los bloques que quiere cachear. OpenAI lo hace de forma automática para prompts que comparten un prefijo idéntico de al menos 1.024 tokens. En ambos casos, el principio es el mismo: la parte estática del contexto (system prompt, definiciones de tools, documentación base) se computa una vez y se almacena en caché durante la sesión.

El beneficio cuantitativo según la documentación oficial de Anthropic es una reducción de hasta el 90% en el coste de los tokens cacheados y una reducción de latencia de hasta el 85% en los tokens de input. Para OpenAI, el descuento es del 50% en los tokens del prefijo cacheado.

import anthropic

client = anthropic.Anthropic()

# System prompt extenso que no cambia entre llamadas
SYSTEM_PROMPT = """
Eres un asistente especializado en derecho laboral español.
Tienes acceso a la siguiente documentación de referencia:

[... 3.000 tokens de documentación del Estatuto de los Trabajadores ...]

Reglas de comportamiento:
1. Siempre cita el artículo específico cuando respondas.
2. Si no encuentras base legal, indícalo explícitamente.
3. No des consejos que puedan interpretarse como asesoramiento legal vinculante.
"""

# Conversación multi-turno con caching del system prompt
conversation_history = []

def chat_with_caching(user_message: str) -> str:
    conversation_history.append({
        "role": "user",
        "content": user_message
    })

    response = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"}  # Cache este bloque
            }
        ],
        messages=conversation_history,
    )

    assistant_content = response.content[0].text
    conversation_history.append({
        "role": "assistant",
        "content": assistant_content
    })

    # Métricas de caching
    usage = response.usage
    cache_read = getattr(usage, "cache_read_input_tokens", 0)
    cache_created = getattr(usage, "cache_creation_input_tokens", 0)
    print(f"Tokens cacheados leídos: {cache_read} | Tokens creados en caché: {cache_created}")

    return assistant_content


# Primera llamada: crea el caché
r1 = chat_with_caching("¿Cuántos días de vacaciones tiene derecho un trabajador a jornada completa?")

# Segunda llamada: reutiliza el caché del system prompt
r2 = chat_with_caching("¿Y si lleva solo 6 meses en la empresa?")

print(r1[:100] + "...")
print(r2[:100] + "...")

La regla de diseño para maximizar el beneficio del caching es clara: coloca los bloques que más cambian al final del prompt. El system prompt, las definiciones de tools y la documentación base van primero (se cachean). El historial de la conversación y el mensaje del usuario actual van al final (varían en cada llamada y no se cachean). Esta ordenación es contraintuitiva si se piensa en el prompt como un texto que se lee de arriba a abajo, pero es la que maximiza el cache hit rate.

Implementación práctica con agentes

El siguiente ejemplo muestra un patrón completo de gestión de contexto para un agente de soporte técnico con memoria, RAG simplificado y detección de context overflow. Es el tipo de arquitectura que usamos en Baigency para los agentes de IA de clientes con volumen alto de conversaciones.

from openai import OpenAI
from collections import deque
from typing import Optional
import tiktoken

client = OpenAI()
encoder = tiktoken.encoding_for_model("gpt-4o")

SYSTEM_PROMPT = """Eres un agente de soporte técnico para una plataforma SaaS.
Respondes preguntas sobre configuración, facturación y errores comunes.
Citas siempre la fuente cuando recuperas documentación."""

MAX_CONTEXT_TOKENS = 8000   # Umbral conservador (model tiene 128K, pero coste importa)
WINDOW_SIZE = 8             # Turnos completos a mantener

def count_tokens(messages: list) -> int:
    """Cuenta tokens aproximados en la lista de mensajes."""
    total = 0
    for msg in messages:
        total += len(encoder.encode(msg.get("content", "")))
        total += 4  # overhead por mensaje
    return total

def get_relevant_docs(query: str) -> Optional[str]:
    """
    Simulación de RAG: en producción, aquí va la llamada al vector store.
    Devuelve None si no hay docs relevantes para no contaminar el contexto.
    """
    docs = {
        "limite": "Límite API Plan Pro: 1000 req/min. Plan Starter: 100 req/min.",
        "precio": "Plan Starter: 49€/mes. Pro: 199€/mes. Enterprise: desde 499€/mes.",
        "error 429": "Error 429 = rate limit superado. Implementar exponential backoff con base 2.",
    }
    for key, doc in docs.items():
        if key.lower() in query.lower():
            return f"[Documentación recuperada]\n{doc}"
    return None

def build_context(
    system: str,
    history: deque,
    user_message: str,
    retrieved_doc: Optional[str],
) -> list:
    """
    Construye el payload final con priorización:
    1. System prompt (máxima prioridad, va siempre)
    2. Historial reciente (sliding window)
    3. Doc RAG si existe (antes del mensaje del usuario)
    4. Mensaje actual del usuario
    """
    messages = [{"role": "system", "content": system}]
    messages += list(history)

    # Inyectar contexto RAG justo antes del mensaje del usuario
    if retrieved_doc:
        messages.append({"role": "system", "content": retrieved_doc})

    messages.append({"role": "user", "content": user_message})

    # Verificar overflow y advertir (en producción: activar summarization)
    total_tokens = count_tokens(messages)
    if total_tokens > MAX_CONTEXT_TOKENS:
        print(f"[WARNING] Context overflow: {total_tokens} tokens. Activar summarization.")

    return messages

def agent_turn(history: deque, user_input: str) -> str:
    doc = get_relevant_docs(user_input)
    payload = build_context(SYSTEM_PROMPT, history, user_input, doc)

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=payload,
        temperature=0.3,
    )

    answer = response.choices[0].message.content

    # Actualizar historial con sliding window
    history.append({"role": "user", "content": user_input})
    history.append({"role": "assistant", "content": answer})

    return answer


# Test del agente
history: deque = deque(maxlen=WINDOW_SIZE * 2)

print(agent_turn(history, "¿Cuál es el límite de peticiones en el plan Pro?"))
print(agent_turn(history, "Estoy recibiendo errores 429, ¿qué hago?"))
print(agent_turn(history, "¿Cuánto cuesta actualizar al plan Pro?"))
print(f"\nMensajes en ventana: {len(history)}")
print(f"Tokens actuales: {count_tokens(list(history))}")

Este patrón incorpora cuatro decisiones de context engineering: (1) el system prompt es estático y candidato a caching, (2) el historial se limita con sliding window antes de alcanzar el umbral, (3) el RAG solo inyecta documentación cuando hay match semántico (no siempre), y (4) el count de tokens se monitoriza en cada turno para activar la alarma de overflow antes de degradarse.

Para agentes con estado persistente y grafos de decisión complejos, el patrón se integra con LangGraph, que gestiona el estado del agente entre nodos y permite definir políticas de compresión de contexto en puntos específicos del grafo.

Preguntas frecuentes sobre context engineering

¿Context engineering y prompt engineering son lo mismo?

No son lo mismo. El prompt engineering se centra en redactar instrucciones efectivas dentro del system prompt: tono, formato, ejemplos few-shot, restricciones. El context engineering abarca todo lo que entra en el context window en cada llamada: no solo el system prompt, sino también las definiciones de tools, el historial conversacional, los documentos recuperados por RAG y la memoria comprimida de sesiones anteriores. Un buen prompt sin context engineering produce un agente que se degrada a los 20 turnos. Context engineering sin buen prompt produce un agente bien abastecido de información que da instrucciones confusas.

¿Qué es el context rot y cómo se detecta en producción?

El context rot es la degradación progresiva de la calidad de las respuestas conforme el historial conversacional crece sin compresión. Se detecta comparando métricas de calidad en los primeros turnos de una sesión versus los últimos: si el agente empieza a ignorar instrucciones del system prompt, a contradecirse o a mezclar información de turnos distintos, hay context rot. En producción, la forma más sistemática de detectarlo es con evaluación automatizada usando un LLM as judge que puntúa cada respuesta según criterios fijos y grafica la evolución por turno.

¿Cuándo usar summarization vs sliding window?

Usa sliding window cuando la continuidad a largo plazo no es crítica y la conversación tiene un arco corto (3-10 turnos típicos). Usa summarization cuando el agente gestiona tareas complejas donde el contexto de turnos anteriores importa para interpretar los mensajes actuales, como un asistente de proyecto que recuerda decisiones previas. En la práctica, la combinación más robusta es: summary de todo el historial antiguo + últimos K turnos completos. El summary ocupa 5-10x menos tokens que el historial completo equivalente con una pérdida de información mínima para tareas factuales.

¿El prompt caching funciona con modelos open source en local?

El prompt caching tal como lo implementan Anthropic y OpenAI es una funcionalidad de sus APIs de inferencia cloud: el servidor almacena el KV-cache del prefijo procesado. En inferencia local con Ollama o vLLM, el caching de KV-cache existe pero se gestiona a nivel de servidor de inferencia, no a nivel de API. Con vLLM en modo servidor, puedes habilitar prefix caching (--enable-prefix-caching) y obtienes un beneficio similar: el prefijo común entre llamadas se reutiliza sin recomputar. El savings en latencia es comparable; el savings en coste no aplica porque no hay facturación por token.

¿Cuántos tokens debería tener mi system prompt?

No existe un límite universal, pero la heurística práctica es: el system prompt no debería superar el 10-15% del context window disponible. En un modelo de 128K tokens, eso es 12.800-19.200 tokens máximo para el system prompt. En la práctica, la mayoría de agentes de producción funcionan bien con system prompts de 1.000-4.000 tokens. Si necesitas más, es una señal de que estás intentando poner en el system prompt información que debería venir de RAG (documentación) o de tool definitions (capacidades). La densidad informativa por token es más importante que la longitud absoluta.

¿Context engineering aplica solo a agentes conversacionales?

No. Las mismas técnicas aplican a cualquier sistema que use LLMs: pipelines de procesamiento de documentos, generación de código, sistemas de extracción de datos estructurados y agentes de automatización. En un pipeline de procesamiento de facturas, el context engineering determina qué fragmentos del documento se inyectan, en qué orden y con qué sistema de instrucciones para maximizar la precisión de extracción. En automatizaciones con IA, las mismas decisiones de priorización y compresión aplican a cada nodo del grafo de procesamiento. El principio es universal: siempre que haya un context window, hay un problema de context engineering.

Conclusión

El context engineering ha pasado de ser una optimización avanzada a ser un requisito básico para cualquier agente de IA que opere en producción con conversaciones de más de 5-10 turnos o con herramientas complejas. La diferencia entre un agente que se vende y uno que se mantiene durante meses sin degradarse es, en gran medida, la calidad de su gestión del contexto.

Los cuatro bloques que cubre esta guía —componentes del contexto, estrategias de compresión, context rot y prompt caching— son suficientes para construir un sistema sólido. El quinto bloque, la evaluación sistemática del comportamiento del agente a lo largo del tiempo, lo cubre nuestra guía sobre evaluación de agentes con LLM as judge.

Si estás construyendo un agente de IA para tu empresa o equipo y quieres una arquitectura que no se degrade en producción, el equipo de Baigency puede ayudarte a diseñar la estrategia de contexto correcta desde el inicio. Los problemas de context rot son significativamente más baratos de prevenir que de corregir una vez el sistema está en producción con usuarios reales.

También puedes explorar cómo los agentes de IA para ventas gestionan contextos complejos en conversaciones de múltiples sesiones, o cómo los agentes de voz con IA aplican sliding window en tiempo real para mantener la latencia de respuesta por debajo de los 800ms.

Por Diego Parada, founder de Baigency. Borrador generado con IA y revisado por Diego Parada (SME). Publicado: junio 2026.