El tablero de proyectos de tu equipo lleva incorporada una suposición silenciosa: todo responsable es una persona. Cada cambio de estado lo hizo alguien con un clic. Cada «Done» significa que un humano hizo el trabajo y otro humano le echó un vistazo. Esa suposición se mantuvo durante veinte años de software de gestión de proyectos, y empieza a tambalearse el día en que tu equipo comienza a asignarle trabajo real a agentes de codificación con IA.
Los agentes no se comportan como los responsables para los que se diseñó tu tablero. Trabajan a las 2 de la mañana. Terminan en minutos y luego esperan, en silencio, a que alguien se dé cuenta. Producen un diff, una ejecución de pruebas y un resumen en lugar de una actualización en la daily. Si tu herramienta de seguimiento no puede representar nada de eso, el trabajo de los agentes ocurre fuera del tablero: en terminales privadas, chats privados y decisiones a criterio personal. El trabajo se hace, pero nadie puede verlo, asumirlo ni aceptarlo.
Cerrar esa brecha es una disciplina con nombre: gestión de proyectos con agentes de IA. Esta guía la define, la separa de los términos con los que se confunde, recorre su bucle operativo y muestra qué cambia en cada primitiva de gestión de proyectos que ya conoces. Usaremos Sharkly como implementación de referencia, igual que lo hace nuestra guía de orquestación de agentes de IA: primero la categoría, después el producto.
TL;DR: ¿qué es la gestión de proyectos con agentes de IA?
La gestión de proyectos con agentes de IA es la práctica de asignar, hacer seguimiento y revisar el trabajo que realizan los agentes de IA junto con las personas, de modo que cada tarea de un agente tenga un responsable, un estado, contexto completo y una persona que acepte o rechace el resultado. Trata a los agentes como responsables dentro de un sistema de trabajo compartido, en lugar de como herramientas dentro de terminales privadas. Es distinta de la orquestación de agentes, que hace que los agentes se ejecuten; la gestión de proyectos con agentes hace que su trabajo sea visible, tenga un dueño y se acepte. La necesitas cuando el trabajo de los agentes se convierte en trabajo de equipo: varios agentes, varias personas y resultados lo bastante importantes como para revisarlos.
La definición, desglosada
La gestión de proyectos con agentes de IA es la disciplina de gestionar trabajo cuyos responsables incluyen agentes de IA: definir tareas que los agentes puedan ejecutar, asignarlas al agente o a la persona adecuada, mantener el contexto y el registro de ejecución en un único lugar compartido, y enrutar cada resultado a través de la revisión y la aceptación humanas.
Cinco palabras de esa frase cargan todo el peso:
- Asignación. A un agente se le puede dar una tarea igual que a un compañero de equipo, con el objetivo, las restricciones y los criterios de aceptación adjuntos, no pegados en un prompt que desaparece cuando se cierra la terminal.
- Seguimiento. El trabajo del agente tiene un estado que todo el equipo puede ver, desde en cola hasta en ejecución o esperando revisión, junto al trabajo humano en el mismo plan.
- Contexto. El agente lee su tarea como lo haría un compañero nuevo: descripción, comentarios, código vinculado, decisiones previas. Y su resultado vuelve a ese mismo registro.
- Revisión. Una persona lee lo que produjo el agente antes de que cuente.
- Responsabilidad. Cada tarea de un agente tiene un humano que responde por ella. El agente ejecutó; una persona es dueña del resultado.
Si tu configuración entrega esas cinco cosas, estás haciendo gestión de proyectos con agentes de IA, sea cual sea la herramienta. Si no entrega ninguna, tienes agentes, pero no tienes gestión.
Qué no es la gestión de proyectos con agentes de IA
Hay tres términos vecinos que se meten en este saco, y esa confusión genera problemas reales cuando los equipos buscan herramientas.
No es la gestión de proyectos tradicional con agentes añadidos a la fuerza
Jira, Linear y sus pares se construyeron sobre la suposición del responsable humano: un solo tipo de responsable, estados que modelan los ritmos de trabajo humanos y ninguna distinción en el modelo de datos entre quién es responsable y qué está ejecutando. Algunos han avanzado hacia los agentes (Linear puede delegar una incidencia a un agente de codificación conectado, que informa el progreso y devuelve un diff en la incidencia), pero la ejecución sigue ocurriendo dentro del agente alojado del proveedor que hayas conectado, bajo las condiciones de ese proveedor. Lo que no obtienes es una capa neutral para ejecutar tu propia combinación de entornos en máquinas que controlas, con un único registro compartido de cada ejecución. Comparamos hasta dónde llegan los rastreadores tradicionales en nuestra guía de alternativas a Jira para equipos de humanos y agentes.
No es orquestación de agentes
Esta es la distinción que más importa, porque las dos disciplinas son adyacentes y complementarias. La orquestación de agentes trata de la ejecución: enrutar una tarea a un agente, aislar el espacio de trabajo de cada agente para que las ejecuciones paralelas no colisionen y mantener la maquinaria en marcha. La gestión de proyectos con agentes trata del trabajo en sí: quién lo pidió, qué debe lograr, en qué estado está, quién lo revisa y si se aceptó.
Una forma clara de mantenerlas separadas: la orquestación hace que los agentes se ejecuten; la gestión de proyectos con agentes hace que su trabajo sea visible, tenga un dueño y se acepte. Un equipo puede tener una orquestación excelente y ninguna gestión de proyectos con agentes, lo cual se ve como diez agentes ejecutándose sin problemas en paralelo mientras nadie puede decir en qué están trabajando ni quién da el visto bueno.
No es un framework de agentes
Frameworks como LangGraph o los patrones multiagente de los SDK de agentes son bibliotecas de código para construir aplicaciones de agentes. Conciernen a los desarrolladores que construyen un agente. La gestión de proyectos con agentes concierne a los equipos que usan agentes, casi siempre entornos de codificación ya hechos como Claude Code o Codex, y que necesitan que ese trabajo encaje en un plan de equipo. Puedes adoptar la gestión de proyectos con agentes sin escribir una sola línea de código de framework. Si delegar trabajo de programación en herramientas autónomas es nuevo para ti, empieza por nuestra introducción sobre qué es la codificación agéntica.
El bucle operativo: definir, asignar, ejecutar, revisar, aceptar
Reduce cualquier configuración de gestión de proyectos con agentes a su esqueleto y encuentras el mismo bucle de cinco etapas. Cada etapa tiene una mitad humana y una mitad de agente, y el bucle solo funciona cuando ambas son explícitas.
1. Definir. Una persona escribe la tarea: el objetivo, por qué importa, qué está dentro y fuera del alcance y cómo se juzgará que está terminada. Esto importa más con agentes que con personas, porque un agente no puede absorber el contexto de los pasillos. Un compañero que recibe un ticket vago hace una pregunta aclaratoria en el almuerzo; un agente o pregunta en un comentario o adivina.
2. Asignar. La tarea va a un responsable, y aquí la primitiva se divide en dos. La responsabilidad va a una persona: el humano que es dueño del resultado. La ejecución va a un agente o a una persona, para el trabajo que los agentes no deberían tocar. Mantener esos como campos separados, en lugar de un único «responsable» sobrecargado, es el cambio más importante en el modelo de datos de la gestión de proyectos con agentes. Preserva la rendición de cuentas mientras permite que la ejecución pase al software. Nuestro recorrido sobre asignar un ticket de Jira a un agente de IA y recibir un PR muestra la etapa de principio a fin.
3. Ejecutar. El agente lee la tarea, inspecciona el código, hace cambios, ejecuta comprobaciones. Esta es la etapa de la que se encarga la orquestación, y la gestión de proyectos con agentes solo le pide una cosa: que el progreso, los bloqueos y los resultados vuelvan a la tarea en lugar de perderse desplazándose en una terminal. Una ejecución que no deja registro compartido es una ejecución que el equipo no puede gestionar.
4. Revisar. El agente se detiene y una persona lee: el diff, los resultados de las pruebas, el propio resumen del agente sobre lo que hizo y lo que sigue siendo incierto. La revisión es donde la velocidad del agente se encuentra con el juicio humano, y la versión honesta de esta etapa incluye el rechazo. Un revisor que solo puede hacer clic en «aprobar» es un sello de goma, no una barrera.
5. Aceptar. La persona responsable toma la decisión: aceptar, solicitar cambios o reasignar. La aceptación es distinta de la revisión igual que hacer merge es distinto de leer un pull request. Es el momento en que la rendición de cuentas se materializa, y es deliberadamente humana. Los agentes investigan, ejecutan, prueban e informan. Las personas fijan la dirección, otorgan autoridad y aceptan el resultado.
Después el bucle se retroalimenta: el trabajo aceptado define la siguiente tarea, y el trabajo rechazado vuelve a definir con criterios más precisos.
Qué cambia en cada primitiva de gestión de proyectos
El vocabulario de la gestión de proyectos sobrevive a la llegada de los agentes. La mecánica que hay debajo cambia casi por completo.
| Primitiva | Suposición de la gestión tradicional | Gestión nativa de agentes |
|---|---|---|
| Tarea | Escrita para un humano que puede preguntar por ahí para obtener contexto | Brief autocontenido con objetivo, alcance, enlaces y criterios de aceptación verificables |
| Responsable | Un campo, siempre una persona | Dos campos: una persona responsable más un agente o persona que ejecuta |
| Estado | Movido a mano según los ritmos humanos (días) | Estado del flujo de trabajo más un estado de ejecución en vivo (en cola, en ejecución, fallido) que se actualiza en minutos |
| Sprint | Acotado a la disponibilidad humana | Alcance mixto; el rendimiento de los agentes limitado por la capacidad de las máquinas y el ancho de banda de revisión |
| Capacidad | Número de personas y horas | Horas de personas más concurrencia de agentes, con la revisión humana como techo real |
| Registro de auditoría | Comentarios e historial de estados manual | Registros de ejecución, trazas, diffs e informes de agentes adjuntos al registro de la tarea |
Las tareas dejan de ser recordatorios y se convierten en briefs. Un responsable humano tolera la ambigüedad; un agente la convierte en respuestas erróneas pero seguras de sí mismas. Escribir tareas con alcance explícito y criterios de aceptación, algo predicado durante años y rara vez practicado, pasa a ser estructural.
El estado se divide en dos capas. El estado del flujo de trabajo sigue describiendo en qué punto está el trabajo para el equipo. Por debajo, la ejecución del agente tiene sus propios estados: en cola, en ejecución, completado, fallido, cancelado. Una tarea puede estar En curso mientras la ejecución de su agente ha fallado y nadie se ha dado cuenta. Las herramientas nativas de agentes muestran ambas capas y dirigen los momentos de «esperando tu revisión» y «la ejecución ha fallado» a la persona responsable, en lugar de confiar en que alguien lo compruebe.
Los sprints conservan su forma y cambian su física. Un sprint sigue siendo un alcance con límite de tiempo y un objetivo. Pero cuando parte del alcance se ejecuta en minutos en lugar de días, la planificación pasa de «qué pueden terminar las personas» a «qué pueden definir y revisar las personas». Cubrimos la mecánica en cómo funcionan los Sprints en Sharkly.
La capacidad se convierte en un número de dos caras. La capacidad del lado de los agentes es matemática de máquinas y concurrencia. La capacidad del lado humano es el ancho de banda de revisión: cuántos resultados de agentes puede leer tu equipo con atención. El segundo número casi siempre es el más pequeño, y fingir lo contrario es como los equipos acaban integrando trabajo que nadie leyó.
El registro de auditoría pasa de ser higiene opcional a requisito fundamental. Cuando una persona hizo el trabajo, puedes preguntarle qué pasó. Cuando lo hizo un agente, la única respuesta honesta es el registro de ejecución: la tarea, la traza, las comprobaciones que ejecutó y el informe que dejó.
Cuándo no necesitas la gestión de proyectos con agentes de IA
Una guía honesta incluye los casos en los que la respuesta es «todavía no». Sáltate la capa de gestión de proyectos con agentes cuando seas un desarrollador en solitario que ejecuta un solo agente, cuando el volumen de agentes sea de unas pocas tareas a la semana que pueden vivir como tickets normales, o cuando el trabajo sea prototipado desechable que nunca se revisará ni mantendrá. El proceso debe seguir al volumen, no precederlo.
Adóptala cuando las señales cambien: más de una persona necesita ver el trabajo de los agentes, se ejecuta más de un agente a la vez, o un cambio de un agente sin revisar ya ha causado un desastre. Usa un sistema compartido cuando el trabajo de los agentes se convierta en trabajo de equipo, y no antes.
Cómo se ve la gestión de proyectos con agentes en la práctica: Sharkly
La categoría es agnóstica respecto a las herramientas; la mecánica es más fácil de ver en un sistema concreto. Sharkly es un sistema de gestión del trabajo para Personas y Agentes. No es un reemplazo de Claude Code, Codex u otras herramientas de ejecución. Añade la capa compartida de tareas, contexto, control y revisión alrededor de los entornos que tu equipo ya usa, con el uso de modelos continuando a través de las suscripciones o claves de API configuradas en esas herramientas.
La Tarea es la unidad de registro: objetivo, descripción, estado, prioridad, comentarios y el estado de ejecución, la traza y el resultado del Agente, todo en un mismo lugar. La asignación implementa la división descrita antes: una persona registra la responsabilidad humana mientras que un Agente o Crew es el responsable de la ejecución, y una Tarea puede llevar ambos a la vez. El Backlog actúa como estado de aparcamiento, de modo que asignar un Agente no inicia una ejecución hasta que la Tarea pasa a un estado listo para trabajar.

