Logo GCP con Eduardo

GCP con Eduardo

Descarga el código de la lección

Cómo Crear tu PRIMER Agente de IA con Google ADK (Setup, Tool Calling y Multi-Modelo)
✦ Guía Técnica & Arquitectura

Cómo Crear tu PRIMER Agente de IA con Google ADK

Aprende a construir un agente de IA desde cero con Gemini, Python y Google ADK, entendiendo lo que realmente ocurre detrás del tool calling, cómo diseñar funciones que el modelo pueda utilizar de forma fiable y cómo evolucionar después hacia una arquitectura multi-modelo sin introducir LangChain como capa adicional de abstracción.

Lo que Aprenderás

Crear la estructura mínima de un agente con Google ADK y Python.
Implementar tool calling mediante funciones Python tipadas y documentadas.
Separar modelo, herramientas, instrucciones y runtime para evitar acoplamiento arquitectónico.
Preparar una estrategia multi-modelo basada en calidad, coste, latencia y resiliencia.
Python 3.11+ Google ADK Gemini Function Calling Tool Calling LiteLLM Google Cloud

Un agente no es simplemente un chatbot con un prompt

Un chatbot tradicional suele seguir un flujo relativamente lineal: entrada → modelo → respuesta. Un agente añade una capacidad fundamental: puede decidir que necesita ejecutar una acción externa antes de completar la respuesta.

Esa acción puede ser consultar una base de datos, invocar una API, calcular un dato, recuperar información empresarial o ejecutar una operación de negocio controlada. El modelo deja de ser el sistema completo y pasa a ser el componente de razonamiento dentro de un runtime que coordina herramientas y estado.

01 Usuario Solicitud natural
02 Agente Interpreta intención
03 Modelo Decide acción
04 Tool Ejecuta operación
05 Respuesta Entrega resultado

¿Por qué Google ADK en lugar de añadir otra abstracción?

Code-first

La definición del agente vive en Python. Puedes versionar instrucciones, herramientas, configuración y composición con las mismas prácticas que cualquier otro sistema de software.

Tool-native

Una herramienta puede ser una función Python normal. La firma, los tipos, la documentación y el resultado forman parte del contrato que el agente utiliza para decidir cuándo invocarla.

Model abstraction

El agente no debería contener lógica de negocio específica del proveedor. Esto permite cambiar el modelo o introducir una capa multi-modelo sin reescribir las herramientas.

El setup mínimo para tu primer agente

Para un proyecto profesional conviene empezar con un entorno Python aislado, dependencias reproducibles y credenciales fuera del código fuente. Python 3.11 o superior es una base razonable para el stack actual.

Terminal setup
# Crear entorno virtual
python -m venv .venv

# Activarlo en macOS / Linux
source .venv/bin/activate

# Windows PowerShell
# .venv\Scripts\Activate.ps1

# Instalar Google ADK
pip install -U google-adk

# Crear estructura inicial
mkdir mi-primer-agente
cd mi-primer-agente

Autenticación: separa desarrollo y producción

Para experimentar puedes trabajar con una API key de Gemini. En un entorno empresarial es preferible diseñar desde el principio la configuración de credenciales pensando en el runtime donde se desplegará el agente.

La regla importante es sencilla: ninguna API key debe terminar hardcodeada en agent.py, Git o una imagen de contenedor.

Tu primer agente Gemini con Google ADK

El núcleo conceptual es pequeño: un nombre, un modelo, unas instrucciones y, opcionalmente, una colección de herramientas. Esta separación es importante porque evita mezclar prompt engineering, integración de APIs y lógica de negocio en una única función monolítica.

app/agent.py Python
from google.adk.agents import Agent


MODEL = "gemini-3.7-flash"


def get_customer_status(customer_id: str) -> str:
    """Return the current status of a customer.

    Args:
        customer_id: Unique identifier of the customer.

    Returns:
        A human-readable customer status.
    """
    # Sustituir por una llamada real a tu backend.
    fake_database = {
        "C001": "ACTIVE",
        "C002": "SUSPENDED",
    }

    return fake_database.get(customer_id, "NOT_FOUND")


root_agent = Agent(
    name="customer_support_agent",
    model=MODEL,
    instruction="""
    You are a customer support agent.

    Rules:
    - Be concise and factual.
    - Never invent customer information.
    - Use get_customer_status when the user asks about
      the status of a specific customer.
    - If the customer ID is missing, ask for it.
    """,
    tools=[get_customer_status],
)

