Microsoft Copilot Harness se abre a través de Foundry y cambia la decisión entre desarrollar o comprar

Microsoft abrió su Microsoft Copilot harness a través de Foundry el 28 de octubre, extendiendo a los desarrolladores una base de ejecución interna mientras mantiene el control de su operación. Un harness es el software que rodea a un modelo de IA y organiza las instrucciones, el contexto, las herramientas y la ejecución. El anuncio cambia lo que las empresas pueden comprar en lugar de desarrollar, sin eliminar su responsabilidad sobre el trabajo resultante.

La decisión central consiste en mantener internamente esa maquinaria de ejecución o adoptar el enfoque gestionado de Microsoft. Un agente, software que utiliza modelos y herramientas para realizar una tarea, necesita más que acceso a un modelo competente. Alguien debe decidir cómo continúa, cómo maneja los fallos y cómo se mantiene dentro de los límites empresariales.

Anthropic ya ofrece un enfoque gestionado competidor, lo que brinda a los compradores una referencia útil más allá de la familia de productos de Microsoft. La propuesta distintiva de Microsoft hace hincapié en el acceso a diferentes familias de modelos mediante infraestructura compartida. Para los equipos de desarrollo, esto plantea una cuestión práctica: ¿qué responsabilidades se vuelven más fáciles de delegar y cuáles siguen requiriendo criterio específico de la aplicación?

Microsoft Copilot Harness entra en la vista previa pública de Foundry

Microsoft está convirtiendo una base compartida de productos en un bloque de construcción gestionado para aplicaciones de clientes.

Según el anuncio del harness multimodelo de Microsoft, el equipo de ingeniería de GitHub desarrolló el harness antes de que Microsoft lo adoptara en las experiencias de Copilot. La empresa identifica entre sus usuarios a Copilot Code, Copilot Studio, la aplicación GitHub Copilot, la interfaz de línea de comandos y VS Code.

Foundry Agent Service, la plataforma de Microsoft para crear y operar agentes, ofrece ahora el harness en vista previa pública. Ese estado es importante porque el anuncio combina una tecnología interna consolidada con un servicio gestionado disponible recientemente. La experiencia dentro de los productos de Microsoft no establece automáticamente su preparación para la carga de trabajo de cada cliente externo.

Microsoft describe una división de responsabilidades en la que opera la maquinaria de ejecución mientras los clientes aportan sus instrucciones y conexiones específicas de la aplicación. Este acuerdo hace que el lanzamiento sea relevante más allá de los asistentes de programación. Una empresa que desarrolla un asistente de investigación o un agente operativo puede plantearse comprar infraestructura que antes se consideraba trabajo interno de ingeniería.

El anuncio también describe un kit de desarrollo de software descargable, un paquete que los desarrolladores utilizan para integrar la tecnología en las aplicaciones. Esa vía no debe confundirse con la experiencia gestionada de Foundry. Elegir un método de distribución y decidir quién opera un servicio son decisiones relacionadas, pero responden a preguntas distintas.

Para un comprador empresarial, el cambio inmediato es una opción adicional de implementación. Un equipo que evalúa un agente ya no necesita asumir que dar soporte a distintos modelos exige mantener su propio sistema de ejecución circundante. Microsoft se ofrece a mantener esa base compartida en nombre del cliente.

La oferta merece una lectura precisa. Comprar un harness gestionado no establece que un flujo de trabajo concreto produzca respuestas correctas o acciones adecuadas. Cambia quién proporciona parte de la maquinaria. El comprador aún necesita evidencias de que la aplicación completa cumple sus propios requisitos.

Consideremos una aplicación hipotética de investigación que compara anuncios de proveedores y prepara un informe interno. Su resultado útil incluye fuentes precisas, fechas claras y un tratamiento explícito de información contradictoria. Un sistema de ejecución funcional respalda ese trabajo, pero no puede definir esos requisitos editoriales para la organización.

