El problema aparente era el volumen de correos. El problema real era que mi equipo me traía temas antes de haber preparado la decisión.

En un puesto anterior como CIO, construí un agente declarativo en Microsoft 365 Copilot con un propósito muy concreto: ayudar a mi equipo a preparar un escalamiento antes de traerlo a mí.

El agente seguía un flujo de trabajo acotado. Hacía preguntas para aclarar la situación, evaluaba si el escalamiento estaba listo y se detenía cuando faltaba información o era más seguro usar otro canal. No tomaba ni ejecutaba la decisión.

No compartiré cifras exactas, pero la escala importa. La organización de tecnología reunía a cientos de profesionales que atendían cientos de proyectos simultáneos y una extensa cartera de aplicaciones. A esa escala, los escalamientos mal preparados no eran un pequeño problema de redacción. Les quitaban tiempo y atención a las decisiones importantes.

Recibía dos tipos de mensajes una y otra vez.

El primero era dolorosamente breve: «La migración está retrasada. Por favor, nos indica qué debemos hacer». No había suficiente contexto para tomar una decisión y el remitente no ofrecía ninguna recomendación.

El segundo se iba al extremo opuesto. Incluía la historia técnica, la cronología de reuniones, las preguntas pendientes y páginas de antecedentes. Parecía estar todo, excepto la decisión.

Distinta extensión, el mismo problema. Ambos me obligaban a reconstruir la situación, identificar las opciones reales, averiguar quién respondía por la recomendación y determinar cuándo había que decidir.

El cuello de botella no era la bandeja de entrada. Era la preparación de decisiones.

El problema no era el volumen de correos

Pedirle a mi equipo que escribiera correos más breves no resolvía el problema. Un mensaje corto podía seguir siendo inútil; uno largo podía contener muchos datos y aun así no estar listo para una decisión.

Lo que importa es la información que cambia la decisión:

• ¿Qué cambió y por qué importa ahora?
• ¿Qué debe decidir o hacer el destinatario?
• ¿Qué opciones son realmente viables?
• ¿Qué se gana y qué se sacrifica con cada opción, y cuáles son los riesgos?
• ¿Qué recomienda el remitente?
• ¿Quién es responsable del siguiente paso?
• ¿Para cuándo se necesita la decisión?

Comprimir no significa acortar un correo. Significa conservar lo que cambia la decisión.

Por supuesto, los líderes deben fijar este estándar. Yo intenté hacerlo. Pero sostenerlo de manera consistente en una organización de ese tamaño es difícil. Las orientaciones se interpretan de distintas maneras, la presión cambia el comportamiento y cada nuevo integrante del equipo debe aprender las mismas expectativas.

El agente convirtió esas preguntas en una práctica repetible. Era un apoyo para el liderazgo, no un sustituto.

El agente ayudaba a pensar antes de escribir

El agente no era una herramienta para pulir correos. Antes de redactar nada, hacía que el remitente analizara la situación.

¿Qué había cambiado? ¿Por qué era importante? ¿Qué decisión se necesitaba? ¿Qué opciones eran reales? ¿Qué recomendaba el remitente? ¿Qué riesgos persistían, quién era responsable del siguiente paso y para cuándo se necesitaba?

No todos los escalamientos requerían la misma cantidad de antecedentes. Mantenía una pequeña lista de proyectos de alta prioridad que seguía de cerca y otra de proyectos que conocía solo a grandes rasgos.

El agente usaba esa distinción para calibrar cuánto contexto pedir. Si yo conocía bien un proyecto, no obligaba al remitente a contar de nuevo toda la historia; se concentraba en el cambio más reciente y la acción necesaria. Si apenas tenía una idea general, pedía suficientes antecedentes para dejar claras las consecuencias. Si el proyecto no aparecía en ninguna lista, asumía que yo partía de cero y solicitaba más contexto.

Esas listas no eran una base de datos de proyectos ni le decían al agente cuál era la situación actual. Solo le indicaban cuánto sabía ya el destinatario. Esa pequeña distinción importaba: la claridad necesaria para decidir depende de quién recibe el mensaje.

También separaba hechos de supuestos y cuestionaba si el correo era realmente el canal adecuado. Solo después de ese trabajo preparaba un mensaje de escalamiento conciso.

Muchos integrantes de mi equipo se sorprendían con el resultado. Esperaban que el agente los ayudara a escribir un mejor correo. En cambio, los ayudaba a entender el problema, precisar qué querían decir y definir qué decisión le estaban pidiendo realmente a otra persona.

El mejor correo era solo el resultado visible. El cambio más importante era pensar mejor antes de comunicar.

El agente no era responsable de la decisión. Mejoraba el traspaso entre quien tenía el contexto y quien debía decidir.

Tomemos un ejemplo hipotético. Un escalamiento mal preparado dice:

La migración está retrasada.
Por favor, díganos qué debemos hacer.

