For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/es/articles/gemini-managed-agents-remote-mcp-production-guide.md.
Este artículo explica por qué la actualización de Gemini Managed Agents es importante para los equipos que crean productos reales de agentes...

La actualización de julio de 2026 de Gemini Managed Agents de Google es más que una pequeña mejora de la API. Acerca a Managed Agents a un verdadero entorno de ejecución de agentes de nivel de producción.
Las incorporaciones importantes son la ejecución en segundo plano, la integración con servidores MCP remotos, las llamadas a funciones personalizadas y la actualización de credenciales. No se trata de hacer que el modelo responda con más fluidez. Se trata de si un agente puede seguir trabajando de forma segura, recuperarse de tareas de larga duración, llamar herramientas con los permisos correctos y dejar suficiente evidencia para que los desarrolladores revisen lo ocurrido.
La actualización de julio de 2026 de Google no debe leerse como un parche rutinario de API. Es una señal de que Gemini Managed Agents está siendo llevado hacia una capa de ejecución más completa para agentes de IA en producción.
Las capacidades clave son la ejecución en segundo plano, la integración con servidores MCP remotos, las llamadas a funciones personalizadas y la actualización de credenciales. Las cuatro operan en el nivel de ejecución. Resuelven problemas prácticos relacionados con la duración de las tareas, el acceso a herramientas, la autenticación, la recuperación y la auditabilidad.
Antes de esto, muchos productos de agentes de IA se construían en torno a un simple bucle de prompts. La aplicación ensamblaba el contexto, el modelo decidía el siguiente paso, el programa llamaba una herramienta y el resultado se volvía a colocar en la ventana de contexto. Ese patrón funciona bien para demostraciones. Pero una vez que el agente entra en un flujo de trabajo empresarial real, rápidamente se encuentra con problemas más difíciles: gestión de estado, credenciales, permisos de herramientas, ejecución de tareas largas, recuperación ante fallos y registros fiables.
Esta actualización de Gemini apunta directamente a esos problemas de producción.
Los agentes útiles a menudo necesitan más que unos pocos segundos. Pueden leer documentos, navegar por la web, ejecutar pruebas, generar código, esperar a CI, preparar un informe o comparar datos entre varios sistemas.
Poner todo eso en una sola solicitud HTTP síncrona es frágil. Tampoco ofrece una buena experiencia de usuario. Un agente de producción no debería sentirse como una solicitud de chat que podría agotar el tiempo de espera. Debería sentirse más como un trabajo que puede iniciarse, supervisarse, pausarse, cancelarse, reintentarse o reanudarse.
La ejecución en segundo plano cambia el modelo del producto. Una tarea de agente ahora puede tener un ID de tarea, un estado, actualizaciones de progreso, soporte para cancelación, razones de fallo y una salida final. Esto hace que el agente sea más fácil de integrar en aplicaciones reales, especialmente cuando los usuarios necesitan volver más tarde y ver qué ocurrió.
También cambia el diseño de la interfaz. Una interfaz de chat se centra en una ronda de conversación. Una interfaz de agente se centra en el estado del trabajo. Los usuarios necesitan ver qué está leyendo el agente, qué herramientas ha llamado, si está bloqueado y si la siguiente acción requiere aprobación.
Para los equipos que construyen con NxCode o productos similares de flujos de trabajo de IA, la respuesta final no es suficiente. El flujo de trabajo también debe conservar evidencia de ejecución auditable: prompts, llamadas a herramientas, salidas de herramientas, errores, cambios en archivos y artefactos finales.
MCP importa porque reduce el caos de integración de herramientas. En el pasado, cada modelo, IDE y sistema interno podía requerir su propio conector. Eso creaba
trabajo de integración repetido y dificultó la gestión de los permisos.
El Protocolo de Contexto del Modelo ofrece una forma más estandarizada para que los agentes accedan a recursos y herramientas externas. Remote MCP lleva esa idea a los escenarios de agentes alojados en la nube. Un agente gestionado puede conectarse a documentos remotos, sistemas de seguimiento de incidencias, plataformas de observabilidad, servicios de datos o herramientas internas sin depender de un servidor de herramientas local.
Esa es la oportunidad. El límite es la seguridad.
Cada servidor MCP también es un límite de permisos. Las herramientas que expone influyen en el comportamiento del modelo. El contenido que devuelve puede contener inyección de prompts. Sus permisos pueden ser más amplios de lo que el usuario pretendía autorizar.
Por eso, en un entorno de producción no se debe tratar Remote MCP como un atajo de conectar y usar. Las herramientas de solo lectura y las herramientas con capacidad de escritura deben separarse. Las acciones destructivas deben restringirse. Cada llamada a una herramienta debe registrarse. Las acciones de alto riesgo deben requerir aprobación humana antes de que el agente pueda continuar.
MCP es muy adecuado para un ecosistema de herramientas más amplio, pero las llamadas a funciones personalizadas siguen siendo la opción correcta para las acciones internas del producto.
Algunos ejemplos son el cálculo de precios, las comprobaciones de derechos del plan, la creación de borradores, la creación de pull requests, la consulta de registros internos o la validación específica del negocio. Estas funciones deben tener tipos claros, permisos limitados y un comportamiento predecible. La autorización final debe seguir ocurriendo en el código de la aplicación en lugar de dejarse en manos del modelo.
La actualización de credenciales parece una pequeña función de infraestructura, pero en realidad forma parte del límite de confianza para los agentes de larga duración.
Los tokens de corta duración son más seguros, pero las tareas en segundo plano necesitan continuidad. El patrón más seguro es conceder solo el alcance mínimo necesario para la tarea actual, evitar ampliar el alcance durante la actualización y mantener las acciones sensibles detrás de una aprobación reforzada. El modelo no debe ver secretos sin procesar, y los registros nunca deben filtrar tokens.
No trasladen de una vez todas las funciones de IA a Managed Agents. Empiecen por clasificar los flujos de trabajo según su riesgo y reversibilidad.
Una primera división útil es:
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
El trabajo de solo lectura puede automatizarse más. Las acciones de escritura requieren controles más estrictos. Para cada herramienta, definan su alcance de permisos, responsable, nivel de sensibilidad de los datos, regla de aprobación y requisito de registro.
Los flujos de trabajo piloto más adecuados son las tareas que actualmente requieren varios pasos manuales, pero que aún pueden validarse en entornos de staging o sandbox. Buenos ejemplos son la recopilación de investigación, los borradores de corrección de código, la investigación de tickets de soporte, la generación de documentación y la conciliación interna de datos.
Un flujo de trabajo más seguro consiste en dejar que el agente produzca primero evidencia y un plan. Solo después de una revisión humana debería realizar acciones irreversibles.
2026-07-08
Los Gemini Managed Agents son entornos de ejecución de agentes configurables en la API de Gemini. Pueden razonar, ejecutar código, gestionar archivos y usar herramientas dentro de un entorno aislado alojado en la nube.
La ejecución en segundo plano permite que las tareas de larga duración continúen sin mantener abierta una conexión HTTP. Esto resulta útil para flujos de trabajo como investigación, generación de código, pruebas, creación de informes y verificaciones de datos entre varios sistemas.
Remote MCP significa que un agente gestionado puede conectarse a servidores remotos del Model Context Protocol en lugar de depender únicamente de servidores de herramientas locales. Esto facilita la conexión de los agentes con sistemas externos, API privadas, documentación, gestores de incidencias o servicios internos de datos.
Remote MCP puede utilizarse en producción solo con un diseño cuidadoso de permisos. Los equipos deben separar las herramientas de solo lectura de las que permiten escritura, registrar cada llamada a herramientas, limitar las acciones destructivas y añadir aprobación humana para operaciones de alto riesgo.
Las llamadas a funciones personalizadas son mejores para acciones empresariales específicas del producto, como validar permisos, calcular precios, crear borradores o abrir pull requests. MCP es mejor para patrones más amplios de integración de herramientas y fuentes de datos.
Los agentes de larga duración pueden necesitar tokens de acceso que expiren antes de que la tarea termine. La renovación de credenciales permite la continuidad, pero debe preservar el principio de privilegio mínimo y evitar exponer secretos al modelo o a los registros.
Como mínimo, los equipos deberían registrar los prompts, las llamadas a herramientas, las salidas de las herramientas, los errores, los cambios en archivos, las decisiones de aprobación y los artefactos finales. Estos registros facilitan la auditoría, la depuración y la mejora del comportamiento de los agentes.
Protocol](https://modelcontextprotocol.io/docs/getting-started/intro): La documentación oficial de MCP para conectar aplicaciones de IA con herramientas externas y fuentes de datos.
Este artículo explica por qué la actualización de Gemini Managed Agents es importante para los equipos que están creando productos reales de agentes de IA. El cambio clave es pasar de ciclos breves de prompts a un modelo de ejecución que admite trabajo de larga duración, herramientas remotas, funciones empresariales personalizadas y continuidad de credenciales.
La lección de diseño más importante es que los agentes de producción necesitan más que la capacidad del modelo. Necesitan estado, permisos, reglas de aprobación, registros de auditoría y límites claros entre el trabajo de solo lectura y las acciones irreversibles.
Para los agentes de IA en producción, la verdadera pregunta no es solo qué puede hacer el modelo, sino si el sistema puede controlar, observar y recuperar lo que hace el agente.
Empieza con una sola frase y obtén un sitio completo en minutos.