El detalle aparentemente pequeño que tiene enorme impacto en producción es la documentación de la herramienta. El docstring no es decoración: ayuda a describir al modelo qué hace la función, qué parámetros necesita y qué devuelve.

Cómo funciona realmente el Function Calling

1. El modelo decide

El usuario formula una petición. El modelo evalúa las herramientas disponibles y determina si alguna puede resolver una parte de la tarea.

2. Genera argumentos

Si necesita una herramienta, genera una llamada estructurada con los argumentos necesarios, respetando el esquema derivado de la función.

3. ADK ejecuta

El runtime ejecuta la función Python. El resultado de esa ejecución vuelve al contexto del agente.

4. El modelo finaliza

El modelo recibe el resultado de la herramienta y lo utiliza para construir una respuesta final orientada al usuario.

⚠ Antipatrón: convertir las tools en funciones gigantes

Una función como execute_everything() que consulta cinco APIs, transforma datos, modifica registros y decide reglas de negocio es una mala frontera para un agente.

Una herramienta debe representar una acción clara y verificable. Cuanto más determinista sea su contrato, menor será la superficie de error del modelo.

Mejor patrón: dividir acciones por responsabilidad: get_customer(), get_order(), calculate_refund() y create_refund_request().

¿Qué patrón arquitectónico deberías utilizar?

No todos los problemas necesitan un agente. Una de las decisiones más importantes a nivel Staff/Architect es determinar si el comportamiento debe ser determinista, probabilístico o híbrido.

Patrón Latencia Consistencia Coste Cuándo utilizarlo
Función Python directa Muy baja Determinista Muy bajo Reglas conocidas y workflows fijos.
LLM + Tool Calling Media Probabilística Medio El usuario expresa la intención en lenguaje natural.
Agent + múltiples tools Media/Alta Probabilística Medio/Alto Tareas con selección dinámica de herramientas.
Workflow determinista + LLM Media Alta en los pasos críticos Medio Producción donde las decisiones críticas necesitan control.
Multi-agent Alta Más compleja Alto Problemas realmente divisibles en especialistas independientes.

Regla de arquitectura: no conviertas un workflow determinista en un agente simplemente porque puedes hacerlo. El LLM debe introducir valor proporcional a la incertidumbre o flexibilidad que necesitas resolver.

El error que dispara el coste de un agente

⚠ Error crítico: usar el modelo más potente para todo

Un agente empresarial puede ejecutar varias inferencias durante una única interacción. Si cada paso utiliza un modelo grande y además envías todo el historial y resultados de herramientas en cada llamada, el coste puede crecer mucho más rápido que el número de usuarios.

El problema no se resuelve únicamente escogiendo un modelo barato. Hay que optimizar el número de llamadas, el tamaño del contexto, el diseño de las tools, la frecuencia de reintentos y el modelo asignado a cada tipo de tarea.

Un patrón práctico es utilizar un modelo rápido para clasificación, extracción o routing y reservar un modelo de mayor capacidad para las decisiones que realmente requieren razonamiento complejo.

Context Budget

No envíes automáticamente documentos, logs o resultados completos de herramientas si el agente sólo necesita una pequeña parte.

Tool Budget

Limita llamadas redundantes. Una tool debe devolver la mínima información necesaria para la siguiente decisión.

Model Budget

Asigna modelos según criticidad, latencia y coste. No todas las tareas necesitan el mismo nivel de razonamiento.

Tool Calling con validación y límites

En producción, una tool que modifica estado debe considerarse una frontera de seguridad. No basta con confiar en que el modelo genere argumentos correctos. La función debe validar entradas, controlar permisos, aplicar límites y devolver resultados explícitos.

app/tools/customer.py Production pattern
from dataclasses import dataclass


@dataclass(frozen=True)
class RefundResult:
    success: bool
    message: str
    refund_id: str | None = None


