Su equipo quiere transformar los resultados de un repositorio de demostración en un informe. El agente puede leer las pruebas, preparar un documento y, ahora, interactuar con una aplicación de escritorio. Pero, ¿quién decide que el documento está listo para ser compartido? El paso de un archivo local a una acción en otro software obliga a definir lo que realmente delega.
Tomemos un escenario ficticio: preparar un informe de pruebas en un espacio sin cuenta personal, luego detenerse antes de cualquier compartición. Este recorrido propuesto no se ha ejecutado. Sirve para distinguir tres decisiones: acceder a una aplicación, preparar una operación y autorizar su efecto.
Dos anuncios, dos preguntas diferentes
El 1 de octubre de 2026, GitHub anuncia en versión previa pública las interacciones de Copilot con aplicaciones de escritorio, en Copilot CLI y Copilot app en macOS y Windows. El acceso se basa en autorizaciones de la aplicación y controles de administrador. Este anuncio no cubre el control del escritorio en Linux.
El mismo día, los flujos de trabajo dinámicos pasan a la versión preliminar pública. Permiten describir la orquestación en código: pasos, paralelismo y puntos de revisión. El alcance incluye la CLI, la aplicación y el SDK, el conjunto de herramientas destinado a integrar Copilot en un programa. En la CLI, el anuncio solicita activar las funciones experimentales.
| Objeto anunciado | Pregunta a hacer antes del piloto |
|---|---|
| Interacción con el escritorio | ¿Qué aplicaciones y qué operaciones están accesibles? |
| Flujo de trabajo dinámico | ¿En qué orden se ejecutan las etapas y dónde se detienen? |
| Autorización de la aplicación | ¿Qué perímetro técnico abre exactamente? |
| Revisión del resultado | ¿Quién valida el documento y el efecto empresarial previsto? |
Estas preguntas siguen siendo distintas. Una orquestación programada puede organizar un análisis que se equivoca. Un permiso de aplicación puede abrir varias acciones de las cuales sólo se desea una. El orden del proceso y la exactitud del resultado se verifican por separado.
Describir la acción antes de abrir el acceso
En nuestro ejemplo, « producir el informe » parece sencillo. Sin embargo, esto puede significar leer un archivo, crear un documento, sobrescribir un documento existente o transmitir información. Sus instrucciones deben nombrar la entrada, la salida, la ubicación autorizada y la condición de parada.
Una primera misión podría ser: leer únicamente los resultados sintéticos del repositorio de prueba, redactar un documento en la carpeta de demostración y mostrar una vista previa. El compartir externamente sigue siendo un paso separado. El alcance se vuelve comprensible para la persona que lo revisa, incluso si no conoce la herramienta del agente.
La siguiente matriz es una propuesta de Partitech para este piloto. No describe ajustes automáticos de Copilot.
| Operación | Autorización propuesta | Prueba para revisar |
|---|---|---|
| Leer los resultados sintéticos | En la carpeta del piloto | Lista de archivos utilizados |
| Preparar un informe | En una nueva ubicación local | Documento y fuentes correspondientes |
| Modificar un informe existente | Después de la comparación explícita | Diferencia antes/después |
| Compartir el documento | Nueva decisión humana | Destinatario, contenido y canal |
| Eliminar los datos de trabajo | Procedimiento separado | Lista exacta de los elementos afectados |
Para cada operación, examine su costo de error y su reversibilidad. Corregir un título local requiere poco esfuerzo. Retirar un documento transmitido a un tercero puede volverse imposible. Esta diferencia debe traducirse en un límite visible en el recorrido, en lugar de una frase general sobre la prudencia.
Hacer la orquestación legible para el equipo
Un flujo de trabajo es el recorrido que sigue la tarea. Al describirlo en un programa, puede hacer explícitas algunas etapas: recopilar las entradas, solicitar un análisis, controlar su estructura y luego presentar un resultado a una persona.
Aquí hay un pseudocódigo conceptual, sin sintaxis de SDK y sin llamada ejecutable. Ilustra nuestro proceso propuesto; no es un ejemplo probado de la interfaz de GitHub.
identifier les fichiers autorisés
vérifier que les entrées sont présentes
produire une proposition de rapport
contrôler les références et les sections attendues
présenter le rapport et les changements prévus
attendre une décision explicite
si la décision autorise une action précise : exécuter cette action
sinon : arrêter en conservant le brouillon
El programa puede imponer una etapa de revisión. No reemplaza la revisión en sí misma. Una estructura correcta puede contener una conclusión errónea; una referencia puede señalar hacia la prueba incorrecta. Por lo tanto, pida que cada afirmación útil remita a una entrada verificable, y que la ausencia de un resultado sea señalada en lugar de completada por una suposición.
Un resultado estructurado significa aquí que la salida distingue constatación, fuente y límite. Este contrato facilita un control independiente: otra herramienta u otro lector pueden comparar las secciones con los archivos de entrada. No transforma las oraciones en pruebas.
La documentación de flujos de trabajo dinámicos sigue siendo la referencia para una implementación. Verifique su versión al momento de programar. Un prototipo de orquestación no debe reproducir una firma supuesta de un SDK a partir de un simple esquema pedagógico.
Poner la revisión antes del efecto
La buena frontera se sitúa justo antes del cambio que compromete al equipo. En el piloto, el borrador puede prepararse automáticamente, luego la revisión debe mostrar el documento completo, las fuentes utilizadas y la acción prevista. Mostrar solo «¿continuar?» no permite decidir correctamente.
Una aprobación debe referirse a un objeto definido. Si el contenido, el destinatario o la ubicación cambian después de la revisión, la decisión anterior ya no cubre exactamente la operación. Entonces, se debe prever una nueva presentación. Este principio pertenece a nuestro método de calificación; no presupone que todas las interfaces de Copilot lo aplican automáticamente.
También organice la detención. ¿Qué queda cuando cancela una sesión? ¿Dónde encontrar el borrador? ¿Cómo saber si una operación ya se ha realizado? Una reanudación a ciegas puede reproducir una acción. Antes de reiniciar, verifique el estado real de la salida y la etapa alcanzada.
El entorno de demostración debe hacer que los errores sean observables sin involucrar sus cuentas habituales. Utilice archivos ficticios y una aplicación de prueba, retire los accesos innecesarios y confíe la revocación a una persona identificada. El piloto no requiere ni compra, ni correo electrónico, ni publicación real.
Probar los rechazos tanto como el recorrido esperado
Nuestro protocolo de calificación comienza con el caso autorizado: las entradas están presentes, el documento está preparado y el proceso se detiene en el punto previsto. Registre el resultado observado sin calificarlo como éxito global. Este primer ensayo verifica un solo camino.
Luego agregue una entrada ausente, un archivo fuera del alcance y una solicitud de compartición no autorizada. El objetivo es ver si el sistema se detiene indicando lo que falta, en lugar de ampliar su misión. Revise también un documento externo que contenga una instrucción engañosa, por ejemplo, pidiendo cambiar al destinatario. El documento debe seguir siendo un dato para analizar; no se convierte en una nueva autorización.
El rastro mínimo debe permitir reconstruir las entradas, las decisiones y los efectos. Evite recopilar indistintamente el contenido de todos los documentos. Defina las personas que pueden consultar estos rastros y su duración de conservación en su proceso existente.
Nuestro artículo sobre el sandbox y las trazas de Copilot app explica los anuncios de septiembre. Proporciona un contexto útil, pero sus mecanismos no prueban automáticamente la cobertura de las interacciones con el escritorio anunciadas el 1 de octubre.
Decida continuar cuando el equipo sepa explicar el alcance autorizado, verificar el borrador, detener el recorrido y recuperar un estado de reanudación confiable. Si falta alguno de estos elementos, ajuste el piloto antes de agregar aplicaciones. La nueva capacidad se vuelve útil cuando el límite de delegación sigue siendo visible.
Fuentes y fecha de verificación
Fuentes de GitHub reabiertas el 6 de octubre de 2026: interacción con el escritorio, flujos de trabajo dinámicos y documentación conceptual. Las preversiones pueden evolucionar. Matriz, escenario y pseudocódigo son propuestas originales de Partitech, sin resultado de ejecución reclamado.