Agentes del chat al código: cómo conservar la procedencia

Cuando un agente solo resume un hilo, una interpretación imperfecta produce una respuesta discutible. Cuando ese mismo hilo puede iniciar una sesión, crear un issue o abrir un pull request, la interpretación se convierte en una decisión operativa. Un archivo compartido hace semanas, una instrucción retractada o el repositorio predeterminado del canal pueden terminar influyendo en código real. El problema ya no es cuánto contexto cabe, sino qué parte era vigente, quién podía aportarla y para qué acción se autorizó.

GitHub anunció el 25 de septiembre de 2026 que Copilot para Slack y Microsoft Teams puede usar más archivos, adjuntos, enlaces, imágenes reenviadas e historial, conservar un vínculo hacia la conversación de origen y manejar mejor respuestas interrumpidas u obsoletas. Esta publicación se consultó el 28 de septiembre, tres días calendario después en Lima; la fuente no expone una hora confiable, por eso no atribuimos una antigüedad exacta. Es una mejora relevante, pero no demuestra por sí sola que cualquier flujo chat-a-código esté listo para producción.

La integración captura la conversación y la combina con una identidad, un repositorio, una rama y una sesión en un sandbox. En un mensaje directo puede actuar con los permisos de la cuenta personal vinculada; en un contexto compartido crea artefactos con la identidad de la aplicación. GitHub documenta además que todo el hilo alimenta la decisión y queda almacenado en los artefactos generados. Esas decisiones de producto forman un sobre de ejecución, aunque la interfaz las presente como una mención dentro del chat.

La arquitectura útil separa cuatro capas: evidencia conversacional, intención aprobada, autoridad efectiva y resultado verificable. Un mensaje puede aportar evidencia sin conceder permisos. Una persona con write puede iniciar el trabajo sin convertir cada frase previa en requisito. La aplicación puede crear una rama sin tener capacidad para fusionarla. Y el pull request puede enlazar el hilo sin asumir que el hilo es una especificación consistente. Si esas capas se mezclan, el equipo obtiene una automatización cómoda pero difícil de auditar o detener.

No envíes un hilo mutable como una bolsa opaca. En el momento de iniciar la sesión, registra identificadores de mensajes, versión o hash de adjuntos, autores, marcas de tiempo y el rango exacto capturado. Añade una lista explícita de exclusiones: mensajes borrados, contenido fuera del hilo, enlaces no resueltos y archivos a los que el agente no pudo acceder. El objetivo no es copiar cada dato para siempre, sino poder responder qué evidencia vio esta ejecución y cuál quedó fuera.

Después normaliza la intención en un contrato pequeño: objetivo, no-objetivos, repositorio, rama base, operaciones permitidas y criterio de finalización. Pide confirmación cuando el contrato sea ambiguo o cuando dos mensajes recientes se contradigan. Un enlace de retorno ayuda a investigar, pero no sustituye el snapshot: el hilo puede seguir cambiando mientras el agente trabaja. Trata la conversación como procedencia y el contrato confirmado como entrada de ejecución.

En un canal compartido, muchas personas pueden añadir contexto aunque solo algunas puedan iniciar cambios. Esa asimetría es razonable si queda visible: aportar una restricción no equivale a autorizar una escritura. Registra quién disparó la sesión, bajo qué identidad actuó el agente y qué participantes pudieron influir en el sobre. Para acciones de alto impacto, exige que el iniciador confirme el contrato después de incorporar contribuciones ajenas, en lugar de inferir consenso por la mera presencia del hilo.

Aplica mínimo privilegio por etapa. Leer el repositorio, crear una rama, empujar commits, abrir un pull request, modificar CI y fusionar son capacidades distintas. La documentación de GitHub indica que los PR creados desde contexto compartido usan la identidad de la app y pueden requerir una aprobación adicional mediante rulesets. Mantén esa separación: una integración conversacional debería producir un cambio revisable, no adquirir silenciosamente la capacidad de aprobar su propio resultado.