Una versión preparada para decidir identifica la solicitud concreta: aprobar un lanzamiento limitado o aplazar el lanzamiento completo. Pone sobre la mesa las opciones viables —un lanzamiento limitado, aplazar por completo el lanzamiento o mantener temporalmente una operación manual— y hace visibles sus implicancias: valor para el cliente, impacto en el hito y riesgo operativo. También incluye la recomendación del remitente, la persona responsable y la fecha límite.

El agente no tomó la decisión. Dejó claro qué había que decidir.

La prueba del pasillo

Supe que la práctica empezaba a ser útil cuando dejó de limitarse al correo electrónico.

A veces alguien me detenía en el pasillo para plantearme un problema. Si no era urgente, empecé a preguntar: «¿Ya validaste esto con el agente?». Si la respuesta era no, le pedía que primero ordenara el asunto con el agente y después regresara o me enviara el mensaje listo para decidir.

No me negaba a escuchar. Estaba devolviendo la responsabilidad de preparar la decisión a quien mejor conocía el contexto. De paso, reforzaba el hábito en una situación real, algo que funcionaba mejor que otra lección abstracta sobre comunicación ejecutiva.

Mi equipo podía seguir acercándose a mí; el agente servía para prepararse, no para pedir permiso.

Pero nunca fue una regla absoluta. Si algo era realmente urgente, me detenía a escuchar. Primero resolvíamos el problema. Después explicaba cómo podía ayudar el agente la próxima vez.

El objetivo no era pasar por el agente para cumplir un proceso. Era llegar mejor preparado al escalamiento.

Esa flexibilidad era importante. El equipo estaba aprendiendo a usar una nueva plataforma y otra forma de trabajar; yo no esperaba que todos cambiaran de la noche a la mañana. Introdujimos la práctica de manera gradual, la reforzamos en las interacciones cotidianas y la adaptamos cuando el contexto exigía algo diferente.

Lo que aprendí

Noté una diferencia real en el trabajo que llegaba a mí. Dedicaba menos esfuerzo a reconstruir el problema y más tiempo a considerar las consecuencias y los costos y beneficios de cada opción. Era más claro quién respaldaba cada recomendación. La falta de contexto se hacía evidente antes. Y el equipo aprendió a reconocer mejor cuándo bastaba un correo y cuándo simplemente necesitábamos conversar.

El agente también nos dio un lenguaje común para preparar un escalamiento. Podíamos usarlo en un correo, una reunión o una conversación de pasillo.

No hice un estudio controlado, así que no voy a atribuirle al agente un ahorro cuantificable de tiempo ni una mejora de productividad. Tampoco asumo que el mismo diseño pueda copiarse sin cambios en otra organización.

Había límites firmes. El agente no podía inventar hechos, crear opciones inexistentes, ocultar desacuerdos ni atribuirle a alguien una recomendación que no era suya. Tampoco podía decidir si cierta información sensible podía procesarse de forma segura ni reemplazar una conversación cuando la urgencia, la ambigüedad, la negociación o el riesgo de exposición hacían del correo el canal equivocado.

El remitente seguía validando los hechos y siendo responsable de la recomendación. El destinatario seguía tomando la decisión. La elección del canal y la aprobación final de la comunicación seguían en manos humanas.

Si cada escalamiento obliga al ejecutivo a reconstruir el problema, el ejecutivo se convierte, por diseño, en el cuello de botella.

Lo que comparto

Ya publiqué Decision-Ready Escalations, la primera entrega de mi repositorio Agentic Work Patterns.

Este no es el agente interno original. Es una reconstrucción independiente, creada desde cero y sin depender de un proveedor, del patrón operativo que resultó útil en mi trabajo como CIO. Incluye instrucciones para el agente, casos de prueba hipotéticos, una rúbrica de evaluación y salvaguardas de privacidad y revisión humana. También ofrece orientación sobre cuándo es más seguro usar otro canal de comunicación y un modelo para registrar la familiaridad del destinatario con el proyecto, sin información de proyectos reales.

Probé la reconstrucción pública con seis escenarios de prueba basados en información ficticia, incluidos dos sobre la familiaridad del destinatario, y se comportó como estaba previsto en esos casos. Estas pruebas son útiles, pero no demuestran confiabilidad en producción, validación independiente, adopción ni impacto en el negocio.

Si quieres evaluar el patrón, comienza con un caso hipotético y revisa el resultado con la rúbrica antes de considerar datos reales de una organización. Un ejemplo de prueba completo muestra el resultado esperado.

Muchas conversaciones sobre agentes empiezan por las decisiones que la IA podría tomar en el futuro. Una oportunidad más inmediata es ayudar a los equipos a preparar decisiones que siguen siendo responsabilidad humana.

¿Qué cambiaría en tu organización si cada escalamiento llegara con una decisión clara, opciones viables, implicancias reales, una recomendación que alguien asuma como propia y una fecha límite?