Mientras un Agente trabaja, los estados de ejecución se mantienen separados del estado del flujo de trabajo de la Tarea, y ambos son visibles en el tablero. Los resultados, los bloqueos y las conversaciones de seguimiento vuelven a la Tarea: el informe del Agente se guarda como un comentario vinculado a su traza de ejecución, y el Inbox dirige los momentos de «esperando tu revisión» a la persona responsable. La aceptación sigue siendo humana. La documentación de Sharkly cubre cada concepto con más profundidad.
En resumen
La gestión de proyectos se ganó su lugar haciendo que el trabajo humano fuera visible, tuviera un dueño y pudiera revisarse. La gestión de proyectos con agentes de IA extiende ese mismo contrato a responsables que resultan ser software: define el trabajo con claridad, asigna la responsabilidad y la ejecución por separado, deja que los resultados vuelvan a un registro compartido y mantén la aceptación en manos humanas. La orquestación hará que tus agentes vayan rápido. Esta es la disciplina que hace que su producción sea digna de confianza. Empieza poco a poco: toma una pieza recurrente de trabajo de agentes que hoy vive en una terminal, dale una tarea con criterios de aceptación reales y pásala una vez por el bucle.
Preguntas frecuentes
¿Qué es la gestión de proyectos con agentes de IA en una frase?
Es la práctica de asignar, hacer seguimiento y revisar el trabajo que realizan los agentes de IA junto con las personas, de modo que cada tarea de un agente tenga un responsable, un estado, contexto completo y una persona que acepte el resultado. En resumen, trata a los agentes como responsables dentro de un sistema de trabajo compartido en lugar de como herramientas dentro de terminales privadas.
¿En qué se diferencia la gestión de proyectos con agentes de IA de la orquestación de agentes?
La orquestación hace que los agentes se ejecuten: enrutamiento, aislamiento del espacio de trabajo, ejecución en paralelo, capacidad de las máquinas. La gestión de proyectos con agentes hace que su trabajo sea visible, tenga un dueño y se acepte: tareas, estados, revisión y rendición de cuentas. Son capas complementarias, y una configuración completa necesita ambas. Nuestra guía de orquestación cubre el lado de la ejecución en profundidad.
¿Puedo hacer gestión de proyectos con agentes de IA en Jira o Linear?
Parcialmente. Puedes representar las tareas de los agentes como tickets, y algunos rastreadores ahora delegan incidencias a agentes de codificación conectados. Lo que no te dan es una capa de ejecución neutral para tu propia combinación de entornos y máquinas, con un único registro compartido de cada ejecución. Consulta nuestra comparativa de alternativas a Jira para equipos de humanos y agentes.
¿Quién es responsable cuando un agente de IA hace el trabajo?
Una persona, siempre. En la gestión de proyectos con agentes, el humano responsable y el agente que ejecuta son campos separados en la misma tarea: el agente ejecuta, y la persona es dueña del resultado, revisa el resultado y decide la aceptación. Un agente nunca es la respuesta final a «quién dio el visto bueno a esto».
¿Qué debería buscar en una herramienta de gestión de proyectos con agentes de IA?
Cuatro cosas que se corresponden con el bucle operativo: una asignación que lleve el contexto completo de la tarea al agente, un seguimiento en vivo que muestre tanto el estado del flujo de trabajo como el estado de ejecución, un registro de auditoría donde las trazas y los resultados vuelvan a la tarea, y un paso integrado de revisión y aceptación humana. Añade planificación de Sprints híbrida si ejecutas agentes dentro de una cadencia de equipo.



