Colaboración en equipo

AWR permite que varias personas — y los agentes con los que trabajan — se coordinen en un único proyecto compartido: todos ven las mismas tareas, reservan el trabajo que están haciendo, informan del progreso sobre la marcha y entregan el trabajo terminado a un revisor independiente. Todo esto lo diriges desde tu conversación habitual con el agente; no necesitas copiar ID de tareas en un navegador.

Disponibilidad: este artículo describe el servicio Team, que aún está en desarrollo. No forma parte del servidor MCP personal 0.5.0 publicado. Las capacidades de abajo se aplican a un proyecto de equipo alojado por tu administrador de proyecto, no a una instalación local personal.

Para las ideas subyacentes (elementos de trabajo, contratos, evidencia, sesiones), lee primero Conceptos. Para el bucle cotidiano de una sola persona, consulta Tu flujo de trabajo diario.

El modelo de colaboración de un vistazo

Cuatro ideas sostienen todo el modelo:

• Líneas de trabajo y trabajo compartido. El proyecto remoto es la autoridad del trabajo compartido: el único lugar donde viven las tareas, las dependencias, el progreso y los resultados. Tu checkout local es solo para código y pruebas; no inicialices un segundo registro de tareas local para reemplazar el proyecto remoto.
• Reservas. Antes de que un agente empiece el trabajo de ejecución, toma una reserva activa sobre la tarea, bajo su sesión. La reserva activa de otra persona no debe ser reemplazada, de modo que dos agentes no puedan trabajar silenciosamente en lo mismo.
• Revisión. La entrega y la aceptación son hechos separados. Una persona autorizada e independiente revisa el trabajo entregado antes de que sea aceptado. Un segundo agente que te pertenece no es un revisor independiente.
• Traspaso. Las sesiones son duraderas: sobreviven a las reconexiones MCP, llevan puntos de control y estado de recuperación, y pueden retomarse — por ti tras un descanso, o inspeccionadas por un compañero — sin perder contexto.

Conéctate una vez

Pide a tu administrador de proyecto una URL MCP del proyecto y tu credencial individual. Cada participante usa su propia credencial, y los permisos del repositorio permanecen separados de los permisos de AWR: unirse al proyecto AWR no concede acceso a Git, y viceversa.

Entre bastidores, un administrador autorizado abre Members en Inspector, te añade, elige tu rol de proyecto y tus líneas de trabajo, y copia una instrucción de conexión personal de un solo uso que contiene el endpoint y tu credencial. La recibes a través de un canal privado. El administrador no puede recuperar su texto en claro después de limpiar el panel de emisión; si pierdes la credencial, puede reemplazarse explícitamente.

Añade el servidor MCP remoto en cualquier cliente de agente que soporte MCP remoto sobre Streamable HTTP con autenticación Bearer:

Estos son ajustes de conexión, no un formato de archivo de configuración ni un comando de shell; cada cliente tiene sus propios ajustes y requisitos de versión. Si tu cliente solo soporta MCP stdio local, esta URL no se puede usar directamente: usa una versión de cliente o una integración que soporte el transporte remoto.

Algunas reglas de seguridad para la credencial:

• Usa los ajustes de secretos soportados por tu cliente o una entrada de agente privada de confianza.
• Nunca pongas la credencial en una URL, una conversación compartida o el repositorio.
• Vuelve a conectar tras cambiar la configuración y luego abre tu checkout de código local en el agente.

Dale a tu agente el resultado

Trabajas en la misma conversación que usas para desarrollar. Describe el resultado y deja que el agente coordine, por ejemplo:

Use the connected AWR Team project to implement the issue API. Refresh the current tasks and resume my existing work, or claim an eligible task matching this request. Read the contract, dependencies and latest checkpoint before editing. Keep progress and evidence in AWR, submit the tested change as a PR, and request independent review.

El agente lee el trabajo compartido, reserva una tarea elegible y mantiene el proyecto actualizado mientras desarrolla localmente. Si encuentra un conflicto real de permisos, dependencias o propiedad, te lo informa en lugar de esquivarlo.

Lo que el agente hace por ti

El agente habla con el servicio Team a través de dos herramientas MCP descubiertas, awr_team_query para lecturas y awr_team_command para escrituras. Cada consulta y comando vuelve a comprobar tus permisos actuales, así que un cambio de rol surte efecto sin que nadie edite la configuración local.

Una sesión típica fluye así:

1. Iniciar o reconectar. El agente consulta capabilities para confirmar su identidad y permisos, luego work.next para reanudar tus propias sesiones o descubrir trabajo visible sin terminar, siguiendo el next_query devuelto. (En servidores antiguos sin work.next, recurre a workstreams.list y a work.list / work.search acotados.)
2. Preparar. Para una tarea seleccionada, work.prepare devuelve el contrato actual, las especificaciones requeridas, las dependencias, el estado de recuperación y un hash de contexto: una instantánea que el agente debe consumir realmente antes de editar. work.prepare y work.observe también pueden devolver un breve elemento guidance (su condición, base factual, acción siguiente y disparador de reevaluación); es un consejo, no derechos de ejecución.
3. Reservar. El agente inspecciona las reservas existentes con claim.inspect, y luego adquiere o renueva una reserva activa bajo su sesión.
4. Ejecutar. Con execution.prepare y una respuesta fresca de execution.start que lleva execution_authorized=true, el agente puede realizar una ejecución dentro del alcance declarado. Tu máquina ejecuta el código y las herramientas: el servicio nunca ejecuta nada por sí mismo. Una reserva por sí sola no es admisión de ejecución.
5. Informar del progreso. El agente envía session.checkpoint con el hash de contexto consumido, la acción siguiente, los cabos abiertos y un breve resumen de progress, agrupando las actualizaciones cuando una fase o prueba se completa, un bloqueo cambia, se necesita tu intervención o la entrega está lista — no en cada llamada de herramienta. Ten en cuenta que los resúmenes de los puntos de control se comparten con los lectores de trabajo autorizados, así que los registros sensibles en bruto no tienen cabida en ellos.
6. Terminar o parar. execution.report registra un resultado terminal con evidencia vinculada a una versión. Las reservas se liberan y las sesiones se terminan solo después de que el trabajo activo y los resultados desconocidos queden resueltos.

Revisión y aceptación

Cuando el trabajo está listo, el agente envía la evidencia y solicita la revisión a través de delivery.submit_and_request_review o review.open. Una persona autorizada e independiente revisa la entrega, y la finalización autorizada sigue la política de aceptación del proyecto.

Mantén estos como hechos separados: implementación, verificación, la fusión en GitHub y la aceptación de AWR. Fusionar un PR no es lo mismo que AWR aceptando la tarea, y tu propio segundo agente no cuenta como revisor independiente.

Traspaso y recuperación

El traspaso funciona porque las sesiones y los puntos de control viven en el proyecto compartido, no en el historial de chat de una persona:

• Reconectar MCP no termina una sesión de trabajo duradera ni renueva su contrato de arrendamiento.
• El estado de recuperación y las entregas registradas tienen prioridad sobre las instrucciones de puntos de control antiguos, de modo que un agente que regresa confía en lo que realmente pasó.
• Si una escritura agota el tiempo de espera, el agente inspecciona el resultado del comando original antes de reintentar exactamente; los recibos reproducidos son hechos históricos, no permiso para ejecutar efectos de nuevo.
• Si los efectos de la ejecución son desconocidos (una interrupción a media tarea), requieren inspección y reconciliación autorizada. Crear una sesión nueva no elude ese requisito.

Dos límites prácticos que conviene conocer: AWR no puede despertar a un agente inactivo (la renovación del arrendamiento usa la programación de tu host, separada de los puntos de control), y una fase bloqueada o en espera es un informe: no crea un elemento de espera ni renueva una reserva por sí misma.

Inspector: la vista de workspace opcional

Inspector es una vista web sobre el mismo proyecto. Iniciar sesión o reservar a través de un sitio web no es un prerrequisito para nada de lo anterior: el agente sigue siendo la superficie de coordinación. Usa Inspector cuando quieras:

• Inspeccionar relaciones entre tareas, propiedad, progreso y resultados registrados.
• Copiar ajustes MCP neutros respecto al cliente y una instrucción de proyecto desde Connect Agent, o un resumen por tarea (copiar texto no crea ninguna sesión ni reserva).
• Como administrador, gestionar miembros y credenciales con ámbito de proyecto en Members.
• Revisar Activity, que separa los registros de acceso autenticado del historial de desarrollo confirmado. Los miembros ordinarios ven su propia actividad autorizada; los auditores del proyecto pueden filtrar por miembro o tarea. Los registros de auditoría excluyen valores de credenciales, conversaciones y entrada/salida arbitraria de herramientas, y los metadatos de las peticiones tienen una retención acotada: no es un archivo de cumplimiento permanente.

Los permisos de administrador y revisión los aplica el servicio central independientemente del cliente que uses, así que las reglas se mantienen tanto si alguien trabaja a través de un agente, de Inspector, o de ambos.

Próximos pasos

• ¿Nuevo en AWR? Empieza con Qué es AWR y el Inicio rápido.
• Conecta tus propias herramientas vía MCP: MCP.
• Trabajando con agentes en el día a día: Agentes y Tu flujo de trabajo diario.
• ¿Algo no funciona? Consulta Solución de problemas.