Los repositorios predeterminados reducen fricción, pero también pueden convertir una omisión en una escritura sobre el sistema equivocado. Muestra siempre repositorio y rama antes de ejecutar, y vuelve a pedir confirmación si cambian durante la sesión. Usa una sesión por tarea, una rama dedicada y un identificador que viaje desde el hilo hasta el commit y el pull request. No permitas que cambiar el destino reutilice credenciales, estado de herramientas o planes construidos para el repositorio anterior.

La revocación debe cortar capacidad, no solo ocultar una respuesta. Si alguien cancela, reemplaza la sesión o cambia el repositorio, invalida el token de ejecución, bloquea nuevas llamadas de herramientas y marca los artefactos parciales como abandonados. El anuncio señala mejoras para impedir que sesiones reemplazadas sigan actuando en el repositorio anterior. Ese es el contrato correcto: una respuesta obsoleta no debe llegar tarde con efectos todavía válidos.

Una prueba funcional responde si el parche satisface el contrato. Una prueba de procedencia responde si cada decisión material puede remontarse al mensaje, archivo o confirmación que la justificó. Una prueba de autoridad confirma que ninguna herramienta superó el alcance declarado. Y una prueba de ciclo de vida verifica que cancelar, reemplazar o desconectar la sesión impide efectos posteriores. No combines estas señales en una puntuación única: un parche correcto puede haberse producido con contexto prohibido o permisos excesivos.

Construye una suite con hilos incompletos, requisitos contradictorios, adjuntos reemplazados, usuarios sin permiso, repositorios homónimos, reconexiones tardías y dos sesiones que compiten. Mide al menos selecciones de destino incorrectas, acciones después de revocación, decisiones sin fuente, solicitudes de aclaración apropiadas y cambios aceptados tras revisión. El gate de release debe exigir cero escrituras fuera de alcance y evidencia suficiente para reconstruir los casos aceptados; la utilidad se analiza aparte.

Supongamos que soporte comparte en Teams una captura de una exportación CSV con zonas horarias incorrectas. Producto añade que el formato histórico debe conservarse y una ingeniera enlaza el repositorio de reportes. El agente no debería interpretar todo el canal. Congela esos tres aportes, identifica la captura como dato potencialmente sensible, redacta un contrato que limita el cambio al formateador de fechas y pide confirmar repositorio, rama base y ausencia de cambios de esquema. Solo después abre una sesión con lectura y escritura en una rama aislada.

Durante la ejecución, otro mensaje propone migrar toda la exportación. Esa idea queda fuera del snapshot y se registra como trabajo separado. Si el equipo cambia el destino a un repositorio legado, la sesión actual se revoca y no hereda su token. El pull request incluye el enlace al hilo, el hash del adjunto, el contrato confirmado, las pruebas ejecutadas y una nota de que la captura no se incorporó al repositorio. La revisión humana evalúa tanto el resultado como la cadena de decisiones. Este escenario es ilustrativo; no describe un cliente ni una implementación de Wasyra.

Las integraciones siguen en vista previa y algunas capacidades se despliegan gradualmente. Tampoco resuelven por sí solas retención, clasificación de datos, residencia, secretos dentro de adjuntos o la coherencia de una conversación humana. Un enlace hacia el origen mejora trazabilidad, pero no certifica que la fuente fuera correcta. Un sandbox reduce exposición del entorno, pero no corrige un repositorio equivocado ni una identidad con permisos amplios.

Antes de adoptar el flujo, pide una demostración con tus propios controles: snapshot de contexto, contrato confirmado, separación de identidades, alcance explícito, revocación efectiva y artefacto revisable. Si el equipo no puede reconstruir por qué el agente tomó una decisión o demostrar que una sesión cancelada perdió capacidad, el chat todavía es una interfaz de conveniencia, no un plano de control confiable.

El valor aparece cuando la conversación acelera el descubrimiento sin borrar las fronteras de ingeniería. Empieza con tareas pequeñas, reversibles y protegidas por revisión; conserva el hilo como evidencia, pero promueve solo el contrato confirmado a entrada ejecutable. Si necesitas diseñar ese recorrido para una operación propia, el servicio de agentes a medida de Wasyra puede ayudar a convertirlo en un sistema medible, con permisos y gates acordes al riesgo.