def create_refund_request(
    order_id: str,
    amount_eur: float,
    reason: str,
) -> dict:
    """Create a refund request for an order.

    Args:
        order_id: Existing order identifier.
        amount_eur: Refund amount in EUR.
        reason: Business reason for the refund.

    Returns:
        Structured result describing the operation.
    """

    # 1. Validate input at the tool boundary.
    if not order_id.strip():
        return {
            "success": False,
            "message": "order_id is required",
        }

    if amount_eur <= 0:
        return {
            "success": False,
            "message": "amount_eur must be greater than zero",
        }

    if amount_eur > 500:
        return {
            "success": False,
            "message": "Refund exceeds automatic approval limit",
        }

    # 2. Here you would call your transactional backend.
    # Never let the LLM directly manipulate the database.

    refund_id = "RF-2026-000123"

    # 3. Return a small, explicit result to the model.
    return {
        "success": True,
        "refund_id": refund_id,
        "message": "Refund request created successfully",
    }

El LLM no debe ser tu capa de autorización

El agente puede proponer una operación, pero la autoridad para ejecutarla debe permanecer en el sistema de negocio.

Autorización, límites monetarios, ownership, idempotencia, validación de parámetros y auditoría deben existir independientemente de que la petición llegue desde un usuario humano, un agente o una API.

Cómo preparar el agente para varios modelos

Una arquitectura multi-modelo no significa ejecutar tres LLM simultáneamente porque sí. Significa que la aplicación tiene una frontera clara entre el agente y el proveedor de inferencia, permitiendo seleccionar un backend en función de requisitos técnicos.

Estrategia Modelo Ventaja Trade-off
Native Gemini Gemini Integración directa con el ecosistema Google. Mayor dependencia del proveedor.
LiteLLM Varios proveedores Abstracción común y facilidad para cambiar de backend. Añade otra dependencia operacional.
Self-hosted Modelos open-weight Control de infraestructura, datos y runtime. Mayor complejidad de operación y capacidad.
Hybrid Gemini + otros Permite optimizar coste, resiliencia y calidad. Mayor complejidad de evaluación y observabilidad.
models.py Multi-model
import os

from google.adk.agents import Agent
from google.adk.models.lite_llm import LiteLlm


def build_model():
    """Select the model through configuration, not business logic."""

    provider = os.getenv("MODEL_PROVIDER", "gemini")

    if provider == "gemini":
        return os.getenv("GEMINI_MODEL", "gemini-3.7-flash")

    if provider == "openai":
        return LiteLlm(
            model=os.getenv("OPENAI_MODEL", "openai/gpt-4o")
        )

    if provider == "anthropic":
        return LiteLlm(
            model=os.getenv(
                "ANTHROPIC_MODEL",
                "anthropic/claude-sonnet-4-20250514"
            )
        )

    raise ValueError(
        f"Unsupported MODEL_PROVIDER: {provider}"
    )


root_agent = Agent(
    name="multi_model_agent",
    model=build_model(),
    instruction="""
    You are a production AI assistant.

    Use available tools when external data is required.
    Never fabricate tool results.
    Keep responses concise and factual.
    """,
    tools=[],
)
⚠ Antipatrón: cambiar de modelo sin evaluación

Que dos modelos acepten la misma llamada no significa que produzcan el mismo comportamiento. Antes de cambiar de backend debes medir calidad de respuesta, uso de herramientas, errores, latencia, coste y regresiones sobre un conjunto de casos representativos.

La arquitectura que recomiendo para producción

Separación de responsabilidades

Mantén el agente centrado en instrucciones y coordinación. Las integraciones externas deben vivir en módulos de herramientas y servicios independientes.

Contratos explícitos

Define tipos, parámetros, resultados y errores de las tools. Una tool ambigua aumenta la probabilidad de llamadas incorrectas.

Idempotencia

Las operaciones con efectos secundarios deben tolerar reintentos. Un agente puede volver a intentar una acción después de un timeout.

Observabilidad

Registra latencia, errores, llamadas a herramientas, modelo utilizado y costes. Sin trazabilidad no puedes optimizar un agente de producción.

Human-in-the-loop

Para acciones de alto impacto, introduce aprobación humana antes de ejecutar operaciones irreversibles o económicamente sensibles.

Evaluation-first

Construye datasets de casos reales y de fallo. Evalúa el agente antes de cambiar prompts, modelos, tools o estrategias de routing.