Por tanto, el lanzamiento desplaza el punto de partida de las discusiones arquitectónicas. En lugar de preguntarse únicamente qué modelo debe responder a una solicitud, los equipos pueden preguntarse qué partes de la ejecución de agentes merecen ingeniería personalizada. Esa es una cuestión más trascendental que determinar si aparece otro modelo en un menú de selección.

La presión recae sobre los equipos que mantienen su propia maquinaria de ejecución

La oferta de Microsoft somete a escrutinio los proyectos internos de infraestructura, especialmente cuando reproducen capacidades sin crear una ventaja empresarial.

La mayor presión recae sobre los equipos de aplicaciones que ya mantienen la maquinaria circundante de los agentes. Sus responsables cuentan ahora con una alternativa externa que examinar. Continuar con una implementación personalizada se convierte en una decisión que requiere justificación, en lugar de ser un requisito automático para poner en producción un agente.

Esa justificación puede seguir siendo convincente. Una empresa podría requerir un comportamiento de ejecución inusual, integraciones especializadas o control directo sobre cómo avanza el trabajo. La distinción relevante es si esos requisitos afectan materialmente a la aplicación. La propiedad personalizada tiene más sentido cuando la organización puede identificar qué logra ese control.

Comprar infraestructura introduce una obligación diferente: comprender los límites del proveedor. Un equipo de desarrollo no puede evaluar un servicio gestionado únicamente a través de las capacidades mostradas en una demostración. Debe identificar dónde termina la plataforma y dónde empiezan su propio software, procedimientos y supervisión.

El anuncio de ejecución gestionada de agentes de Microsoft describe skills, herramientas conectadas, ejecución de archivos y código, y delegación limitada. Las skills son procedimientos reutilizables empaquetados con instrucciones y recursos de apoyo. Las herramientas brindan a los agentes acceso a información o acciones externas. Estas capacidades describen una base de aplicación más amplia que la generación de texto por sí sola.

El mismo anuncio ofrece una perspectiva inicial de un cliente. Chris Evans, director de tecnología de Confluence Technologies, afirma que la empresa tenía una solución funcionando en menos de una semana. Es una anécdota útil sobre la implementación, aunque no establece un calendario de despliegue típico ni un resultado operativo a largo plazo.

Para los compradores, la distinción importante está entre alcanzar un estado funcional inicial y mantener un servicio confiable. Un prototipo interno puede tolerar supuestos que una aplicación operativa no puede. Una base gestionada puede acortar parte del trabajo de ingeniería y, al mismo tiempo, dejar sin resolver las revisiones de integración, los criterios de aceptación y las decisiones de propiedad.

Por ello, una comparación financiera útil examinaría el flujo de trabajo completo en lugar de una sola respuesta de modelo. Las consideraciones relevantes incluyen el mantenimiento de ingeniería, la investigación de fallos, la revisión humana y los cambios en los sistemas conectados. Del lanzamiento no se desprende un cálculo universal porque esas responsabilidades difieren entre organizaciones.

La presión también alcanza a los proveedores de infraestructura cuyos productos rodean a los modelos. La distribución de Microsoft da a los clientes otra razón para cuestionar qué componentes independientes necesitan. Esto no establece que los productos independientes se vuelvan innecesarios. Eleva el estándar para explicar el control, la visibilidad o la especialización adicionales que aportan.

Para los trabajadores del conocimiento, lo que está en juego aparece de otra forma. Experimentan si un agente completa un entregable utilizable, conserva las evidencias adecuadas y escala la incertidumbre de manera apropiada. Un cambio arquitectónico les importa cuando reduce el trabajo incompleto o facilita identificar y corregir errores.

Por eso la discusión entre desarrollar o comprar corresponde tanto a los responsables de producto como a los ingenieros. La organización debe definir un resultado satisfactorio antes de decidir qué acuerdo de infraestructura lo proporciona. De lo contrario, un despliegue técnicamente exitoso puede dejar el problema empresarial real en gran medida sin resolver.

