Líderes de opinión
Los agentes siempre son contrataciones de primer día. Es hora de diseñar para ello.

Para 2027, 74% de las empresas se espera que utilicen agentes en alguna capacidad, según un estudio reciente de Deloitte. Durante años, hemos diseñado y construido software para mejorar la experiencia humana al navegar por nuestras aplicaciones, sitios web, sistemas operativos y documentos. Ahora, el usuario ya no es un ser humano. Esto tiene implicaciones más amplias más allá de pasar de los paneles de control y los flujos de trabajo controlados que diseñamos para tareas humanas. Estamos en un momento en que necesitamos diseñar los entornos operativos de los agentes, mientras también diseñamos flujos de trabajo humanos para guiar eficazmente la experiencia del agente dentro de estos entornos.
Todavía estamos en una fase temprana de aprendizaje sobre lo que los agentes realmente necesitan de nosotros para ser repetiblemente exitosos y fiables. El instinto es tratar la integración del agente como un problema puramente de prompts o de interfaz de usuario. Diseñar un entorno de ejecución bien gobernado es un terreno nuevo para nosotros como cultura. Sin embargo, los principios subyacentes de buen diseño y buena gestión no han cambiado: les debemos a los agentes un contexto claro, una dirección inequívoca y una intención explícita.
Context: Por qué la codificación vino primero
El contexto es, probablemente, la entrada más importante si queremos que los agentes entreguen de forma repetible el nivel que pretendemos. El desarrollo de software registra más contexto que casi cualquier otro campo: repositorios, esquemas de API, relaciones entre sistemas, revisiones de código y discusiones de la comunidad. Así que tiene sentido que los laboratorios de frontera de IA comenzaran con la codificación. Es uno de los pocos dominios donde ya está escrito una buena parte del contexto.
Pero, como cualquier nuevo integrante de un equipo de software dirá, incluso con todos esos datos, los agentes seguirán careciendo de la memoria institucional incrustada en las reglas no escritas que nadie documentó. Esa brecha es generalizada: 43% de los desarrolladores están preocupados de que las herramientas de IA carezcan de suficiente contexto sobre su proyecto o base de código específica. El conocimiento tácito abarca desde convenciones cotidianas, como bibliotecas preferidas para tareas específicas, hasta “fantasmas” operacionales de alto riesgo: un hotfix nocturno que perdura para siempre, o una columna de base de datos aparentemente vacía que sustenta secretamente un informe de ingresos personalizado. Este contexto vive en la cabeza de un ingeniero senior, en un hilo reciente de Slack, o en ninguna parte. Rara vez está en el propio código fuente.
Si esto es cierto en el software, uno de los campos mejor documentados, es fácil ver por qué los agentes tienen dificultades para rendir eficazmente desde el primer día en muchas otras industrias. En salud y derecho, gran parte del conocimiento institucional que moldea el trabajo diario se aprende e internaliza. Vive en la experiencia de las personas más que en documentación formal. Un agente legal puede no conocer la estructura, tono o argumentación preferida por un socio concreto para un informe, mientras que un agente de salud puede no entender los flujos de trabajo locales y las prácticas de escalamiento que una clínica ocupada utiliza para apoyar la triaje liderada por clínicos. La documentación por sí sola no puede cerrar esa brecha, porque el desafío no es simplemente el acceso a la información; es la transferencia del contexto. Para dar a los agentes lo que necesitan para triunfar, debemos incorporarlos de la misma manera que incorporaríamos a un nuevo empleado.
Direction: Por qué la ósmosis no funciona
Incorporar a un nuevo compañero requiere más que proporcionar los materiales y el acceso adecuados. Cuando invertimos en el éxito de los que nos rodean, ofrecemos una dirección sólida sobre qué hacer con los nuevos materiales y el acceso: expectativas, claridad sobre lo que intentamos lograr y retroalimentación a lo largo del proceso. Yo aplico esta misma mentalidad al diseñar para agentes. Doy una dirección clara y específica (relativa a la tarea en cuestión). Eso se mantiene para cualquier compañero, sin importar su antigüedad. Sin embargo, en un escenario de nueva contratación, la dirección debe ir más allá, porque aún no poseen ningún contexto institucional.
Piense en un agente como una nueva contratación que nunca deja de ser nueva. Es entusiasta y capaz (y, francamente, tiene energía ilimitada), pero no puede captar y retener tantas reglas no escritas como lo hace una persona con el tiempo. Los humanos aprenden por ósmosis y experiencia, mientras que los agentes aprenden de una arquitectura construida explícitamente en su entorno de trabajo.
Con una nueva contratación, puede cerrar esa brecha con el tiempo mediante preguntas, retroalimentación y nuevas ideas que vaya adquiriendo sobre los procesos y preferencias de la organización. Charlas literales junto a la máquina de café o almuerzos de equipo. Con un agente, tiene que construir ese cierre de brecha dentro del propio diseño. Esto puede incluir:
- Proporcionar al agente una ventana de contexto estructurada que separe reglas duraderas, hechos específicos de la tarea y el historial relevante, en lugar de arrojarle una pila de documentos.
- Definir sus permisos y límites de decisión desde el principio: lo que puede hacer de forma independiente, lo que requiere aprobación y lo que nunca debe acceder.
- Incorporar algunos ejemplos concretos de resultados de alta calidad directamente en la experiencia, de modo que el agente tenga un modelo claro de cómo debe realizarse el trabajo.
- Compartir los callejones sin salida anteriores que haya encontrado.
Diseñar un entorno de agente bien gobernado no se trata de facilitar el trabajo al modelo. Se trata de proteger al equipo de ingeniería humano de deudas técnicas invisibles. Pero incluso un agente bien dirigido puede seguir instrucciones a la perfección y aun así perder el objetivo. La dirección le dice qué hacer, pero no le muestra cómo se ve “lo bueno”. Esa brecha es donde entra la intención.
Intent: Por qué los agentes se desvían al medio
Es importante recordar que los agentes son máquinas de coincidencia de patrones, entrenadas con enormes cantidades de conocimiento y naturalmente inclinadas a ofrecer el promedio estadístico. Sin una intención clara y explícita, ese resultado promedio es exactamente lo que un agente devolverá. Pida a un agente que “añada un punto de acceso de autenticación de usuario” y generará una ruta Express de libro de texto con hash de contraseña básico. Funciona, pero ignora por completo el servicio de autenticación personalizado de su equipo, omite la telemetría requerida y rompe el formato de error estandarizado. Es una característica adecuada en papel, pero según el contexto, es un error arquitectónico en la práctica. La facilidad con la que se introducen “bugs” como este no puede subestimarse.
Para evitarlo, la dirección debe combinarse con verificación activa de intención y registro. Las barreras de seguridad no deben limitarse a comprobar si el código compila, aunque eso sea importante. Las barreras deben imponer explícitamente los estándares opinados, reglas de casos límite y el contexto del dominio que elevan la salida genérica a un trabajo listo para producción. El registro es importante como indicador de estado del sistema para nosotros, los humanos. Esta trazabilidad es crítica para la confianza.
En las interacciones humanas hay mucho espacio para la incertidumbre. Alguien puede compartir una primera versión con usted y, juntos, pueden discutir qué es sólido y qué necesita mejora. Esto funciona porque no esperamos que nuestros compañeros humanos sean máquinas autónomas. Para capturar verdaderamente el poder y la promesa de los compañeros agenticos (a quienes sí necesitamos que operen más autónomamente…), podemos diseñar muchas de estas verificaciones direccionales. El intercambio sigue siendo necesario, pero no puede recaer totalmente en el esfuerzo manual. Al cargar de antemano criterios de aceptación claros y reglas de verificación, permite que el agente ejecute sus propios bucles de retroalimentación internos. Diseñar para la prevención de errores es otro principio sólido de UX que podemos aplicar en este nuevo mundo: dar a los agentes la capacidad de señalar baja confianza antes de comprometerse con una acción, en lugar de predeterminar silenciosamente la mejor conjetura.
Where the Metaphor Breaks
El marco de la nueva contratación funciona, hasta que no lo hace. Con una contratación humana, la experiencia genera competencia, lo que genera juicio. Observar a su nuevo empleado internalizar el “por qué” detrás del contexto y la dirección es lo que construye confianza con el tiempo, y en general, esto es acumulativo. Un agente no tiene dónde acumular y almacenar esa experiencia.
La primera semana y la centésima semana de una nueva contratación se ven diferentes. La primera tarea y la milésima de un agente son idénticas, a menos que diseñe y construya algo que las haga diferentes. Este es nuestro nuevo desafío de diseño.
Agent Responsibility Hinges on Design
Si la responsabilidad no puede vivir en el agente, debe vivir en la estructura que lo rodea. Se reduce a las mismas tres preguntas que haría antes de asignar trabajo a cualquier nueva contratación: ¿Qué contexto tiene? ¿Qué dirección le he dado? ¿Cuál es mi intención real?
La próxima vez que asigne una tarea a un agente, no se limite a revisar el resultado. Primero revise sus propios insumos. ¿Le dio el contexto que una nueva contratación necesitaría el primer día? ¿Fue su dirección lo suficientemente específica como para sobrevivir a una interpretación literal? ¿Fue su intención lo suficientemente clara para que “la respuesta media” no fuera lo mejor que podía hacer?
Con esta guía clara en mano (¿en bytes?), ocurre algo interesante: un agente no necesita una larga pista de despegue para volverse confiable. El contexto, la dirección y la verificación que construya desde el principio definen cómo opera en cada tarea. Una nueva contratación gana su confianza con el tiempo; un agente debe ganarla cada vez a través del sistema que diseñó. La responsabilidad no es algo en lo que crece, está incorporada desde el inicio. La pregunta no es cuándo su agente estará listo para más responsabilidad. Es si lo diseñó para ganar esa responsabilidad en cada tarea individual.