Checklist paso a paso

  1. Define el caso de uso: especifica qué decisiones puede tomar el agente y cuáles quedan fuera de su alcance.
  2. Selecciona el modelo: establece requisitos de calidad, latencia, coste, contexto y disponibilidad.
  3. Diseña las tools: una función debe representar una acción concreta con parámetros y resultados claros.
  4. Valida en la frontera: nunca confíes en que el modelo haya generado argumentos seguros.
  5. Implementa idempotencia: protege operaciones con efectos secundarios frente a reintentos y duplicados.
  6. Controla el contexto: limita historial, documentos y resultados de herramientas a la información realmente necesaria.
  7. Instrumenta observabilidad: registra traces, latencias, errores, tool calls y consumo.
  8. Crea un dataset de evaluación: incluye casos normales, edge cases, ataques de prompt injection y errores de herramientas.
  9. Prueba regresiones: ejecuta la misma batería después de modificar prompts, modelos o tools.
  10. Despliega progresivamente: empieza con tráfico controlado y monitoriza antes de ampliar el rollout.

Los 7 antipatrones más comunes

01 · Prompt gigante

Meter reglas de negocio, documentación, contratos y datos dinámicos en un único prompt dificulta mantenimiento y evaluación.

02 · Tool sin contrato

Funciones con parámetros ambiguos o resultados inconsistentes hacen que el modelo tenga más posibilidades de equivocarse.

03 · Sin límites

No establecer límites de llamadas, tamaño de contexto o tiempo de ejecución puede convertir una interacción en una cascada de inferencias costosas.

04 · LLM como autorización

Un modelo nunca debe ser la última barrera para permitir una transferencia, reembolso, eliminación o modificación crítica.

05 · Sin evaluación

Una demo que funciona con cinco prompts no demuestra que el agente sea fiable bajo carga y casos reales.

06 · Multi-agent demasiado pronto

Introducir varios agentes antes de dominar uno aumenta latencia, coste, observabilidad y superficie de fallo.

07 · Acoplamiento al proveedor

Evita que la lógica de negocio dependa directamente de APIs específicas del modelo. Mantén la inferencia detrás de una frontera de configuración.

08 · Confundir autonomía con calidad

Un agente que puede ejecutar veinte pasos no es necesariamente mejor que un workflow controlado de tres pasos.

Preguntas frecuentes sobre Google ADK

¿Qué es Google ADK y para qué sirve?

Google ADK, o Agent Development Kit, es un framework orientado a código para construir agentes de IA. Permite combinar un modelo, instrucciones, herramientas y patrones de orquestación dentro de una aplicación de agente.

¿Cómo funciona el tool calling en Google ADK?

Una aplicación registra funciones Python como herramientas. El modelo puede decidir cuándo necesita una de ellas, generar sus argumentos y solicitar su ejecución. ADK coordina la llamada y devuelve el resultado al contexto del modelo para completar la respuesta.

¿Puedo usar modelos distintos de Gemini con Google ADK?

Sí. Además del uso directo de modelos Gemini, ADK dispone de integraciones para otros proveedores y de un conector basado en LiteLLM. Esto permite construir estrategias multi-modelo y seleccionar diferentes backends según calidad, coste, latencia y requisitos operativos.

Tu primer agente debe ser pequeño, observable y reemplazable

El objetivo de tu primer proyecto con Google ADK no debería ser construir un sistema autónomo gigantesco. Debería ser comprender perfectamente el ciclo: usuario → modelo → tool → resultado → respuesta.

Una vez controlas ese ciclo, puedes añadir sesiones, memoria, recuperación, múltiples herramientas, workflows, agentes especializados, evaluación, observabilidad y estrategias multi-modelo de forma incremental.

La diferencia entre una demo de IA y una arquitectura de agentes preparada para producción no está en tener más prompts. Está en diseñar correctamente los límites entre modelo, herramientas, datos, permisos, runtime y observabilidad.

La regla Staff/Architect

Usa un agente donde aporte decisión. Usa código determinista donde la decisión ya sea conocida. Y utiliza una frontera explícita entre ambos para que el sistema pueda ser probado, auditado, optimizado y evolucionado sin depender de que el LLM "se comporte bien".

Sobre el Autor: Eduardo Martínez Agrelo

AI & Data Architect

Eduardo Martínez Agrelo es AI & Data Architect, especializado en arquitectura de datos, inteligencia artificial y diseño de plataformas orientadas a producción. Su enfoque combina profundidad técnica, decisiones arquitectónicas y aplicación práctica de tecnologías modernas de datos e IA.

© 2026 Eduardo Martínez Agrelo · AI & Data Architect

Google ADK · Gemini · Python · Tool Calling · Function Calling · Multi-Model AI