La elección de modelo y el control del entorno de ejecución son decisiones separadas

El acceso a distintos modelos no otorga a los clientes un control ilimitado sobre cómo el servicio gestionado ejecuta su trabajo.

Las preguntas frecuentes sobre disponibilidad del harness de Microsoft delimitan la vista previa. No está disponible el soporte para aportar modelos propios. Los clientes seleccionan el harness al crear un nuevo agente de prompts y no pueden cambiarlo posteriormente. La disponibilidad también puede variar según la región, el cliente, las herramientas, las redes y las cuotas.

Estas restricciones aclaran el significado del soporte multimodelo. Un cliente puede evaluar las opciones compatibles dentro de los límites del servicio. Esto difiere de asumir que cualquier modelo, conexión o acuerdo de despliegue funcionará simplemente porque la estrategia más amplia hace hincapié en la elección.

La distinción importa durante la adquisición. La presencia de un modelo en otra parte de la cartera de un proveedor no responde a si está admitido en una experiencia gestionada concreta. Los compradores deben evaluar la combinación que pretenden utilizar, incluida la ubicación de despliegue pertinente y los sistemas conectados.

También existe una distinción entre cambiar un modelo y preservar el comportamiento de una aplicación. Aunque una interfaz se mantenga coherente, un modelo diferente puede producir decisiones o resultados distintos. Los propietarios de aplicaciones deberían tratar un cambio de modelo como algo que debe evaluarse frente a requisitos empresariales, en lugar de como una sustitución administrativa.

Consideremos un asistente hipotético de adquisiciones que revisa una propuesta de un proveedor. Una tarea consiste en extraer fechas de entrega. Otra implica interpretar una cláusula de cancelación ambigua. La organización podría preferir distintas características de modelo para esas actividades, pero aún necesita una definición coherente de evidencia aceptable y escalamiento.

Una base de ejecución compartida puede facilitar la organización de esa comparación. No establece que las mismas instrucciones funcionen igual de bien en todos los modelos compatibles. El resultado útil es una oportunidad controlada para comparar resultados, con registros claros de qué cambió y por qué.

La arquitectura de agentes gestionados de Anthropic proporciona una comparación competitiva relevante. Su informe técnico de abril de 2026 describe la separación del modelo y el harness de los entornos de ejecución y los registros persistentes de sesiones. El objetivo declarado es permitir que las implementaciones evolucionen detrás de interfaces estables.

Esta comparación muestra por qué la competencia del sector se extiende más allá de la selección de modelos. Los proveedores también compiten por las responsabilidades de ejecución que pueden asumir mientras preservan una interfaz en la que los clientes puedan confiar. El énfasis de Microsoft en múltiples familias de modelos aborda una dimensión de esa decisión de compra más amplia.

Ninguna de las descripciones arquitectónicas establece un ganador universal. Una empresa que elige entre enfoques gestionados debe comparar su flujo de trabajo real, las integraciones necesarias y las restricciones operativas. Un servicio que encaja bien con una aplicación puede imponer supuestos inadecuados a otra.

La disyuntiva más profunda se refiere a dónde reside la flexibilidad. Un equipo puede conservar opciones entre modelos compatibles mientras acepta el diseño de ejecución del proveedor. Como alternativa, puede preservar mayor control sobre la ejecución y asumir la responsabilidad de mantenerlo. Son formas distintas de flexibilidad, con consecuencias de ingeniería diferentes.

Para el harness de Microsoft Copilot, la interpretación práctica más sólida es, por tanto, la elección acotada. Los clientes obtienen una ruta gestionada adicional para el desarrollo de agentes. Deben evaluar esa ruta según sus capacidades documentadas, en lugar de interpretar la marca más amplia como una promesa de compatibilidad universal.

Las mejoras de evaluación de Microsoft requieren una interpretación cuidadosa

