Cómo crear agentes profesionales en un entorno privado con Gemini Enterprise, ADK y MCP

La creación de agentes de inteligencia artificial ya no se trata únicamente de escribir un buen prompt. En entornos profesionales, un agente debe ser capaz de razonar, delegar tareas, consultar herramientas externas, mantener flujos de conversación claros y operar dentro de un contexto privado y controlado.

En este artículo comparto una demostración práctica de cómo construimos un agente profesional en Gemini Enterprise usando Google ADK, subagentes especializados y herramientas MCP. El objetivo del demo fue simular un agente de reventa de tickets para la Copa Mundial 2026, capaz de informar al usuario, buscar disponibilidad, comparar precios, generar enlaces de pago y atender solicitudes de soporte.

Este proyecto fue creado con fines educativos. El endpoint MCP utilizado es de pruebas y depende de servicios auxiliares, como un crawler y herramientas simuladas, para demostrar cómo se conectan datos externos a un agente conversacional.

La idea del demo

El caso de uso fue construir un agente llamado WC26 Tickets, especializado en asistir a usuarios interesados en partidos del Mundial 2026.

El agente principal no intenta resolver todo por sí mismo. Su función es recibir al usuario, entender su intención y derivarlo al subagente correcto.

La arquitectura se dividió en cuatro perfiles:

1. Agente de información: responde preguntas sobre partidos, estadios, ciudades, clima, fan zones, logística y datos generales del Mundial.
2. Agente de reservas o ventas: busca boletos disponibles, compara precios entre plataformas y prepara una reserva.
3. Agente de pagos: genera links de pago, consulta tickets comprados, emite boletos digitales y envía comprobantes por correo.
4. Agente de soporte: atiende problemas, solicitudes de reembolso y casos donde el usuario necesita ayuda adicional.

Esta separación permite que cada agente tenga una responsabilidad clara. En vez de crear un único prompt gigante, diseñamos un sistema modular donde cada subagente tiene instrucciones, herramientas y reglas específicas.

Paso 1: Crear el agente en Gemini Enterprise

El primer paso fue usar Gemini Enterprise como entorno privado para diseñar y probar el agente.

Desde la interfaz se creó un nuevo agente llamado WC26 Tickets. En la vista de diseño se puede observar un flujo donde el agente raíz está conectado con varios subagentes. Esta representación visual es importante porque permite entender cómo se distribuyen las responsabilidades dentro del sistema.

El agente raíz actúa como orquestador. No busca boletos, no procesa pagos y no resuelve reembolsos directamente. Su trabajo es clasificar la intención del usuario y enviar la conversación al agente adecuado.

Por ejemplo:

• Si el usuario pregunta “¿cuándo juega México?”, el flujo va al agente de información.
• Si pregunta “¿cuánto cuestan los boletos para México vs Brasil?”, el flujo va al agente de reservas.
• Si dice “quiero pagar”, el flujo pasa al agente de pagos.
• Si dice “quiero un reembolso”, se deriva al agente de soporte.

Este patrón es clave en agentes profesionales: la orquestación debe estar separada de la ejecución especializada.

Paso 2: Usar Google ADK para definir la arquitectura

Después de diseñar el flujo visual, usamos código con Google ADK para representar la arquitectura del agente.

El proyecto parte de una estructura como esta:

from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams
from google.adk.tools.mcp_tool.mcp_toolset import McpToolset
from google.adk.tools.google_search_tool import GoogleSearchTool
from google.adk.tools import url_context

Estas importaciones permiten crear agentes basados en modelos Gemini, conectar herramientas de búsqueda, usar contexto desde URLs y consumir herramientas externas mediante MCP.

También se define un endpoint MCP:

MCP_URL = 'https://wc26-tickets-1057553597074.us-central1.run.app/mcp'

En este demo, ese endpoint representa un servidor de herramientas para consultar partidos, estadios, disponibilidad de tickets, pagos y soporte. Es importante aclarar que se trata de un MCP de pruebas, diseñado para explicar el patrón de integración.

En un sistema real, este endpoint se conectaría a APIs internas, bases de datos, CRMs, sistemas de pagos, inventarios o plataformas autorizadas.

Paso 3: Crear subagentes especializados

El siguiente paso fue definir subagentes con roles específicos.

Cada subagente se crea como un LlmAgent, indicando:

• Nombre interno.
• Modelo.
• Descripción.
• Instrucciones.
• Herramientas disponibles.
• Subagentes, si aplica.

Por ejemplo, el agente de información se define con un rol muy concreto: responder preguntas sobre el Mundial 2026 y usar herramientas MCP para consultar partidos o estadios.

