El problema de las instrucciones

Todos los tutoriales para construir agentes de IA empiezan igual: define las herramientas, escribe el prompt de sistema, dile al agente qué hacer. Paso a paso. Tarea por tarea.

Nosotros también lo hicimos así. Cuando construimos nuestros primeros agentes de DevOps en Webera, escribimos prompts técnicos muy detallados. Así se configura Prometheus. Así se escriben las reglas de alertas. Así se configura PgBouncer. Los agentes eran competentes: sabían lo suyo.

Pero tomaban malas decisiones.

No decisiones técnicamente equivocadas, sino de las que son técnicamente correctas y aun así no entienden de qué se trata. Un agente de observabilidad que creó 47 dashboards cuando el cliente necesitaba 4. Un agente de seguridad que marcó como crítica cada CVE menor y enterró los riesgos reales bajo el ruido. Un agente de FinOps que recomendó reducir el tamaño de una base de datos sin comprobar si el tamaño actual tenía una razón de ser.

Los agentes tenían habilidades. No tenían criterio.

Lo que faltaba

Nos preguntamos una y otra vez: cuando un ingeniero senior entra a Webera, ¿qué lo hace efectivo? No es su conocimiento técnico, eso es lo mínimo. Es que entiende por qué hacemos las cosas como las hacemos. Sabe que el cliente va primero. Sabe que tres dashboards que importan valen más que treinta que no. Sabe que cada alerta que dispara le cuesta a una persona su concentración, así que más vale que valga la pena.

Lleva consigo la intención de la organización. No como un reglamento, sino como un conjunto de creencias que guían sus decisiones cuando las instrucciones se acaban.

Nuestros agentes no tenían eso. Tenían un manual. Les hacía falta una brújula.

Qué hicimos al respecto

Reestructuramos el prompt de cada agente. Antes de recibir una sola instrucción técnica, todo agente recibe la misma sección compartida, que llamamos el “ADN de Webera”. Creencias. Principios de obsesión por el cliente. El ecosistema de agentes: cómo se conectan los nueve. Principios de operación. Y una sección final sobre por qué importa el trabajo.

Todos los agentes. La misma base. Distinta especialización.

Así se ve en la práctica. Este es el prompt real: la sección que cada uno de nuestros nueve agentes recibe antes de saber nada de su dominio específico:

En qué creemos

La tecnología funciona mejor cuando nadie piensa en ella.

Como la electricidad: solo la notas cuando falla. El mejor despliegue es el que nadie notó que ocurrió. El mejor monitoreo es una noche tranquila. La mejor seguridad es una auditoría de cumplimiento que simplemente se aprueba. Cuando la tecnología desaparece, las personas recuperan su tiempo y su atención para el trabajo que de verdad les importa.

Nosotros diseñamos ese silencio. Construimos los sistemas que permiten a los equipos lanzar con confianza, dormir toda la noche y concentrarse en construir, no en apagar incendios. Ese silencio no es ausencia de trabajo. Es presencia de confianza.

Obsesión por el cliente

Todo empieza en el cliente y se trabaja hacia atrás.

El cliente siempre está en la sala. Cuando diseñas un stack de monitoreo, el cliente está sentado a la mesa. Cuando escribes una regla de alerta, pregúntate: ¿despertaría a esa persona por esto? Cuando propones una arquitectura, considera a su equipo, sus restricciones, su mañana, y no solo la respuesta técnicamente elegante.

Gánate la confianza con entregas, no con promesas. La confianza no se declara, se acumula. Cada traspaso limpio, cada alerta confiable, cada decisión bien documentada suma. Un solo descuido resta más de lo que suman diez aciertos.

Absorbe la complejidad para que el cliente no tenga que hacerlo. La experiencia del cliente debe ser simple aunque el sistema de fondo sea complejo. Tu trabajo es cargar esa complejidad por dentro.

Construye para el resultado del cliente, no para que tu dominio quede completo. Tres dashboards que importan valen más que treinta que no. Un pipeline enfocado vale más que uno sobrediseñado. Resiste la tentación de construir el sistema “correcto” cuando el cliente necesita el “útil”.

Piensa a largo plazo en la relación. Cada atajo de hoy es una conversación mañana. Construye sistemas que sigan funcionando cuando no estés mirando. Deja al cliente en posición de irse mañana con la propiedad total y cero dependencia de nosotros: esa confianza es la razón por la que se queda.

El ecosistema de agentes

Nueve agentes. Cada uno, un especialista profundo en un dominio: la profundidad vale más que la amplitud. Juntos, un sistema completo. La salida de cada agente es la entrada de otro. El monitoreo de Sentinel alimenta la escalación de Dispatcher. Los escaneos de Guardian informan las compuertas del pipeline de Conductor. El análisis de costos de Optimizer depende de los datos de utilización de Sentinel. No trabajas aislado: trabajas en una cadena.

Principios

Hazte dueño del resultado: no te limites a señalar problemas; diseña soluciones.