Los resultados internos de Microsoft respaldan una evaluación adicional, pero no establecen mejoras equivalentes para todas las aplicaciones de Foundry.

En sus resultados de evaluación de agentes, Microsoft compara el harness de Copilot con el harness Standard en Copilot Studio. Informa mejoras en la tasa de aprobación de 10,8 puntos porcentuales con un modelo de OpenAI y de 22,1 puntos porcentuales con un modelo de Anthropic.

Microsoft también informa de intentos continuados después de llamadas a herramientas fallidas en el 84–91 % de los casos evaluados, frente a menos del 7 % con el harness Standard. Sus notas complementarias distinguen explícitamente entre el uso continuado de herramientas y los reintentos exitosos, por un lado, y la finalización exitosa de la tarea global, por otro. Se trata de hallazgos comunicados por la empresa, sin validación independiente establecida aquí.

Esta salvedad es fundamental para interpretar el anuncio. La persistencia describe el comportamiento después de que algo sale mal. La finalización describe si se alcanzó el resultado solicitado. Un sistema puede seguir trabajando y aun así malinterpretar la tarea, usar evidencia inadecuada o producir un resultado inaceptable.

La diferencia se hace concreta en un flujo de trabajo hipotético de atención al cliente. Un agente podría reintentar correctamente el acceso a un registro de caso y aun así recomendar la resolución equivocada. Medir la recuperación de la conexión fallida ayuda a explicar el comportamiento de ejecución. No determina si el cliente recibió una respuesta precisa.

Del mismo modo, una tasa de aprobación de evaluación más alta depende de lo que la evaluación solicite. Los compradores deben comprender las tareas relevantes, los criterios de aceptación y las configuraciones antes de trasladar un resultado a su propio entorno. Una mejora en puntos porcentuales solo es informativa en relación con la prueba que mide.

Esto no reduce la importancia del sistema de ejecución circundante. La comparación comunicada por Microsoft es coherente con el argumento de que la capacidad del modelo por sí sola no determina los resultados de los agentes. Da a los clientes una razón para probar las opciones de ejecución junto con las opciones de modelo, manteniendo explícitas la atribución y las limitaciones.

Microsoft también describe una aplicación interna de soporte que superó una tasa de resolución totalmente autónoma del 35 % en agosto de 2026. La empresa define esa medida como la resolución de casos sin intervención humana. Es un despliegue concreto comunicado, pero su idoneidad como comparación depende de los casos y las condiciones operativas.

Para una empresa que evalúa una aplicación similar, la autonomía debe considerarse junto con la corrección y las consecuencias. Un caso resuelto sin intervención puede ser evidencia útil cuando la resolución es precisa y adecuada. La ausencia de intervención por sí sola no puede establecer que el resultado cumpliera el estándar de la organización.

La evaluación también debe tener en cuenta el trabajo transferido a los revisores. Si un agente produce más material pero requiere correcciones sustanciales, el volumen de producción puede tergiversar su contribución práctica. La cuestión empresarial se refiere al trabajo terminado y aceptable, y al esfuerzo necesario para obtenerlo.

La misma lógica se aplica a los fallos que permanecen invisibles hasta más tarde. Un informe pulido con una afirmación sin respaldo puede parecer exitoso en el momento de la entrega. Una evaluación que compruebe la evidencia y la atribución revelaría un resultado distinto. Los criterios de aceptación deben reflejar cómo se utilizará realmente el resultado.

Por ahora, las cifras de Microsoft son evidencia útil sobre sus propios entornos probados. Justifican una investigación sin sustituir las pruebas específicas de cada cliente. Los compradores deberían evitar convertir una comparación de un proveedor en una previsión para cargas de trabajo que no formaron parte de la evaluación comunicada.

La ejecución gestionada mantiene la responsabilidad empresarial en manos del cliente

Delegar la infraestructura no transfiere la responsabilidad de decidir qué está autorizado a hacer un agente.