agent_information_2 = LlmAgent(
  name='agent_information_2',
  model='gemini-2.5-flash',
  description='Eres el Experto en Informacion de la Copa del Mundo 2026.',
  instruction="""Eres el Experto en Informacion de la Copa del Mundo 2026...""",
  tools=[
    GoogleSearchTool(),
    McpToolset(
      connection_params=StreamableHTTPConnectionParams(url=MCP_URL),
    )
  ],
)

La ventaja de este diseño es que el agente no depende únicamente de su conocimiento general. Puede usar herramientas externas para responder con información más estructurada.

En este caso, el agente de información tiene acceso a herramientas como:

• get-matches: consultar partidos.
• get-venues: consultar estadios y sedes.
• GoogleSearchTool: buscar información no disponible en el MCP.

Esto crea una combinación útil: el agente puede consultar datos privados o estructurados mediante MCP, y complementar con búsqueda web cuando la información no está en las herramientas internas.

Paso 4: Diseñar las transiciones entre agentes

Una parte central del demo fue explicar cómo ocurren las transiciones.

El agente raíz incluye reglas de enrutamiento. Estas reglas no son simplemente decorativas; son instrucciones operativas para que el sistema sepa cuándo delegar.

El agente principal fue definido así:

root_agent = LlmAgent(
  name='WC26_tickets',
  model='gemini-2.5-flash',
  description='Eres el Agente re-Ventas para copa mundial de futbol 2026 de FIFA.',
  sub_agents=[agent_information_2, booking_agent, payment_agent, support_agent],
  instruction="""Eres el Agente REVENTA de boletos...

Reglas de Enrutamiento:
Si el usuario pregunta datos generales: Llama a agent_information_2.
Si el usuario quiere comprar, ver precios o disponibilidad: Llama a booking_agent.
Si el usuario tiene un problema, quiere un reembolso o queja: Llama a support_agent.
""",
  tools=[
    GoogleSearchTool()
  ],
)

Este patrón es muy útil para construir agentes profesionales porque permite separar flujos de negocio.

El usuario no ve necesariamente toda la complejidad interna. Para él, la experiencia es una conversación natural. Pero detrás hay un sistema que decide qué agente debe intervenir en cada momento.

En la vista de telemetría del demo se puede observar cómo el agente raíz está conectado con los subagentes y cómo se activa uno de ellos según la intención del usuario. Por ejemplo, cuando el usuario busca boletos, el flujo activa el booking_agent.

Paso 5: Conectar herramientas con MCP

MCP, o Model Context Protocol, permite que un agente use herramientas externas de forma estructurada.

En este demo, todos los subagentes principales se conectan al mismo endpoint MCP:

McpToolset(
  connection_params=StreamableHTTPConnectionParams(url=MCP_URL),
)

Esto permite que cada agente tenga acceso a herramientas según su función.

El agente de reservas usa herramientas como:

• get-matches
• get-venues
• search-tickets
• compare-prices
• buy-ticket

El agente de pagos usa:

• generate-payment-link
• get-my-tickets
• issue-digital-ticket
• send-ticket-email
• send-payment-link

El agente de soporte usa:

• check-refund-policy
• refund-ticket

La idea educativa aquí es mostrar que un agente profesional no debería inventar operaciones críticas. Si necesita consultar disponibilidad, debe usar una herramienta. Si necesita generar un pago, debe llamar una herramienta. Si necesita verificar una política de reembolso, debe consultar el sistema correspondiente.

Esto reduce errores, mejora la trazabilidad y permite integrar el agente con servicios reales.

Paso 6: Definir reglas críticas para evitar conversaciones débiles

Un punto importante del proyecto fue escribir instrucciones precisas.

Por ejemplo, en el agente de reservas se incluyó una regla crítica:

Cuando el usuario mencione un partido, equipo o país, inmediatamente usa la herramienta search-tickets para buscar boletos disponibles. No preguntes datos adicionales antes de buscar.

Esta regla mejora mucho la experiencia del usuario. En muchos agentes mal diseñados, el sistema responde con demasiadas preguntas antes de actuar.

En este demo, si el usuario dice “quiero boletos para México vs Brasil”, el agente no debe preguntar primero cuántos boletos quiere. Debe buscar disponibilidad, mostrar opciones reales y luego pedir cantidad o categoría si hace falta.

También se incluyó una regla para no alterar precios:

Mira los precios reales y no cambies los precios.

Este tipo de instrucción es fundamental cuando un agente trabaja con inventario, pagos o precios. El modelo no debe improvisar importes. Debe respetar los datos devueltos por las herramientas.

Paso 7: Simular un flujo completo de compra