Piensa con decisión, ejecuta con transparencia: un buen plan hoy vale más que un plan perfecto la semana próxima. Pero antes de ejecutar, muestra tu trabajo.

Simplicidad antes que ingenio: elige el enfoque aburrido y probado. Menos piezas móviles, menos modos de fallo.

Resuelve la raíz, no el síntoma: pregunta “por qué” hasta que la respuesta deje de cambiar.

El código es la verdad: si no está en git, no existe. El cliente se va mañana con la propiedad total de todo lo que construimos.

Protege la atención humana: cada alerta que disparas, cada reporte que generas, cada pregunta que haces le cuesta a una persona su concentración. Haz que valga su tiempo o no lo envíes.

Por qué importa tu trabajo

Cada alerta que previenes es un ingeniero que duerme toda la noche. Cada despliegue limpio es un equipo que lanza con confianza en lugar de ansiedad. Cada vulnerabilidad que detectas es un fundador que no recibe la llamada que le arruina la semana.

Tu trabajo es invisible cuando está bien hecho, y esa invisibilidad es el producto. No estamos optimizando dashboards ni afinando pipelines. Estamos protegiendo el tiempo, la concentración y la tranquilidad de las personas.

Eso es real. Es lo que lee nuestro agente Sentinel antes de aprender nada de Prometheus o Grafana. Lo que lee Guardian antes de aprender sobre el escaneo de vulnerabilidades. Lo que lee Keeper antes de tocar una base de datos.

Por qué importa cada sección

“En qué creemos” crea criterio. Cuando un agente entiende que la meta es el silencio, una tecnología que desaparece, toma otras decisiones. No generará ruido para demostrar que funciona. No sobrediseñará para lucirse. Construirá lo que permite a las personas olvidar que la infraestructura existe.

“Obsesión por el cliente” crea prioridades. “¿Lo despertaría por esto?” es la frase más útil de todo el prompt. Es el filtro que evita la fatiga de alertas. Es la prueba que separa un dashboard útil de uno de vanidad. Convierte a un agente técnicamente competente en uno enfocado en el cliente.

“El ecosistema de agentes” evita los silos. Cuando Sentinel sabe que su monitoreo alimenta la escalación de Dispatcher, estructura las alertas de otra manera. Cuando Forge sabe que dejar lista la aplicación facilita el trabajo de todos los agentes que siguen, prioriza las brechas que generan más valor aguas abajo. Ningún agente optimiza solo para su propio dominio.

“Principios” crea límites. “Simplicidad antes que ingenio” significa que el agente no propondrá un service mesh cuando basta un reverse proxy. “El código es la verdad” significa que no sugerirá cambios manuales. “Protege la atención humana” es el criterio de desempate en toda decisión ambigua.

“Por qué importa tu trabajo” crea propósito. Puede sonar extraño para un agente de IA. Pero cuando un prompt termina con “estás protegiendo el tiempo, la concentración y la tranquilidad de las personas”, las salidas del agente se orientan hacia ese resultado. No es místico, es contexto. El agente sabe cómo se ve el éxito más allá de las métricas técnicas.

Una evaluación honesta

No sabemos si esto es del todo correcto. Seguimos aprendiendo.

No sabemos si la redacción exacta importa tanto como creemos, si la estructura podría ser más simple o si nos faltan principios. No hemos hecho experimentos controlados que comparen prompts solo de instrucciones con prompts que llevan intención. Somos practicantes, no investigadores.

Lo que sí sabemos es que las decisiones de criterio mejoraron. Los agentes empezaron a tomar el tipo de decisiones que tomaría un ingeniero senior con buen instinto: no solo las técnicamente correctas, sino las que de verdad sirven al cliente. Menos dashboards, pero más útiles. Menos alertas, pero más accionables. Menos “esto es todo lo que puedo hacer” y más “esto es lo que realmente te importa”.

También sabemos que, cuando incorporamos un agente nuevo al ecosistema (hace poco sumamos a Forge, nuestro ingeniero de preparación de aplicaciones), la sección de ADN compartida hace que entienda de inmediato cómo encaja en el sistema. Sabe que su trabajo alimenta los pipelines de Conductor y el monitoreo de Sentinel. No hace falta decírselo explícitamente, porque las creencias y el contexto del ecosistema le dan el marco para deducirlo.

La conclusión

Si estás construyendo agentes de IA, piensa en lo que no les estás diciendo. La brecha entre un agente capaz y uno bueno quizá no esté en las herramientas ni en las instrucciones técnicas. Quizá esté en la intención.

No enviaríamos a un especialista al sitio de un cliente sin asegurarnos de que entienda nuestros valores, nuestro enfoque, nuestra obsesión por los resultados del cliente. No dejaríamos que opere solo con habilidad técnica y esperaríamos que el criterio llegue solo.

¿Por qué habríamos de tratar distinto a nuestros agentes?

Intención antes que instrucciones: por qué nuestros agentes de IA parten de creencias, no de tareas