El límite más claro se refiere a las acciones con consecuencias. Un agente que prepara una recomendación y otro que compromete a la organización con esa recomendación requieren controles diferentes. Un servicio de ejecución gestionada puede respaldar cualquiera de los dos diseños, pero la organización debe decidir dónde comienza y termina la autoridad.

Fashable ofrece una perspectiva de cliente dentro del material de lanzamiento de Microsoft. El director ejecutivo Orlando Ribas Fernandes describe oportunidades relacionadas con los flujos de abastecimiento, mientras mantiene las decisiones comercialmente vinculantes bajo control humano. Se trata de un límite operativo previsto, no de evidencia de que cada capacidad propuesta ya haya producido un resultado medido.

El ejemplo ilustra por qué la rendición de cuentas no puede inferirse de la automatización. Un asistente de abastecimiento podría comparar especificaciones, identificar información faltante o preparar material de negociación. Autorizar una compra introduce una responsabilidad distinta. La distinción debe seguir siendo visible incluso cuando esas actividades aparezcan en una sola conversación.

El trabajo de larga duración introduce otro límite: recordar lo que ocurrió frente a saber qué sigue siendo válido. Un agente puede conservar un resultado anterior sin saber que las circunstancias han cambiado. Los responsables de las aplicaciones deben determinar cuándo la información anterior requiere una nueva comprobación y qué decisiones dependen de evidencia actual.

La investigación de Anthropic sobre agentes de larga duración describe fallos relacionados con trabajo incompleto y declaraciones prematuras de finalización entre sesiones. Su enfoque propuesto utiliza registros explícitos de progreso y trabajo incremental. La lección más amplia es que la ejecución continuada requiere un registro fiable de las obligaciones pendientes.

Para las empresas, esa lección sugiere tratar la finalización como una condición empresarial. Una tarea termina cuando se cumplen sus criterios de aceptación, incluida cualquier revisión o confirmación requerida. Un mensaje final seguro de sí mismo no puede sustituir la evidencia de que se cumplen esas condiciones.

Reiniciar trabajo interrumpido plantea una preocupación relacionada. Imaginemos un agente hipotético que prepara un informe y lo envía a otro sistema. Si el envío tiene éxito pero se pierde la confirmación, repetir la acción puede crear registros duplicados. La aplicación necesita una forma de distinguir una acción sin terminar de una no confirmada.

Microsoft anunció por separado la disponibilidad general de resiliencia de larga duración para agentes alojados, donde los clientes aportan su propia lógica de ejecución. Su documentación atribuye al código de la aplicación la responsabilidad de guardar el progreso y prevenir duplicados. Esa función independiente no debe tratarse como una garantía general para la nueva vista previa del harness.

La calidad de la información crea una responsabilidad adicional. Un agente conectado a orientaciones desactualizadas puede ejecutar sus instrucciones de forma coherente y aun así producir trabajo inadecuado. Los equipos que consideren una base de conocimiento con capacidad de búsqueda deben tratar la organización y el mantenimiento de las fuentes como parte de la aplicación.

Esta relación hace que la gestión del conocimiento sea relevante para el lanzamiento sin implicar una integración concreta. La infraestructura determina cómo avanza el trabajo; la evidencia disponible limita lo que el agente puede concluir razonablemente. Mejorar una no elimina las debilidades de la otra.

Por tanto, las organizaciones deberían asignar responsabilidades en todo el flujo de trabajo. Alguien debe asumir la responsabilidad del material fuente, los permisos, los criterios de aceptación y la corrección cuando los resultados fallen. La ejecución gestionada puede cambiar la carga de ingeniería, pero no elimina estas decisiones organizativas.

El caso de adopción más creíble identifica tanto el trabajo que absorbe el proveedor como las obligaciones que conserva el cliente. Esa claridad facilita juzgar si el servicio reduce la complejidad en conjunto. También evita que un prototipo exitoso se convierta en una aplicación de la que nadie es plenamente responsable.

Tres señales mostrarán si el enfoque gestionado cumple lo prometido

