Qué es la gestión de proyectos agéntica
Cómo conectar la tarea, el resultado de un agente y la revisión humana, con evidencia concreta y límites de disponibilidad.
Actualizado el 8 de septiembre de 2026.
Un agente termina una tarea y devuelve un resultado convincente. El equipo todavía tiene que saber qué petición resolvió, qué fuentes utilizó, qué comprobó y quién puede aceptar el cambio. La gestión de proyectos agéntica organiza esa relación entre una petición, una ejecución y una decisión humana.
El punto de partida es el trabajo compartido: un proyecto, tareas con alcance concreto y contexto que otra persona pueda recuperar. A partir de ahí se conectan las herramientas que ejecutan y los controles que permiten revisar sus resultados. La calidad de ese sistema depende de su comportamiento comprobable, no del número de agentes que muestre una pantalla.
En BIKLABS, proyectos y work items forman esa base. La wiki y BIA están en Preview, los agentes internos en Alpha y los gates en Piloto. La conexión MCP actual ofrece nueve herramientas sobre proyectos y work items. Este artículo separa esa disponibilidad del proceso más amplio que un equipo puede diseñar alrededor de ella.
Una tarea necesita algo más que una instrucción
«Mejora la documentación» deja abiertas demasiadas decisiones. «Actualiza el apartado de paginación utilizando la especificación aprobada; entrega un borrador y señala cualquier discrepancia» delimita un resultado que puede revisarse.
| Elemento | Ejemplo de definición |
|---|---|
| Resultado | Un borrador del apartado de paginación |
| Fuentes | La especificación aprobada y la implementación que se va a documentar |
| Límites | Señalar discrepancias; cualquier cambio de código requiere otra tarea |
| Criterio de aceptación | Ejemplos comprobados, enlaces válidos y revisión del responsable técnico |
Qué cambia cuando ejecuta un agente
Las personas aportan criterio y responsabilidad organizativa. El agente aporta una ejecución que debe evaluarse según sus fuentes, herramientas y resultado. Asignarle un nombre ayuda a distinguirla, pero ese nombre no demuestra qué permisos aplicó el sistema ni qué acciones quedaron registradas.
Conviene separar tres estados: trabajo solicitado, resultado entregado y resultado aceptado. Un proceso que los representa con claridad permite que un agente termine su parte sin confundirla con una decisión de entrega. Si la revisión detecta un problema, el work item conserva la corrección pendiente y la persona responsable.
También hay que distinguir dos controles. Un gate dentro del gestor puede detener una transición compatible. Los permisos del repositorio, del almacenamiento o de otra aplicación controlan las acciones en esos sistemas. La presencia del primero no demuestra que los segundos estén cubiertos. En BIKLABS, los gates son un Piloto y su cobertura debe verificarse en el flujo habilitado.
Agentes externos y contexto autorizado
Un equipo puede utilizar un runtime externo compatible con MCP para consultar y actualizar el trabajo que permitan las herramientas disponibles. BIKLABS ofrece hoy una superficie limitada para proyectos y work items; el acceso a documentos adicionales o la devolución de otros entregables exige una integración específica.
Ejecutar el cliente en un portátil o en un runner propio no implica que todo el procesamiento permanezca allí. Las peticiones al proveedor del modelo y las herramientas conectadas pueden transmitir contenido a otros servicios. El equipo debe revisar ese recorrido de datos, las fuentes autorizadas y las condiciones de cada servicio antes de incorporar material sensible.
La separación entre gestor de trabajo y runtime facilita elegir las herramientas de ejecución. La portabilidad real del historial, los permisos y los resultados depende de las interfaces y formatos que cada integración soporte; debe comprobarse al evaluar un cambio de proveedor.
Qué evidencia pedir al sistema
Una pantalla de actividad es útil cuando permite responder preguntas concretas. ¿Qué tarea estaba asociada a la ejecución? ¿Qué resultado devolvió? ¿Qué comprobaciones se hicieron? ¿Qué persona revisó la entrega? Cuando hay consumo o coste disponible, ¿de qué parte de la ejecución procede?
Un dato ausente debe permanecer identificado como ausente. Un importe cero no equivale a un coste desconocido, y una ejecución marcada como finalizada no demuestra que el entregable sea correcto. La cobertura de runs, consumo y actividad de BIKLABS está en Preview; no constituye un registro universal ni una conciliación completa con la factura del proveedor.
La evaluación puede incluir estos casos, dentro de un proyecto de prueba autorizado:
- Un resultado correcto que una persona acepta.
- Una entrega incompleta que vuelve a revisión con un motivo concreto.
- Una ejecución interrumpida cuyo estado no se confunde con una entrega aceptada.
- Una fuente necesaria que no está disponible para el agente.
- Un resultado cuyo coste o consumo no se ha recibido.
Un piloto con un resultado concreto
Para probar la documentación asistida, utiliza un proyecto acotado y una sección que el equipo conozca. Crea el work item, identifica las fuentes autorizadas y define cómo se comprobarán los ejemplos. El runtime compatible prepara el borrador con las herramientas que tenga habilitadas. Una persona revisa el contenido y registra su decisión donde el flujo lo permita.
La wiki de BIKLABS está en Preview. La escritura automática de documentación, la colaboración en tiempo real y los bucles que coordinan agentes de forma duradera siguen siendo recorridos que requieren desarrollo o validación. Un piloto puede mantener una entrega manual del borrador mientras comprueba el valor de la estructura compartida.
Mide el proceso completo: preparación, espera, revisión, corrección y coste de ejecución conocido. Compáralo con una tarea equivalente realizada mediante el proceso anterior. Un borrador que llega pronto pero exige más revisión puede empeorar el resultado global; una cifra de velocidad aislada no permite decidir.
Coordinación y obligaciones legales
Conservar contexto y decisiones puede ayudar a preparar evidencia, pero la organización debe determinar qué obligaciones corresponden a su uso concreto de IA. Los estados de una tarea o un gate de aprobación no acreditan por sí solos el cumplimiento de una norma. La guía sobre el AI Act para equipos de ingeniería (en inglés) desarrolla esa distinción y enlaza las fuentes oficiales.
La gestión agéntica resulta útil cuando el equipo puede continuar el trabajo, revisar una entrega y explicar una decisión sin reconstruir todo desde cero. Empieza por esa capacidad observable y amplía la automatización cuando el recorrido haya demostrado que funciona.
Explora los agentes y su disponibilidad en BIKLABS →¿Quieres verlo en acción?
Descubre cómo BIKLABS integra agentes IA en tu flujo de trabajo.