Todo equipo de ingeniería arrastra una capa de trabajo recurrente que nadie planificó y que todos acabamos pagando. Alguien arma el resumen del standup. Alguien lee cada informe de error que llega y lo deriva a quien corresponda. Alguien compila el informe de estado del viernes a partir de seis pestañas de información dispersa. Nada de esto es difícil. Todo es trabajo repetitivo: predecible, reiterativo y caro en silencio, porque acaba recayendo en quien lo detectó primero.
Este es justo el tipo de trabajo que un Agente de IA hace bien, siempre que algo ponga en marcha al Agente en el momento adecuado sin que nadie tenga que escribir un prompt. Ese mecanismo de arranque es lo que aportan las Automatizaciones en Sharkly. Una Automatización es una definición propiedad de un Space para trabajo repetible de un Agente o un Crew: instrucciones escritas, un responsable de la ejecución, uno o más desencadenantes y un historial de ejecuciones que puedes consultar.
La idea no es automatizar el criterio. El propio planteamiento de Sharkly es tajante: la automatización se detiene donde se requiere el criterio del equipo. Una Automatización puede redactar el resumen del standup, hacer una primera lectura de un error y armar el informe semanal. Una persona sigue decidiendo qué hace el equipo al respecto. Si eres nuevo en Sharkly, empieza por qué es Sharkly y luego vuelve.
TL;DR
Una Automatización en Sharkly es una regla propiedad de un Space que pone en marcha un Agente o un Crew con un conjunto fijo de instrucciones cada vez que se dispara un desencadenante. Hay cuatro tipos de desencadenante: una programación (cron de cinco campos con zona horaria), un cambio de estado de una tarea, un comentario que contiene una frase configurada y una URL de webhook secreta para servicios externos, además de un botón Ejecutar ahora para pruebas manuales. Cada ejecución queda registrada en el historial de ejecuciones con su origen, su resultado y el motivo del fallo, y una Automatización se puede pausar y reanudar mientras la revisas. Usa Automatizaciones para trabajo recurrente bien definido: resúmenes de standup, primera revisión de errores, informes periódicos. El Agente se encarga de leer y redactar; una persona revisa el resultado y toma la decisión.
Qué es una Automatización y qué no es
Una Automatización guarda una definición pequeña y completa de un único trabajo repetible: un nombre y unas instrucciones que describen el objetivo, los pasos, las restricciones y el resultado esperado; el Space al que pertenece; un responsable, es decir, el Agente o el Crew que realiza el trabajo; una prioridad; un estado Activa o En pausa; uno o más desencadenantes; y un historial de ejecuciones que registra el origen, el resultado, la ejecución del Agente y el motivo del fallo de cada ejecución.
Hay dos límites que, de otro modo, te pillarían por sorpresa.
En primer lugar, una Automatización no crea una Tarea por cada ejecución. Inicia directamente una ejecución de Agente o de Crew. La ejecución, su salida y cualquier fallo acaban en el historial de ejecuciones de la Automatización, no en tu lista de tareas, así que tu tablero no se llena de Tareas generadas por una máquina todas las mañanas a las nueve.
En segundo lugar, las Automatizaciones no son el lienzo de workflows de Sharkly. Un Space tiene dos superficies de automatización: Automatizaciones, la regla única que se describe aquí, y los workflows de Automatización, un lienzo de nodos de desencadenante y acción que puede llamar a conectores de terceros. Usa una Automatización cuando un Agente o un Crew deba ejecutar un conjunto de instrucciones en respuesta a un evento predecible. Usa un workflow cuando necesites acciones de varios pasos o entre aplicaciones antes de que el Agente intervenga.
Como el responsable es un Agente de Sharkly completo, se aplica todo lo que ya hayas configurado en ese Agente: sus instrucciones, su Runtime, sus Skills, sus repositorios y su configuración de ejecución. Si todavía no has creado ninguno, Agentes en Sharkly explica cómo una configuración guardada que funciona se convierte en algo que un equipo puede reutilizar. Una Automatización es, en la práctica, una cita fija con ese Agente.
Los cuatro tipos de desencadenante
Una Automatización puede tener varios desencadenantes, cada uno habilitado o deshabilitado de forma independiente. Una misma definición puede servir para varios puntos de entrada: las mismas instrucciones de triaje pueden dispararse ante un cambio de estado y ante un comando de barra, sin duplicar nada.
| Desencadenante | Se dispara cuando | Ideal para | Ojo con |
|---|---|---|---|
| Programación | Coincide una expresión cron, en una zona horaria elegida | Comprobaciones recurrentes, resúmenes, recordatorios, mantenimiento | La elección de la zona horaria; las ejecuciones se producen haya cambiado algo o no |
| Cambio de estado de una tarea | Una tarea pasa a un estado de la Organización seleccionado | Colas de entrada, seguimiento de revisiones, triaje | La coincidencia es a nivel de toda la Organización, no filtrada por Space |
| Frase en un comentario | Un comentario de una tarea contiene una frase configurada, sin distinguir mayúsculas de minúsculas | Comandos bajo demanda como /triage desde dentro de una conversación | También escucha en toda la Organización; elige una frase distintiva |
| Webhook | Un servicio externo envía un POST a una URL secreta | Resultados de CI, eventos de GitHub, alertas de otros sistemas | La URL es un secreto de portador; guárdala y rótala con cuidado |
Programación usa una expresión cron estándar de cinco campos y una zona horaria, con los ajustes predefinidos habituales por hora, día, día laborable y semana. Es el desencadenante para el trabajo que debe ocurrir porque es martes, no porque haya cambiado algo.
Cambio de estado de una tarea inicia la Automatización cuando una tarea pasa a un estado de la Organización seleccionado. Hay un detalle que importa: los estados son definiciones reutilizables de la Organización y la coincidencia de eventos actual es a nivel de toda la Organización. Si varios Spaces usan el mismo estado “Necesita triaje”, una transición coincidente en cualquiera de ellos puede iniciar tu Automatización. Redacta las instrucciones para que el Agente verifique la tarea que desencadenó el evento antes de actuar.
Frase en un comentario inicia una ejecución cuando un comentario de una tarea contiene una frase configurada. La coincidencia no distingue mayúsculas de minúsculas, busca en cualquier parte del comentario y también escucha en toda la Organización. El consejo de la documentación: mejor un comando de barra distintivo como /triage-bug que “check”, y haz que las instrucciones validen la tarea que desencadenó el evento.
Webhook crea una URL secreta que acepta un POST de un servicio externo. La URL completa se muestra cuando se crea o se regenera el desencadenante y no está disponible para consultarla después, porque, de forma predeterminada, la propia URL actúa como secreto de portador. Si configuras un secreto de firma, las solicitudes también deben superar la verificación de firma, el mismo patrón que GitHub usa para sus propios webhooks. Mantén estos secretos fuera del control de código fuente y regenerarlos si se ven expuestos. Para automatizar Sharkly más allá de los webhooks, consulta la CLI y la API de Sharkly.
Hay otra forma de iniciar una ejecución que no es un desencadenante: Ejecutar ahora inicia la Automatización directamente, y es la manera de probar las instrucciones y la disponibilidad del responsable antes de confiarle el trabajo a los cuatro desencadenantes.
Qué ejecuta realmente una Automatización
Cuando se dispara un desencadenante, Sharkly inicia el Agente o el Crew asignado con las instrucciones de la Automatización. Esas instrucciones son todo el contrato, así que la documentación es concreta sobre lo que deben indicar: el resultado que hay que producir, las entradas que hay que inspeccionar, los pasos que hay que seguir, dónde debe registrarse el resultado, qué cambios están permitidos y cuándo debe revisar o decidir una persona.
Ese último punto merece énfasis. Una Automatización bien escrita nombra su propio punto de parada. “Redacta el resumen y regístralo; no cambies el estado de ninguna tarea” es mejor instrucción que una más larga que deja la autoridad en el aire. Las indicaciones de despliegue de la documentación son igual de claras: empieza con trabajo observable y reversible, y revisa varias ejecuciones antes de ampliar el alcance.
Tres tareas que conviene automatizar primero
Cada una de ellas se mantiene en el nivel de fidelidad que admite el producto: el Agente lee, redacta y registra; las decisiones siguen siendo de las personas.
El resumen diario del standup. Desencadenante: una programación, con el ajuste predefinido de día laborable, en la zona horaria del equipo. Responsable: un Agente de informes con acceso de lectura al contexto relevante. Instrucciones: inspecciona las tareas del Sprint actual, anota qué avanzó, qué está bloqueado y qué espera revisión, y registra después un resumen breve donde lo lea el equipo, sin cambiar ninguna tarea. El Agente hace la parte del standup que a nadie le gusta, montar la foto completa, y el standup pasa a ser una conversación sobre los dos puntos que requieren criterio. Si tu equipo lleva su ritmo de trabajo con Sharkly, los Sprints aportan la estructura que el Agente inspecciona.
Primera revisión de errores. Desencadenante: un desencadenante de estado de tarea sobre tu estado de entrada de errores, o un desencadenante de comentario sobre una frase distintiva como /triage, o ambos. Responsable: un Agente de triaje cuyos repositorios cubran el código afectado. Instrucciones: verifica que la tarea que desencadenó el evento es un error en el Space previsto, lee el informe, inspecciona la zona relevante del código y registra qué parece tocar el error, si el informe contiene suficiente información para actuar y una prioridad sugerida con su razonamiento. Recomienda; no decidas. El paso de verificación no es decorativo: como la coincidencia de estados y comentarios es a nivel de toda la Organización, las instrucciones son tu filtro de alcance. La ventaja es que cada error recibe la misma primera lectura cuidadosa a los pocos minutos de llegar. La misma división del trabajo se mantiene cuando el trabajo llega desde fuera de Sharkly; mira cómo un ticket de Jira se convierte en el trabajo de un Agente.
El informe periódico. Desencadenante: una programación, con el ajuste predefinido semanal. Responsable: el mismo tipo de Agente de informes, con instrucciones acotadas a una ventana más larga: resume qué se completó, qué se retrasó y qué está bloqueado. La diferencia con el caso del standup es solo el alcance y el público, que es justo por lo que pertenece a una Automatización. El informe que existe todos los viernes con la misma fidelidad supera al informe mejor que existe cuando alguien tiene tiempo.
En los tres casos, fíjate en lo que nunca aparece en las instrucciones: aceptar, aprobar, publicar, cerrar, decidir.
Historial de ejecuciones, estado de salud y pausa y reanudación
Una automatización que no puedes inspeccionar es una automatización en la que no puedes confiar, así que cada ejecución queda registrada. El historial de ejecuciones indica cada ejecución como En ejecución, Completada, Fallida u Omitida, y los detalles de la ejecución te permiten abrir la carga útil del desencadenante, la ejecución del Agente, la salida y el motivo del fallo registrado. Por encima de las ejecuciones individuales, una señal de salud resume el último estado útil: nunca probada, en ejecución, saludable, omitida o requiere atención.
Hay una negación de límite que debería irte en negrita en la cabeza: un estado Completada describe la ejecución de la Automatización, no promete que todos los resultados posteriores fueran correctos. Completada significa que la maquinaria funcionó. Que el resumen fuera preciso o que la valoración del triaje fuera acertada sigue siendo una lectura humana.
La pausa y la reanudación existen justo para los momentos que te imaginas. Pausa una Automatización para detener las nuevas ejecuciones desencadenadas mientras revisas sus instrucciones, sus desencadenantes o su responsable, y reanúdala cuando la configuración esté lista; la definición y su historial se mantienen intactos mientras tanto. Eliminar es la única vía de retirada, así que resérvala para definiciones cuyo historial de ejecuciones ya no necesites. Y antes de archivar un Agente, comprueba si alguna Automatización todavía depende de él.
Antes de fiarte de cualquier Automatización, la documentación sugiere una lista de comprobación breve: ejecútala manualmente con Ejecutar ahora, confirma que el Agente o el Crew tiene el acceso necesario, inspecciona la ejecución y su salida, prueba cada desencadenante por separado, usa un estado específico o una frase de comentario distintiva y mantén los secretos de webhook fuera del control de código fuente.
Dónde se detiene la automatización
Sería fácil concluir que el objetivo es una cadena sin supervisión. No lo es, y el propio diseño del producto lo dice. Las Automatizaciones no aceptan su propia salida y registran cada ejecución para su revisión.
Así que la regla de decisión honesta es esta. Usa una Automatización cuando el mismo trabajo bien definido deba iniciarse repetidamente o en respuesta a un evento predecible, y cuando un primer borrador consistente sea mejor que uno excelente pero esporádico. Asigna una Tarea directamente a un Agente cuando el trabajo sea puntual, y deja el trabajo por completo en manos de las personas cuando el trabajo sea el criterio en sí: una decisión de prioridad bajo presiones contrapuestas, una decisión de aceptación, cualquier cosa en la que equivocarse de forma consistente sea peor que ser lento de vez en cuando.
Empieza con algo pequeño y aburrido. Configúralo todo, crea un Agente de informes, escribe una Automatización con una programación de días laborables e instrucciones que terminen con “no cambies ninguna tarea” y ejecútala manualmente una vez. Lee la salida. Si es útil, deja que la programación tome el relevo. La documentación cubre las Automatizaciones y el lienzo de workflows con más profundidad.
FAQ
¿Qué tipos de desencadenante admiten las Automatizaciones de Sharkly?
Cuatro: una programación que usa una expresión cron de cinco campos con zona horaria, un desencadenante de estado de tarea que se activa cuando una tarea pasa a un estado seleccionado de la Organización, un desencadenante de comentario que se activa con una frase configurada y un desencadenante de webhook que acepta un POST en una URL secreta. Una Automatización puede combinar varios desencadenantes, cada uno habilitado o deshabilitado de forma independiente, y Ejecutar ahora inicia una ejecución manual para hacer pruebas.
¿Crea una Automatización una Tarea cada vez que se ejecuta?
No. Las Automatizaciones actuales inician directamente ejecuciones de Agente o de Crew y no crean una Tarea por cada ejecución. La ejecución, su salida y cualquier motivo de fallo se registran en el historial de ejecuciones de la Automatización. Si quieres que el resultado aparezca donde lo lea el equipo, dilo en las instrucciones.
¿En qué se diferencian las Automatizaciones de los workflows de Automatización?
Son dos superficies distintas dentro de un Space. Una Automatización es una regla: cuándo empezar, qué Agente o Crew se ejecuta y qué instrucciones sigue. Los workflows de Automatización son un lienzo de nodos de desencadenante y acción que pueden llamar a aplicaciones de terceros mediante conectores. Usa la regla única para comprobaciones recurrentes y comandos en comentarios; usa el lienzo para flujos de varios pasos y entre aplicaciones.
¿Puede una Automatización encargarse del triaje de errores por sí sola?
Puede encargarse de la primera revisión: verificar la tarea que desencadenó el evento, leer el informe, inspeccionar el código relevante y registrar los hallazgos con una prioridad sugerida. La decisión del triaje sigue siendo de una persona, y las instrucciones deberían decirlo explícitamente. La documentación recomienda empezar con trabajo observable y reversible y revisar varias ejecuciones antes de ampliar el alcance.
¿Qué ocurre cuando falla una ejecución de una Automatización?
La ejecución se registra como Fallida en el historial de ejecuciones, con el motivo del fallo cuando está disponible, y la señal de salud pasa a requiere atención. Abre los detalles de la ejecución para inspeccionar la carga útil del desencadenante, la ejecución del Agente y la salida, corrige las instrucciones, el desencadenante o el responsable, y usa Ejecutar ahora para verificar la corrección antes de volver a fiarte de los desencadenantes.
