Durante el último año, mientras construíamos Amazon Quick, nuestros agentes pasaron de responder preguntas a realizar acciones: programar reuniones, ejecutar investigaciones, generar informes. A medida que el sistema evolucionaba, un problema seguía resurgiendo: no existía una definición compartida de las primitivas a partir de las cuales se construye el trabajo agéntico. Las mismas pocas ideas seguían reconstruyéndose bajo nombres diferentes: un actor que hace el trabajo, una señal que lo inicia, un procedimiento empaquetado y una memoria que lleva las lecciones hacia adelante. Esta repetición se filtraba en el diseño del producto y llegaba al usuario.
Tomemos al usuario que dice «monitoriza mi canal de Slack y envíame un resumen diario». ¿Eso es un nuevo agente, una instrucción programada a uno existente, un flujo de trabajo o una habilidad? Son preguntas distintas, pero sin un vocabulario compartido se colapsan en una sola elección confusa.
Esta publicación comparte la taxonomía en la que convergimos: un conjunto de primitivas hallado al descomponer el trabajo agéntico en cuatro preguntas simples: ¿Cuándo?, ¿Qué?, ¿Quién?y ¿Cómo? La mayor parte del marco permanece invisible para los usuarios finales por diseño, pero un vocabulario compartido hace que el sistema sea más fácil de razonar para cualquiera que construya por debajo de él.
El marco de un vistazo
Figura 1: Cómo se relacionan los desencadenantes, los agentes y las capacidades, con el aprendizaje retroalimentando desde el runtime de sesión
Un desencadenante inicia el trabajo y porta la tarea (Cuándo y Qué), un agente la asume (Quién) y usa sus capacidades (herramientas, habilidades y flujos de trabajo) para realizar la tarea (Cómo). Esta publicación describe estas primitivas y cómo se relacionan entre sí. Es la primera publicación de una serie, y las próximas publicaciones cubrirán nuestro sistema operativo agéntico, el aprendizaje en segundo plano, los feeds proactivos y mucho más.
Desencadenantes: qué hace que el trabajo comience
Los disparadores son el mecanismo de activación para realizar el trabajo, pero también contienen instrucciones: un mensaje humano es tanto el momento de activación como la descripción de lo que hay que hacer. Son tanto el ¿Cuándo? como el ¿Qué? de una tarea.
- Iniciado por humanos: Una persona abre una conversación y le pide al agente que haga algo. Interactivo, síncrono, conversacional.
- Delegado por agente: Un agente, a mitad de una tarea, invoca a otro para resolver un subproblema. Programático, componible, potencialmente recursivo.
- Programado: Activación basada en el tiempo, como «ejecutar investigación financiera todos los lunes a las 9am». Determinista, con las mismas instrucciones permanentes aplicadas en cada ejecución.
- Dirigido por eventos: Una señal de un sistema externo, como un correo electrónico nuevo, una mención en Slack, un cambio en un archivo o un webhook.
El tipo de disparador condiciona la ejecución: una tarea programada en segundo plano puede mantenerse conservadora (por ejemplo, no hacer nada si hay incertidumbre), mientras que una iniciada por humanos sería receptiva (por ejemplo, preguntar en lugar de detenerse).
Agentes
Definimos un agente como un actor persistente que aprende. Es el ¿Quién? en cualquier ejecución, y el ancla contra la cual se acumula el aprendizaje. Dos agentes con entradas idénticas pueden diferir, porque llevan consigo instrucciones, capacidades e historiales distintos. El agente no son las instrucciones que sigue. Es la entidad que las interpreta. Consta de tres cosas:
- Instrucciones: Orientación permanente que define la persona, el rol, los archivos de contexto y los principios operativos. Un Agente de Finanzas se comporta de manera diferente a un asistente general principalmente por esto.
- Capacidades: Las herramientas, habilidades, flujos de trabajo y subagentes disponibles para su uso, actualizados dinámicamente. Una biblioteca de gráficos puede añadirse en una sesión y eliminarse en la siguiente.
- Contexto aprendido: Memoria que se acumula con el uso: las consultas que funcionan para una herramienta, el formato que prefieren los usuarios, los casos límite que les interesan. Así es como la décima ejecución supera a la primera sin que nadie cambie las instrucciones.
Todo lo demás es extrínseco: el modelo de lenguaje grande (LLM) subyacente al agente es un parámetro de modelo intercambiable, el historial de conversación es un estado por sesión, y los disparadores pertenecen a la plataforma.
Una consecuencia de esta definición es que la solicitud de un usuario «Quiero un agente que monitoree mi Slack y envíe un resumen cada mañana» suele ser un disparador añadido a un agente existente, no un nuevo agente o flujo de trabajo. Con este planteamiento, podemos fusionar los agentes de chat, programados y «autónomos» en un solo actor con el que puedes conversar, programar y que puede orquestar e inspeccionar su propio trabajo pasado.
Capacidades
Las capacidades son Cómo actúa un agente, abarcando un espectro desde totalmente agéntico hasta totalmente determinista. Ese eje es en realidad un contrato de confianza: cuánta libertad conserva el agente frente a cuánta fija el usuario de antemano.
Las herramientas son operaciones atómicas con un esquema tipado: enviar un correo, consultar una base de datos, leer un archivo. Ya sea una función local, un servidor de Model Context Protocol (MCP) u otro agente detrás de un límite de protocolo, quien invoca ve la misma interfaz: nombre, descripción, parámetros, resultado.
Las habilidades son una guía estructurada con margen para el criterio: instrucciones empaquetadas con recursos (plantillas, scripts, ejemplos) que describen un enfoque en lugar de una secuencia rígida. Se cargan mediante divulgación progresiva, de modo que el agente solo ve nombres y descripciones breves hasta que una se vuelve relevante, y entonces lee las instrucciones completas. Una habilidad puede, por tanto, empaquetar conocimiento experto de profundidad arbitraria sin un costo constante.
Los flujos de trabajo son coordinación determinista: pasos declarados, flujo de control, ramificaciones y manejo de errores que se ejecutan en un orden fijo, con la lógica de decisión en código en lugar de en la inferencia del modelo. Piense en una ruta de aprobación de compras: verificación de presupuesto, visto bueno del gerente y luego finanzas, todo registrado. La ruta es fija, pero el criterio dentro de un paso sigue siendo del agente.
Figura 2: Habilidades frente a flujos de trabajo, que difieren en si el agente o el código decide el orden de los pasos
Por qué las habilidades y los flujos de trabajo perduran más allá de las mejoras de los modelos
Surge una pregunta natural: si los modelos siguen mejorando, ¿no se volverán innecesarias las habilidades y los flujos de trabajo? No lo creemos, porque cada uno aporta valor independiente de la capacidad del modelo. Las habilidades son la unidad para capturar, versionar y compartir la experiencia institucional, mientras que los flujos de trabajo ofrecen auditabilidad, visibilidad paso a paso y coordinación determinista entre múltiples servicios. Tampoco son fijos: una habilidad bien comprendida puede consolidarse en un flujo de trabajo (cristalización), y un flujo de trabajo que sigue encontrando casos límite puede relajarse de nuevo en una habilidad (disolución). Esto se hace en Quick mediante nuestro marco de aprendizaje continuo, que describiremos en una publicación futura.
Qué significa esto en la práctica
Volvamos a “monitorea mi canal de Slack y envíame un resumen diario”. Como estos primitivos son componibles, la misma solicitud puede satisfacerse de varias formas válidas:
- Una tarea programada con una instrucción de una sola línea, dejando que el agente resuelva el resto.
- La misma tarea respaldada por una habilidad con reglas de formato explícitas y prioridades de canales.
- La misma tarea que invoca un flujo de trabajo con pasos deterministas y manejo de errores.
Las tres producen un resumen diario de forma programada. Lo que difiere es el contrato de confianza. Un usuario que confía en el agente quiere la primera; uno quemado por la inconsistencia, la segunda; uno que ejecuta un proceso sensible al cumplimiento, la tercera.
El aprendizaje desplaza esa trayectoria con el tiempo. Una tarea que comienza como una frase (“revisa mi correo en busca de asuntos urgentes”) acumula aprendizajes vinculados al dominio: consultas efectivas, formato preferido y qué remitentes importan. La décima ejecución es notablemente mejor, sin que nadie lo codifique a mano. El diseño correcto es la opción más simple que cumple el requisito de confianza del usuario, con una ruta para graduarse mediante aprendizaje autónomo cuando necesite más.
Conclusión
El valor de esta taxonomía de primitivos agénticos es que cuatro preguntas sencillas, Cuándo, Qué, Quiény Cómo, son suficientes para ubicar cualquier trabajo agéntico, desde una solicitud de chat de una línea hasta un proceso programado de nivel de cumplimiento. Compartir un mismo vocabulario permite a los creadores razonar sobre el sistema y permite al producto ocultar la complejidad. Lo mejor de todo es que el usuario nunca tiene que aprender nada de esto. Dicen lo que quieren y el sistema ensambla los primitivos apropiados para hacer su trabajo.
Lo próximo en la serie: el sistema operativo agéntico que se construye sobre estos primitivos y potencia Amazon Quick.
Sigue explorando
- ¿Listo para probar? Empieza con la guía de introducción de Amazon Quick.