Durante el año pasado, mientras construíamos Amazon Quick, nuestros agentes pasaron de responder preguntas a tomar medidas: programar reuniones, realizar investigaciones y generar informes. A medida que el sistema evolucionó, un problema siguió resurgiendo: no había una definición compartida de los primitivos a partir de los cuales se construye el trabajo agente. Las mismas ideas fueron reconstruidas una y otra vez bajo diferentes nombres: 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 filtró al diseño del producto y al usuario.
Tomemos como ejemplo al usuario que dice “monitorea mi canal de Slack y envíame un resumen diario”. ¿Se trata de un nuevo agente, una instrucción programada para uno existente, un flujo de trabajo o una habilidad? Son preguntas diferentes, pero sin un vocabulario compartido colapsan en una elección confusa.
Esta publicación comparte la taxonomía en la que convergimos: un conjunto de primitivos que se encuentran al descomponer el trabajo agente en cuatro preguntas sencillas: ¿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 debajo de él.
El marco de un vistazo
Figura 1: Cómo se relacionan los desencadenadores, los agentes y las capacidades, con el aprendizaje retroalimentación del tiempo de ejecución de la sesión
Un desencadenante inicia el trabajo y realiza la tarea (Cuándo y Qué), un agente la asume (Quién) y utiliza sus capacidades (herramientas, habilidades y flujos de trabajo) para realizar la tarea (Cómo). Esta publicación describe estos primitivos y cómo se relacionan entre sí. Es la primera publicación de una serie y las próximas publicaciones cubren nuestro sistema operativo agente, aprendizaje en segundo plano, fuentes proactivas y mucho más.
Desencadenantes: qué hace que comience el trabajo
Los desencadenantes son el mecanismo de activación para realizar el trabajo, pero también contienen instrucciones: un mensaje humano es a la vez el momento de activación y la descripción de qué hacer. Ambos son el ¿Cuándo? y el ¿Qué? de una tarea.
Iniciada por un ser humano: una persona abre una conversación y le pide al agente que haga algo. Interactivo, sincrónico, conversacional. Delegado por agente: un agente, a mitad de una tarea, invoca a otro para manejar un subproblema. Programático, componible y potencialmente recursivo. Programado: Activación basada en el tiempo, como “realizar una investigación financiera todos los lunes a las 9 a.m.”. Determinista, con las mismas instrucciones vigentes aplicadas en todas las ejecuciones. Basado en eventos: una señal de un sistema externo, como un nuevo correo electrónico, una mención de Slack, un cambio de archivo o un webhook.
El tipo de desencadenante condiciona la ejecución: una tarea en segundo plano programada puede ser conservadora (por ejemplo, no hacer nada si no está seguro), mientras que una iniciada por un humano respondería (por ejemplo, preguntar en lugar de detenerse).
Agentes
Definimos a un agente como un actor persistente y que aprende. ¿Es el quién? en cualquier ejecución, y el ancla contra la cual se acumula el aprendizaje. Dos agentes a los que se les da información idéntica pueden diferir, porque llevan instrucciones, capacidades e historias diferentes. El agente no son las instrucciones que sigue. Es la entidad la que los 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 financiero 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. Se puede agregar una biblioteca de gráficos en una sesión y eliminarla en la siguiente. Contexto aprendido: memoria que se acumula mediante el uso: las consultas que funcionan para una herramienta, el formato que prefieren los usuarios, los casos extremos que les interesan. Así es como la décima ejecución vence 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 conversaciones es un estado por sesión y los activadores 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 todas las mañanas” suele ser un disparador agregado a un agente existente, no a un nuevo agente o flujo de trabajo. Con este marco, podemos fusionar agentes de chat, programados y “autónomos” en un solo actor con el que se puede conversar, programar y que puede orquestar e inspeccionar su propio trabajo anterior.
Capacidades
Las capacidades son la forma en que actúa un agente, y abarcan un espectro que va desde lo totalmente agencial hasta lo totalmente determinista. Ese eje es en realidad un contrato de confianza: cuánta libertad mantiene el agente versus cuánto fija el usuario por adelantado.
Las herramientas son operaciones atómicas con un esquema escrito: enviar un correo electrónico, consultar una base de datos, leer un archivo. Ya sea una función local, un servidor de Protocolo de contexto modelo (MCP) u otro agente detrás de un límite de protocolo, la persona que llama ve la misma interfaz: nombre, descripción, parámetros, resultado.
Las habilidades son una guía estructurada con espacio para el juicio: instrucciones acompañadas de recursos (plantillas, guiones, 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 uno se vuelve relevante y luego lee las instrucciones completas. Por lo tanto, una habilidad puede agrupar una profundidad arbitraria de experiencia sin un costo constante.
Los flujos de trabajo son una coordinación determinista: pasos declarados, flujo de control, bifurcaciones y manejo de errores que se ejecutan en un orden fijo, con lógica de decisión en código en lugar de inferencia del modelo. Piense en una ruta de aprobación de compras: verificación del presupuesto, aprobación del gerente y luego finanzas, cada uno registrado. La ruta es fija, pero el juicio dentro de un paso sigue siendo del agente.
Figura 2: Habilidades versus 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 duran más que las mejoras del modelo
Surge una pregunta natural: si los modelos siguen mejorando, ¿no se volverán innecesarios las habilidades y los flujos de trabajo? No lo creemos, porque cada uno tiene un valor independiente de la capacidad del modelo. Las habilidades son la unidad para capturar, versionar y compartir experiencia institucional, mientras que los flujos de trabajo brindan auditabilidad, visibilidad paso a paso y coordinación determinista de múltiples servicios. Tampoco son fijos: una habilidad bien comprendida puede convertirse en un flujo de trabajo (cristalización), un flujo de trabajo que sigue llegando a casos extremos puede volver a convertirse en una habilidad (disolución). Esto se hace en Quick a través de nuestro marco de aprendizaje continuo, que describiremos en una publicación futura.
Qué significa esto en la práctica
Vuelve a “supervisar mi canal de Slack y enviarme un resumen diario”. Debido a que estas primitivas se componen, la misma solicitud se puede atender de varias maneras válidas:
Una tarea programada con una instrucción de una sola línea, dejando que el agente se encargue del 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.
Los tres producen un resumen diario según un cronograma. Lo que difiere es el contrato de confianza. Un usuario que confía en el agente quiere lo primero, uno quemado por la inconsistencia el segundo, uno que ejecuta un proceso sensible al cumplimiento el tercero.
El aprendizaje cambia esa trayectoria con el tiempo. Una tarea que comienza con una oración (“revisar mi correo electrónico para ver si hay elementos urgentes”) acumula aprendizajes relacionados con el dominio: consultas efectivas, formato preferido y qué remitentes son importantes. La décima ejecución es notablemente mejor, ya que nadie la codifica a mano. El diseño correcto es la opción más sencilla que satisface el requisito de confianza del usuario, con un camino para graduarse a través del aprendizaje autónomo cuando necesite más.
Conclusión
El valor de esta taxonomía primitiva de agencia es que cuatro preguntas sencillas, cuándo, qué, quién y cómo, son suficientes para realizar cualquier trabajo de agencia, desde una solicitud de chat de una sola línea hasta un proceso programado con grado de cumplimiento. Compartir un vocabulario permite a los constructores razonar sobre el sistema y permite que el producto oculte la complejidad. Lo mejor de todo es que el usuario nunca tiene que aprender nada de esto. Dicen lo que quieren y el sistema reúne las primitivas apropiadas para hacer su trabajo.
El siguiente en la serie: el sistema operativo agente que se basa en estos primitivos y potencia Amazon Quick.
Sigue explorando
Sobre los autores
Thomas Delteil
Adi Kalyanpur