Microsoft Foundry mete A2A entrante y publicación a Copilot/Teams: la distribucion ya es parte del stack de agentes
Microsoft anuncio el 3 de junio de 2026 nuevas piezas de distribucion en Foundry: publicación directa a Microsoft 365 Copilot y Teams, autopilot agents y endpoints A2A entrantes. El cambió útil no es otro canal: es tratar identidad, handoff y governance como parte del producto.

Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
La mayoria de plataformas de agentes todavía se obsesiona con la construccion y deja la distribucion como problema ajeno. Microsoft intento cerrar justo esa brecha el 3 de junio de 2026 con un anuncio que mezcla tres piezas: publicación directa a Microsoft 365 Copilot y Teams, autopilot agents en public preview y A2A entrante para exponer agentes de Foundry como endpoints abiertos a otros agentes.
La noticia importante no es “otro canal más”. Es que la distribucion ya entra al stack técnico del agente: identidad propia, aprobaciones, handoff entre agentes y gobierno central desde el principio.

Del chat al trabajo delegado
La parte más útil del anuncio esta en como Microsoft describe la experiencia en Copilot y Teams. No lo vende como un bot que responde preguntas. Lo vende como algo más cercano a “asignale un objetivo al agente”.
Esa diferencia importa bastante. En ese modelo, el agente:
- muestra progreso;
- pide aprobaciones;
- escala a humanos cuando toca;
- y vive dentro de los canales donde ya se coordina el equipo.
Para builders empresariales, eso es mucho mejor que pedir a los usuarios que entren a una consola aparte para hablar con el agente. Si la tarea ya nace en Teams o en Microsoft 365 Copilot, el costo de adopcion baja.
A2A entrante: el detalle técnico más serio
El otro movimiento fuerte es incoming A2A en public preview. Segun Microsoft, cualquier agente de Foundry puede exponerse como endpoint A2A para que otros agentes lo descubran por su agent card y lo invoquen via protocolo abierto.
La lectura práctica es clara: un agente ya no tiene que absorber todo el trabajo el solo ni vivir hardcodeado dentro de una sola plataforma.
Eso habilita dos patrones sanos:
- delegar por especialidad, donde un agente llama a otro por una tarea puntual;
- interoperar entre vendors o frameworks, sin rehacer la integración como caso especial cada vez.
Es un paso distinto a “tengo tools”. Aqui el agente mismo se vuelve superficie invocable.
Identity y governance dejan de ser post-it
Microsoft empuja mucho otra pieza: cada agente recibe una Entra agent identity y queda registrado automaticamente en Microsoft Agent 365 para revision, aprobacion y administracion.
Eso puede sonar burocratico, pero toca un problema real. Cuando una empresa tiene varios agentes:
- quien los descubre;
- quien les aprueba permisos;
- donde se auditan;
- y como se evita que aparezcan diez agentes invisibles haciendo cosas sensibles.
Si esa capa vive fuera del producto, los equipos la resuelven tarde y mal. Si vive dentro del pipeline, por lo menos tienes una base defendible.

Autopilot agents: autonomia con cuenta propia
El anuncio también mete autopilot agents en public preview. La parte llamativa es que operan con identidad propia y hasta cuenta de usuario con correo, calendario, OneDrive y Teams.
Eso suena potente, pero también sube el liston de control. Cuando un agente tiene cuenta propia, deja de ser helper y se acerca a rol operativo. Ahi cambian las preguntas:
- que puede hacer solo;
- donde se le permite actuar;
- como se le pide aprobacion;
- y como se revoca.
Por eso mi lectura no es “Microsoft lanzó agentes más autonomos”. Mi lectura es “Microsoft esta empaquetando el problema completo de distribuir, identificar y gobernar agentes dentro del workplace”.
Donde si veo demanda cualificada
Las busquedas que pueden traer lectores buenos aquí son:
foundry a2amicrosoft foundry teams copilot agentsautopilot agents microsoftagent 365 entra identity
No es contenido para curiosos de IA generica. Es trafico de gente evaluando como poner agentes donde ya trabaja su organización sin abrir otra isla de tooling.
Si estas comparando stacks, esta nota conversa bien con Workspace agents en ChatGPT. Las dos empujan la misma pelea, pero con filosofias distintas: el siguiente cuello de botella no es construir el agente, sino distribuirlo, conectarlo con otros agentes y gobernarlo en canales reales.
La conclusión corta es esta: Microsoft Foundry no esta anadiendo un bot a Teams; esta convirtiendo identidad, publicación y handoff A2A en piezas nativas del runtime de agentes.