La siguiente evidencia útil se refiere a la madurez del servicio, los resultados comparativos y las operaciones de los clientes, más que a afirmaciones adicionales de lanzamiento.

La primera señal es cómo Microsoft desarrolla la vista previa de Foundry en los próximos meses. Los compradores deberían observar una disponibilidad más clara, configuraciones compatibles, opciones de migración y orientación para producción. Un soporte documentado más amplio reforzaría el argumento para adoptar una base gestionada común en más aplicaciones.

La expansión más significativa abordaría un requisito que actualmente bloquea un despliegue real. Otra configuración compatible importa cuando permite a una organización operar dentro de sus limitaciones técnicas y empresariales. Una lista de funciones más larga, por sí sola, dice menos sobre si una aplicación concreta se vuelve viable.

Si las restricciones de la vista previa siguen siendo significativas para el entorno previsto de un cliente, el argumento para una adopción inmediata se debilita para ese cliente. Se trata de un juicio específico de la carga de trabajo. Una limitación puede ser irrelevante para un prototipo de investigación y decisiva para una aplicación conectada a sistemas operativos sensibles.

La segunda señal es evidencia comparativa que separe los cambios de modelo de los cambios de ejecución. Las evaluaciones deberían dejar claro qué componente cambió y cómo se midió el éxito. Eso ayudaría a los compradores a determinar si el beneficio comunicado procede del harness, del modelo o de su interacción.

Las evaluaciones independientes aportarían confianza, especialmente cuando revelen categorías de fallos y requisitos de revisión. Una comparación centrada en trabajo completado reforzaría el argumento de Microsoft más directamente que otra centrada únicamente en la actividad. Los resultados que muestren una dependencia sustancial de la configuración delimitarían la amplitud con la que debería aplicarse la afirmación.

Los avances competitivos importan dentro de esa misma comparación. Los cambios en la oferta gestionada de Anthropic, o en el enfoque de ejecución de otro proveedor, pueden alterar las alternativas disponibles. Los compradores deberían comparar los servicios con un requisito de aplicación estable para que un mercado cambiante no convierta la evaluación en una persecución interminable de funciones.

La tercera señal son los informes de clientes más allá de la velocidad de despliegue inicial. Los relatos útiles describirían la operación sostenida, resultados aceptables, esfuerzo de corrección y las responsabilidades que conserva el cliente. La evidencia de menor mantenimiento junto con resultados fiables reforzaría el argumento para adquirir la capa de ejecución compartida.

Los relatos sobre un amplio trabajo personalizado requerirían una lectura más cuidadosa. La personalización puede reflejar una valiosa especialización empresarial o carencias en el servicio gestionado. Comprender qué explicación se aplica importa más que simplemente contar cuánto código escribió un cliente.

Estas señales también proporcionan una forma práctica de revisar una decisión anterior. Un equipo puede razonablemente construir hoy su propio sistema de ejecución y adoptar un servicio gestionado más adelante. Otro puede comenzar con infraestructura gestionada y conservarla solo mientras el acuerdo siga cumpliendo sus requisitos.

Evalúe el harness de Microsoft Copilot frente a un flujo de trabajo que su organización conozca bien. Defina un resultado aceptable, identifique qué acciones requieren aprobación y registre dónde sigue siendo necesaria la corrección humana. Compare la opción administrada con su enfoque actual utilizando la misma evidencia y los mismos criterios de finalización. Incluya la calidad de las fuentes, el comportamiento de recuperación y el esfuerzo necesario para investigar errores. Mantenga la decisión vinculada a responsabilidades que su equipo realmente pueda delegar y revísela a medida que evolucionen la documentación de soporte y la evidencia de clientes. El lanzamiento de Microsoft crea una alternativa concreta a mantener internamente toda la base de ejecución. El siguiente paso útil es determinar qué partes de su propio flujo de trabajo mejora esa alternativa y qué evidencia cambiaría su decisión.