El primer agente en un equipo es una historia de productividad personal. El quinto ya es una historia organizativa. En algún punto entre ambos, un grupo deja de ser un equipo que usa IA y se convierte en un equipo agéntico: personas y agentes trabajando en el mismo tablero, sobre las mismas tareas y bajo reglas que alguien tuvo que poner por escrito.
Esa transición es donde viven la mayoría de las preguntas interesantes. ¿Quién es dueño del trabajo que ejecutó un agente? ¿Qué contiene un standup cuando el tablero se actualiza solo? ¿Cuántos agentes puede absorber un revisor? Esta guía aborda la composición de un equipo agéntico, la división del trabajo que sobrevive al contacto con el trabajo real y los acuerdos de trabajo que merece la pena copiar. Sharkly es la plataforma que construimos para este tipo de equipo, y los modos de fallo que verás a continuación surgen de observar cómo este modelo se rompe.
TL;DR
Un equipo agéntico es un grupo en el que las personas y los agentes de IA tienen trabajo asignado dentro de un mismo sistema compartido, y en el que las personas conservan la dirección, la autoridad y la aceptación. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. Los requisitos prácticos son: un registro de tarea que ambos puedan leer, un asignado de ejecución distinto de la persona responsable, un estado de revisión que llegue a alguien y un alcance escrito lo bastante claro como para que el agente no tenga que adivinar.
De qué se compone un equipo agéntico
Hay tres tipos de participantes, y conviene nombrarlos con precisión.
Las personas crean y actualizan tareas, comentan, reciben elementos en su cola, reciben trabajo asignado, revisan los resultados de los agentes y gestionan los ajustes que su rol permite. Son los únicos participantes que pueden rendir cuentas.
Los agentes son configuraciones de trabajo guardadas, no prompts puntuales: instrucciones, un runtime como Claude Code o Codex, repositorios, entorno, ajustes de ejecución y habilidades vinculadas. Un agente se parece más a un rol documentado que a una persona. Nuestra explicación de Sharkly Agents cubre qué incluye uno.
Los crews agrupan agentes bajo un agente líder para el trabajo que necesita coordinación. La ejecución empieza por el líder: este lee la tarea y las instrucciones del crew y, a partir de ahí, o se encarga él del trabajo o incorpora a miembros concretos. Ese orden existe para evitar que todos los miembros empiecen a la vez. Los detalles están en nuestra guía sobre Sharkly Crews.
El acceso se superpone a todo esto: el rol en la organización determina la capacidad administrativa general, y la pertenencia a un espacio determina a qué áreas de trabajo puede llegar cada persona. Los agentes se delimitan de la misma forma, a repositorios concretos y máquinas concretas.
La división del trabajo que funciona
El contrato que aplica Sharkly en su propio equipo es un buen valor por defecto porque es lo bastante acotado como para poder hacerlo cumplir: los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, conceden autoridad y aceptan el resultado.
Hay cuatro responsabilidades que siguen siendo de las personas por muy capaces que lleguen a ser los agentes.
- Dirección. Decidir qué merece la pena hacerse y en qué orden.
- Contexto. Escribir un alcance sobre el que el agente pueda actuar: por qué importa el trabajo, qué queda fuera de alcance, los archivos y restricciones relevantes y cómo se revisará la finalización.
- Aceptación. Leer la evidencia y decidir que el trabajo está hecho. Una ejecución terminada no es un resultado aceptado.
- Escalado. Decidir qué ocurre cuando un agente se bloquea, se equivoca o se topa con una pregunta que requiere criterio.
Todo lo demás es negociable y depende de cuánto confíe tu equipo en el historial de un agente concreto en un tipo de trabajo concreto.
Cómo circula el trabajo por el equipo
El ciclo es corto y merece la pena explicarlo, porque los equipos que se saltan un paso lo notan en una semana.
- Una persona escribe una tarea con un resultado esperado y criterios de aceptación.
- La tarea recibe un asignado humano como responsable y un agente o crew como asignado de ejecución. Son campos independientes, y cambiar uno no cambia el otro.
- Sacar la tarea de un estado de backlog en espera inicia la ejecución cuando el agente asignado está listo.
- La ejecución se lleva a cabo en una máquina conectada, en un directorio aislado, y el progreso y los bloqueos vuelven a la tarea.
- El agente deja el trabajo en espera de respuesta humana o en espera de revisión humana, lo que llega a la bandeja de entrada de agentes de la persona responsable.
- Una persona lee la traza y el diff, y luego acepta, comenta para continuar o reasigna.
Los comentarios son la conversación duradera. Un comentario en una tarea con un agente listo puede encolar la siguiente ejecución, lo que convierte el feedback de revisión y la ejecución en un mismo movimiento en lugar de dos sistemas separados.
Tres modelos que funcionan
El desarrollador emparejado. Cada desarrollador mantiene uno o dos agentes para su propio trabajo recurrente: cobertura de pruebas, actualizaciones de dependencias, refactorizaciones que ya ha hecho veinte veces. El beneficio para el equipo es que esas definiciones de agentes se comparten, así que una persona recién incorporada hereda cinco configuraciones que funcionan desde el primer día en lugar de tener que crear las suyas.
El squad con un crew compartido. Un crew se encarga de una categoría de trabajo de la que depende todo el squad, como la preparación de releases o el triaje de incidentes. Un agente líder decide qué miembro aporta, y una persona es la propietaria de esa categoría. Este es el modelo que más escala antes de que la capacidad de revisión se convierta en el cuello de botella.
El equipo de plataforma que estandariza. Un equipo de plataforma o de developer experience es propietario de las definiciones de agentes, las habilidades y la configuración de máquinas de varios equipos de producto. Los equipos de producto asignan trabajo; el equipo de plataforma mantiene al día los runtimes, los permisos y las instrucciones. Este modelo cambia algo de autonomía por consistencia, y suele ser el intercambio correcto a partir de unos treinta ingenieros.
Ninguno de los tres requiere reorganizar nada. Son patrones sobre quién es propietario de la configuración de los agentes, que es la pregunta que decide si la capacidad de los agentes se acumula en todo el equipo o se queda en el ámbito personal.
Acuerdos de trabajo que conviene adoptar
Una persona que rinde cuentas por tarea. Aunque el trabajo lo haga un crew de cuatro agentes. Y sobre todo en ese caso.
El alcance se escribe antes de asignar. Si nadie sabe decir cómo se va a comprobar el resultado, la tarea no está lista para un agente. Solo esta regla elimina la mayoría de las malas ejecuciones.
La revisión es capacidad planificada, no tiempo libre. Decide cuánto trabajo de agentes puede absorber cada revisor al día y respeta esa cifra. Una pila creciente de resultados de agentes sin revisar es la misma deuda que los pull requests sin fusionar, y crece más rápido.
Las ejecuciones fallidas se diagnostican, no se reintentan. Abre el registro de ejecución y lee primero el título y los detalles técnicos. Los errores de proveedor que se parecen a menudo requieren soluciones opuestas, así que reintentar por reflejo oculta la causa real.
Las definiciones de agentes tienen un propietario y una fecha de revisión. Las instrucciones se pudren. El desarrollador que escribió el agente de migración se va, las convenciones cambian y el agente sigue aplicando con total seguridad las reglas del trimestre pasado.
Qué es lo primero que se rompe cuando el equipo crece
La capacidad de revisión es siempre lo primero. La segunda restricción es la capacidad de máquinas: las ejecuciones se encolan mientras esperan concurrencia o un directorio de trabajo libre, y un equipo que añadió agentes sin añadir computadoras descubre una cola que no puede ver desde el tablero.
El tercero es la deriva de propiedad. Cuando varios agentes contribuyen a tareas relacionadas y nadie cambia el propietario tras un traspaso, acabas con trabajo que técnicamente está asignado y en la práctica no es de nadie. Una revisión semanal de las tareas con asignados de tipo agente y propietarios humanos obsoletos lleva diez minutos y evita la versión desastrosa de este problema. Si prefieres partir de un sistema que ya separa estos campos, descarga Sharkly y durante una semana haz pasar por él un tipo de trabajo recurrente.
Preguntas frecuentes
¿Cuántos agentes por desarrollador son razonables? Empieza con uno o dos y deja que el ritmo de revisión marque el techo. El número correcto es aquel en el que los resultados no esperan más de una jornada laboral a que una persona decida.
¿Los agentes asisten al standup? Su trabajo sí. El tablero ya muestra el estado, así que el standup se convierte en la lista de excepciones: fallos, ejecuciones bloqueadas y resultados que esperan a alguien.
¿Debería un agente ser alguna vez el único asignado? No. Mantén a una persona como responsable del resultado, con el agente en el puesto de ejecución. Nuestra guía sobre gestión de proyectos con agentes de IA explica por qué esa separación importa más a medida que crece el volumen.
¿Cómo incorporamos a un nuevo agente al equipo? De la misma forma que incorporas a una persona: dale una primera tarea acotada, revisa de cerca y luego amplía el alcance. Guarda lo que funcionó como las instrucciones y habilidades del agente, para que el siguiente equipo no tenga que descubrirlo de nuevo.