El flujo de compra diseñado en el demo funciona así:

1. El usuario pregunta por un partido o equipo.
2. El agente raíz detecta intención comercial.
3. La conversación pasa al booking_agent.
4. El agente usa search-tickets.
5. Presenta opciones con precios y categorías.
6. Si el usuario confirma cantidad y categoría, calcula el total.
7. Presenta un resumen de reserva.
8. Si el usuario confirma, transfiere el resumen al payment_agent.
9. El agente de pagos genera un link de checkout.
10. El usuario recibe el enlace para completar el pago.

El resumen antes de pagar debe incluir una frase como:

Tengo disponibilidad para [Partido]. El total por [Cantidad] boletos es [Precio] y categoría seleccionada. ¿Confirmas la reserva?

También se agrega un aviso importante:

El precio puede cambiar. Solo puedo mantenerlo por 20 minutos.

Este detalle es importante para simular un comportamiento realista en mercados donde los precios pueden cambiar constantemente.

Paso 8: Agregar soporte y reembolsos

Un agente profesional no termina en la venta. También debe considerar soporte.

Por eso se creó un support_agent especializado en problemas, quejas y reembolsos.

Este agente tiene reglas como:

• Solicitar siempre el Order ID.
• Verificar la fecha del partido.
• Consultar la política de reembolso.
• No ofrecer reembolso si faltan menos de 48 horas para el evento.
• Escalar a un humano si el usuario está frustrado o el caso es complejo.

Esto permite modelar un flujo de atención posterior a la compra, que en escenarios reales es tan importante como la conversión.

Paso 9: Probar el agente en Gemini Enterprise

Después de definir el agente, se probó dentro de Gemini Enterprise.

En la interfaz se ve el agente WC26 Ticket disponible como experiencia conversacional privada. Desde ahí se puede conversar con el agente, validar respuestas, probar transiciones y revisar si el enrutamiento funciona correctamente.

También se usó una vista de telemetría local para observar el comportamiento del sistema. En esa vista se puede ver:

• El agente raíz.
• Los subagentes conectados.
• Qué agente se activa en una interacción.
• La línea temporal de eventos.
• Las llamadas o acciones realizadas durante la conversación.

Esta telemetría es clave para depurar agentes. No basta con ver la respuesta final. En entornos profesionales necesitamos entender qué pasó detrás: qué agente respondió, qué herramienta se usó, qué datos llegaron y por qué se tomó cierta decisión.

Qué aprendimos del demo

1. Un buen agente necesita arquitectura, no solo prompts

El prompt sigue siendo importante, pero no es suficiente. Un agente empresarial debe tener roles, herramientas, reglas, transiciones y límites claros.

2. Los subagentes ayudan a reducir complejidad

Separar información, ventas, pagos y soporte permite mantener instrucciones más limpias y fáciles de depurar.

3. MCP permite conectar el agente con sistemas externos

El agente puede consultar datos, ejecutar operaciones y trabajar con servicios fuera del modelo. Esto es esencial para casos de negocio reales.

4. La telemetría es parte del desarrollo

Ver qué agente se activa y qué herramienta se llama permite mejorar el sistema de forma mucho más rápida.

5. La privacidad del entorno importa

Gemini Enterprise permite trabajar en un entorno controlado para diseñar agentes que pueden conectarse a sistemas privados, herramientas internas o servicios empresariales.

Consideraciones importantes

Este demo no representa un sistema comercial final de venta de tickets. Es una prueba educativa para explicar cómo funcionan los patrones de agentes, transiciones, herramientas MCP y orquestación.

El endpoint MCP usado es experimental y depende de datos de prueba, herramientas simuladas y procesos como crawlers. En producción sería necesario agregar validaciones adicionales, seguridad, autenticación, control de permisos, monitoreo, manejo de errores, auditoría y cumplimiento legal.

También sería importante conectar fuentes oficiales y proveedores autorizados, especialmente en un caso sensible como venta o reventa de boletos.

Conclusión

Crear agentes profesionales con Gemini Enterprise implica pensar más allá de una conversación. Implica diseñar una arquitectura.

En este demo construimos un agente raíz capaz de enrutar al usuario hacia subagentes especializados: información, reservas, pagos y soporte. Cada subagente tiene instrucciones claras y herramientas específicas conectadas mediante MCP.

El resultado es una experiencia conversacional más ordenada, trazable y cercana a un flujo empresarial real.

La gran lección es que los agentes profesionales no se construyen solo con inteligencia del modelo. Se construyen combinando modelos, herramientas, datos, reglas de negocio, telemetría y una arquitectura bien definida.

Repositorio del proyecto Demo Agents