Segundo artículo de la serie sobre el blueprint de agentes de comercio de Anthropic. El primero, qué publicaron y qué significa para una empresa en LATAM, es el contexto. Este es sobre las decisiones de diseño.
Hay una propuesta técnica que vas a recibir, casi con seguridad, cuando pidas un agente de compras para tu tienda. La vas a recibir de un proveedor o de tu propio equipo, y va a tener un diagrama con cajas: un "orquestador" arriba, y debajo un agente de búsqueda, un agente de carrito, un agente de servicio al cliente, un agente de recomendaciones. Cada uno especializado. Suena ordenado, suena escalable, y es exactamente lo que Anthropic, con datos de sus clientes enterprise, dice que no hay que hacer.
Este artículo es sobre esa y otras cuatro decisiones de diseño que separan un piloto vistoso de un producto que funciona. No hace falta saber programar para entenderlas. Sí hace falta entenderlas para no aprobar la propuesta equivocada.
Un modelo, un loop, muchas skills
La arquitectura que propone el manual es casi decepcionante de simple: un solo modelo, en un ciclo estándar de "razona, usa una herramienta, mira el resultado, repite". No hay enrutador de intenciones que decida a qué agente mandar la pregunta. No hay subagentes especializados. Hay un agente que lo hace todo y que carga instrucciones adicionales, llamadas skills, cuando la conversación las necesita.
La razón es práctica, no filosófica. Una conversación de compra real cruza intenciones todo el tiempo: "busco un regalo para mi mamá, algo de cocina, ¿este llega antes del domingo?, ¿y si lo pago en cuotas?, ah, y quiero cambiar la dirección de entrega del pedido anterior". Con subagentes, cada cambio de tema es una transferencia: se pierde contexto, se pagan tokens dos veces y se suma latencia. Con un solo agente y skills, el contexto es compartido y el modelo simplemente carga la instrucción que le falta.
Anthropic reserva los subagentes para un caso concreto: tareas estrechas, autocontenidas y que no necesitan el hilo de la conversación. Una investigación profunda de mercado para el agente del comerciante, por ejemplo. Todo lo demás, en un solo agente.
Lo que significa para ti como decisor: si la propuesta que te presentan tiene más de dos o tres "agentes" en el diagrama, pregunta por qué. La respuesta honesta suele ser "porque así se organizan los equipos", no "porque así funciona mejor". Son cosas distintas.
La regla del 33%
Si todo va en un solo agente, ¿cómo se decide qué instrucciones tiene siempre a la vista y cuáles carga bajo demanda? El manual da una regla concreta que me pareció de las ideas más útiles del documento: lo que se usa en más de un tercio de las conversaciones va en el prompt principal. Todo lo demás va en skills.
Para una tienda típica, eso pone en el prompt principal la búsqueda, el carrito y el checkout, que aparecen en casi toda conversación. Y deja como skills el descubrimiento guiado ("no sé qué regalar"), la investigación de producto, la planificación de un viaje o un evento, el servicio al cliente y la personalización.
Hay una excepción que no se negocia: las instrucciones de seguridad, las restricciones legales y las reglas de marca van siempre en el prompt principal, sin importar con qué frecuencia se usen. No se puede "olvidar" cargar la regla de no vender alcohol a menores porque la conversación empezó hablando de cocina.
La regla importa por dos razones que se van a repetir en este artículo: costo y calidad. Cada instrucción en el prompt principal se paga en cada turno de cada conversación. Y un prompt sobrecargado hace que el modelo siga peor las instrucciones que sí importan.
El agente no reemplaza tu buscador, lo usa
La tercera decisión es la que más tranquiliza a quien ya invirtió en su plataforma. El agente no trae su propio buscador, su propio catálogo ni su propio motor de recomendaciones. Llama a los que ya tienes. Tu buscador devuelve resultados rankeados; el agente decide cuáles mostrar y cómo explicarlos. Tu sistema de inventario dice qué hay; el agente no promete lo que no está.
Esto tiene una consecuencia incómoda que ya mencioné en el primer artículo y que vale repetir: la calidad del agente está acotada por la calidad de tus sistemas. Un buscador que no encuentra "tenis" cuando el catálogo dice "zapatillas deportivas" va a producir un agente que tampoco los encuentra, solo que ahora con una explicación muy elocuente de por qué no hay resultados.
El manual agrega un detalle de diseño que parece menor y no lo es: las herramientas deben devolver solo los campos que el modelo necesita para razonar, y cuando algo falla, deben explicarlo en lenguaje claro en lugar de un código de error. "No hay stock en tu ciudad, pero sí en la tienda de al lado con entrega en 2 días" es una respuesta con la que el agente puede hacer algo. "Error 409" no.
Cada componente visual es una herramienta
Esta es la decisión más técnica de las cinco, y la que más protege al cliente. En el blueprint, el agente no escribe una lista de productos en texto y espera que la interfaz la dibuje bonito. Cada elemento visual (el carrusel de productos, el comparador, el itinerario de viaje, el mapa de asientos) es una herramienta con formato estricto que el modelo invoca con datos estructurados.
¿Por qué importa? Porque cuando el modelo escribe texto libre, puede escribir cualquier cosa. Un precio que no existe. Un producto que no está en el catálogo. Un descuento inventado. Cuando la única forma de mostrar un producto es a través de una herramienta que exige un identificador válido y un precio que viene del backend, el modelo simplemente no puede mostrar lo que no existe. La alucinación no se previene con un prompt que dice "no inventes precios". Se previene con un diseño donde inventar es imposible.
Hay un beneficio secundario que el manual señala: el historial de la conversación queda guardado en formato estructurado, así que cuando el cliente dice "el primero que me mostraste", el agente sabe exactamente cuál fue.
Latencia y costo, en lenguaje de negocio
Las dos objeciones que matan pilotos de agentes son "es lento" y "es caro". El manual dedica una sección entera a cada una, y las respuestas se resumen en tres ideas.
Menos vueltas. La latencia de un agente es, sobre todo, cuántas veces tiene que ir y volver entre razonar y consultar herramientas. Se reduce cargando de entrada el contexto probable (si el cliente abrió el chat desde la página de un producto, ese producto ya está en contexto), llamando herramientas independientes en paralelo, y con un hallazgo contraintuitivo: a veces el modelo más inteligente es más rápido, porque planea mejor qué herramientas necesita y da menos vueltas. Anthropic lo vio especialmente en los casos lentos, los que definen la experiencia de los clientes más impacientes.
Mostrar el trabajo. Un spinner de cinco segundos se siente eterno. Una línea que dice "buscando hoteles en Cartagena" seguida de "comparando precios" se siente como progreso. Es la misma espera. La percepción es distinta.
Caché de prompt. Esta es la que decide si el proyecto es viable económicamente. Los modelos cobran mucho menos por releer texto que ya procesaron (del orden de una décima parte). El manual describe cómo estructurar el prompt en tres capas (lo global, lo de la sesión, lo volátil) para que entre 90% y 99% de lo que el modelo lee en cada turno venga de caché. La diferencia entre un agente diseñado así y uno que no lo está puede ser un orden de magnitud en la factura mensual.
Dato clave: Anthropic recomienda elegir el modelo con una batería de evaluaciones, no con intuición. Su punto de partida: el modelo más capaz para el agente del comerciante, donde el análisis pesa más que la velocidad, y un modelo más rápido para el agente de compras, donde cada segundo cuenta. Pero la recomendación explícita es medir con tu tráfico, no copiar la de ellos.
Cinco señales de alerta al evaluar una propuesta
Con todo lo anterior, esto es lo que yo miraría en una propuesta técnica, de un proveedor o del equipo interno, sin necesidad de leer una línea de código:
- Muchos agentes en el diagrama. Más de tres cajas con la palabra "agente" es una arquitectura que va a costar el doble y responder más lento. Pregunta por qué no es una sola.
- "Vamos a construir nuestro propio buscador/catálogo para el agente". Eso es un proyecto de plataforma disfrazado de proyecto de IA. Si el buscador actual es malo, arréglalo para todos, no solo para el agente.
- El agente "escribe" los productos que muestra. Si la respuesta a "¿cómo evitan que invente precios?" es "le decimos en el prompt que no lo haga", no hay diseño de seguridad. Hay esperanza.
- No hay plan de caché. Pide una estimación de costo por conversación y pregunta qué porcentaje viene de caché. Si nadie sabe, la estimación está mal por un orden de magnitud.
- Eligieron el modelo por nombre. "Usamos el mejor modelo" o "usamos el más barato" sin una evaluación con tus casos reales es una decisión sin datos. Y es una de las pocas decisiones baratas de revertir, si se diseñó para eso.
Conclusión
Lo que más me gusta del manual es que casi todas sus decisiones van en contra del instinto de "más": más agentes, más instrucciones, más sistemas nuevos, más modelo. La arquitectura que funciona es más simple de lo que uno esperaría, y esa simplicidad es la que hace que el costo y la latencia cierren.
El manual cierra con una idea que vale para cualquier proyecto de IA, no solo comercio: la arquitectura no depende del modelo. Cuando salga uno mejor, cambiarlo es un ajuste de configuración y una corrida de evaluaciones. Todo lo demás (herramientas, skills, evaluaciones) se conserva. Eso es lo que separa una inversión de un experimento.
En el tercer artículo de la serie entro en la parte que a mí, viniendo de pagos, más me importa: cómo el agente no mueve dinero sin aprobación, qué hace con los datos del cliente, y qué hay que tener listo antes de salir a producción.
¿Listo para llevar la IA a tu equipo?
Agenda una llamada gratuita de 30 minutos y te mostramos cómo podemos ayudarte a adoptar IA de forma estratégica y efectiva.
Agendar llamada gratuita
