DEV Community

Cover image for ¿Qué es OpenAI AgentKit?
Roobia
Roobia

Posted on • Originally published at apidog.com

¿Qué es OpenAI AgentKit?

OpenAI AgentKit es un conjunto de herramientas para construir, desplegar y medir agentes de IA sobre la plataforma de OpenAI. Si estás creando agentes que llaman APIs, ejecutan herramientas y necesitan llegar a producción, lo importante en 2026 es saber qué partes siguen vigentes y dónde conviene invertir. Esta guía resume qué incluye AgentKit, qué está siendo retirado, cómo construir con el SDK de Agentes y cómo usar herramientas de prueba de API como Apidog cuando tu agente depende de servicios externos.

Prueba Apidog hoy

Qué es AgentKit

OpenAI presentó AgentKit en DevDay el 6 de octubre de 2025. No era un único producto, sino un conjunto de piezas construidas alrededor de la API de OpenAI y del SDK de Agentes de OpenAI.

Su objetivo era reducir la distancia entre:

  • “Tengo una idea para un agente”
  • “Tengo un agente funcionando frente a usuarios reales”

AgentKit

Antes de AgentKit, construir un agente solía implicar:

  • Escribir lógica de orquestación manual.
  • Crear conectores personalizados para cada fuente de datos.
  • Montar pipelines de evaluación propios.
  • Ajustar prompts sin trazabilidad clara.
  • Construir una interfaz de chat desde cero.

AgentKit agrupó varias soluciones para ese flujo. Pero hay un punto clave: el 3 de junio de 2026, OpenAI anunció que retirará dos piezas de AgentKit: Agent Builder y Evals. Por eso, si estás construyendo algo mantenible, el camino más sólido es el SDK de Agentes.

Las piezas de AgentKit

AgentKit se lanzó con cuatro componentes principales.

Agent Builder

Agent Builder es un lienzo visual para diseñar flujos de agentes de varios pasos. Permite:

  • Arrastrar y conectar nodos.
  • Previsualizar ejecuciones con entradas reales.
  • Publicar versiones del flujo.
  • Empezar desde plantillas.

Para desarrolladores, el punto más útil es que Agent Builder puede exportar el flujo como código Python o TypeScript usando el SDK de Agentes. Eso permite prototipar visualmente y luego continuar en código.

Estado en 2026: OpenAI está desaprobando Agent Builder. Según la página de desaprobaciones, la plataforma se cerrará el 30 de noviembre de 2026.

Si empiezas hoy, úsalo solo como ayuda de prototipado. El destino final debería ser código con el SDK de Agentes.

ChatKit

ChatKit es una interfaz de chat incrustable para desplegar un agente frente a usuarios. En lugar de crear toda la UI desde cero, puedes integrar un componente de chat, conectarlo a un flujo publicado y personalizar tema y comportamiento.

ChatKit cubre tareas comunes como:

  • Streaming de respuestas.
  • Manejo de hilos.
  • Interacción de chat embebida.
  • Integración con un flujo de agente publicado.

ChatKit sigue disponible y es la pieza de AgentKit menos afectada por los cambios de 2026.

Registro de Conectores

El Registro de Conectores permite administrar cómo se conectan datos y herramientas a través de productos de OpenAI, incluyendo ChatGPT y la API.

Sirve para centralizar conectores como:

  • Dropbox.
  • Google Drive.
  • SharePoint.
  • Microsoft Teams.
  • Servidores MCP de terceros.

Desde una perspectiva de arquitectura, este componente ayuda a controlar qué puede alcanzar un agente y bajo qué permisos.

Si quieres profundizar en MCP, esta guía sobre servidores MCP y el SDK de Agentes de OpenAI explica cómo los agentes llaman herramientas mediante el Protocolo de Contexto del Modelo.

Evaluaciones y optimización

Evals añadía capacidades para medir y mejorar agentes:

  • Conjuntos de datos de evaluación.
  • Calificación de rastros.
  • Puntuación de pasos en ejecuciones multiagente.
  • Optimización automática de prompts.
  • Evaluación contra modelos de terceros.

El objetivo era medir calidad sin crear desde cero una herramienta de evaluación.

Estado en 2026: Evals también está siendo retirado. Se volverá de solo lectura para usuarios existentes el 31 de octubre de 2026 y se cerrará el 30 de noviembre de 2026.

Cómo se relaciona AgentKit con el SDK de Agentes

El SDK de Agentes es la capa de código. Ahí defines:

  • Agentes.
  • Herramientas.
  • Traspasos.
  • Barandillas de seguridad.
  • Lógica de ejecución.

Agent Builder se situaba encima como una capa visual que podía generar código del SDK. ChatKit funciona como una superficie de despliegue para experiencias conversacionales.

Capa Qué es Estado en 2026
Agents SDK Framework de código para definir agentes, herramientas y barandillas Activo, camino recomendado a largo plazo
Agent Builder Lienzo visual que exporta código del SDK de Agentes Obsoleto, cierre el 30 de noviembre de 2026
ChatKit Interfaz de usuario de chat incrustable vinculada a un ID de flujo de trabajo Disponible
Registro de Conectores Panel de administración para conectores y servidores MCP Disponible
Evals Calificación de rastros y optimización de prompts Solo lectura el 31 de octubre de 2026, cierre el 30 de noviembre de 2026

La recomendación práctica es clara:

  • Si necesitas flujos mantenibles como código, usa el SDK de Agentes.
  • Si necesitas casos de lenguaje natural sin código, OpenAI recomienda Agentes de Workspace en ChatGPT.
  • Si eres parte de un equipo de ingeniería, empieza directamente con el SDK.

Para quién es AgentKit

AgentKit fue útil para varios perfiles:

  • Equipos de producto que querían lanzar prototipos rápido.
  • Empresas que necesitaban acceso gobernado a datos internos.
  • Equipos de ingeniería que querían control completo en código.
  • Equipos que necesitaban medir la calidad de agentes con evaluaciones.

En 2026, la decisión es más simple:

  • Para prototipos visuales: Agent Builder aún puede servir mientras esté disponible.
  • Para productos mantenibles: usa el SDK de Agentes.
  • Para UI conversacional: usa ChatKit.
  • Para acceso gobernado a herramientas y datos: usa el Registro de Conectores.

Flujo práctico para construir un agente

El flujo de construcción es similar tanto si empiezas visualmente como si empiezas en código.

1. Define el trabajo del agente

Antes de escribir código, define:

  • Qué tarea debe resolver.
  • Qué entradas recibe.
  • Qué salidas debe producir.
  • Qué herramientas necesita.
  • Qué APIs externas va a llamar.

Ejemplo:

“El agente debe consultar pedidos recientes de un cliente, resumir el estado y escalar casos con errores de entrega.”

2. Modela las herramientas

La mayoría de herramientas de un agente son llamadas HTTP a APIs internas o externas:

  • Buscar pedidos.
  • Consultar un CRM.
  • Crear un ticket.
  • Leer documentación interna.
  • Ejecutar una acción en un microservicio.

Define cada herramienta con un contrato claro: nombre, parámetros, respuesta esperada y errores posibles.

3. Compón el flujo

En Agent Builder, esto se hacía conectando nodos. Con el SDK de Agentes, lo haces en código definiendo agentes, herramientas y traspasos.

La clave es separar responsabilidades:

  • Un agente para razonar.
  • Herramientas para acceder a datos.
  • Barandillas para validar seguridad y cumplimiento.
  • APIs para ejecutar acciones reales.

4. Añade barandillas de seguridad

OpenAI ofrece una capa modular de barandillas de seguridad que puede:

  • Enmascarar o marcar PII.
  • Detectar intentos de jailbreak.
  • Aplicar comprobaciones sobre entradas y salidas.
  • Ejecutarse como nodos de flujo o como biblioteca independiente.

No dejes estas validaciones para el final. Añádelas desde las primeras pruebas.

5. Conecta datos y herramientas

Puedes conectar herramientas mediante:

  • Registro de Conectores.
  • Servidores MCP.
  • Funciones definidas en el SDK.
  • APIs HTTP propias.

Aquí es donde el agente deja de ser una demo y empieza a depender de infraestructura real.

6. Prueba y evalúa

Prueba con entradas reales y casos límite:

  • Usuario válido.
  • Usuario sin datos.
  • API lenta.
  • API caída.
  • Respuesta incompleta.
  • Campos inesperados.
  • Errores de autenticación.

Aunque Evals se retire, el principio sigue siendo el mismo: necesitas medir el comportamiento del agente y validar las herramientas que usa.

7. Despliega

Puedes desplegar de dos formas principales:

  • Incrustar la experiencia con ChatKit.
  • Ejecutar tu implementación del SDK de Agentes en tu propia infraestructura.

En ambos casos, la fiabilidad dependerá de las APIs que el agente llama.

Ejemplo: una herramienta que llama tu agente

Un agente es tan bueno como las herramientas que puede usar. En la práctica, esas herramientas suelen ser APIs HTTP.

Supongamos que tu agente necesita obtener los pedidos recientes de un cliente. La herramienta podría describirse así:

{
  "type": "function",
  "name": "get_recent_orders",
  "description": "Busca los pedidos recientes de un cliente por ID de cliente.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "El identificador único del cliente"
      },
      "limit": {
        "type": "integer",
        "description": "Cuántos pedidos devolver",
        "default": 5
      }
    },
    "required": ["customer_id"],
    "additionalProperties": false
  }
}
Enter fullscreen mode Exit fullscreen mode

Cuando el modelo decide llamar a get_recent_orders, tu código recibe los argumentos, ejecuta una solicitud real a la API de pedidos y devuelve el resultado al agente.

Ejemplo de llamada HTTP:

curl https://api.your-company.com/v1/customers/cus_8842/orders?limit=5 \
  -H "Authorization: Bearer $ORDERS_API_KEY" \
  -H "Content-Type: application/json"
Enter fullscreen mode Exit fullscreen mode

El problema: el comportamiento del agente depende completamente de esa API.

Si la API:

  • Responde lento.
  • Está caída.
  • Devuelve campos con nombres incorrectos.
  • Cambia el contrato.
  • Devuelve datos inesperados.

Entonces el agente puede razonar sobre datos incorrectos o fallar en medio del flujo.

Dónde encajan las pruebas y la simulación de API

Apidog no construye agentes. AgentKit y el SDK de Agentes hacen eso.

Apidog encaja en la capa inferior: probar, simular y documentar las APIs que tus agentes llaman.

Pruebas de API para agentes

1. Simula APIs antes de que estén listas

Si el backend todavía no terminó el servicio de pedidos, puedes configurar una API simulada que devuelva respuestas realistas según el contrato acordado.

Esto te permite probar el agente sin esperar al backend.

Casos útiles para simular:

  • Cliente con pedidos.
  • Cliente sin pedidos.
  • Error 404.
  • Error 500.
  • Respuesta lenta.
  • Campos opcionales ausentes.
  • Límites de paginación.

2. Valida que cada herramienta devuelva lo esperado

Una herramienta que devuelve 200 OK con campos incorrectos puede ser peor que un fallo explícito. El modelo intentará razonar con datos inválidos.

Por eso conviene escribir casos de prueba de API para validar:

  • Código de estado.
  • Esquema de respuesta.
  • Campos obligatorios.
  • Tipos de datos.
  • Valores esperados.
  • Mensajes de error.
  • Tiempos de respuesta.

Ejemplo de validaciones para get_recent_orders:

{
  "orders": [
    {
      "id": "ord_123",
      "status": "shipped",
      "created_at": "2026-06-01T10:00:00Z",
      "total": 49.99
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Tu prueba debería asegurar que:

  • orders existe y es un array.
  • Cada pedido tiene id.
  • status usa valores conocidos.
  • created_at tiene formato válido.
  • total es numérico.

3. Gestiona entornos y secretos

Las herramientas de un agente suelen requerir claves como:

ORDERS_API_KEY=...
CRM_API_KEY=...
SUPPORT_API_KEY=...
Enter fullscreen mode Exit fullscreen mode

No pegues esas claves en el código del agente. Usa variables por entorno:

  • Desarrollo.
  • Staging.
  • Producción.

Puedes descargar Apidog y organizar tus endpoints en un proyecto para probarlos de forma aislada antes de conectarlos al runtime del agente.

4. Trata cada herramienta como una API testeable

La regla práctica es simple:

Si tu agente puede llamar una herramienta, esa herramienta necesita pruebas.

Esto aplica tanto si la herramienta llama:

  • Una API REST.
  • Un endpoint interno.
  • Un servidor MCP.
  • Un microservicio.
  • Un wrapper sobre una base de datos.

Si quieres un tutorial específico, esta guía sobre cómo probar las llamadas a herramientas de un agente de IA explica el enfoque paso a paso.

Preguntas frecuentes

¿Es gratuito OpenAI AgentKit?

Las herramientas de AgentKit se basan en el uso de la API de OpenAI. Pagas por los tokens del modelo subyacente y por las llamadas que genere tu agente.

No hay un elemento de suscripción independiente de AgentKit. El costo principal viene del uso del modelo y de la API. Consulta siempre los precios actuales en la plataforma de OpenAI, ya que las tarifas pueden cambiar.

¿Cuál es la diferencia entre AgentKit y el SDK de Agentes?

El SDK de Agentes es el framework de código para definir agentes, herramientas y barandillas de seguridad.

AgentKit era el paquete más amplio que incluía:

  • Agent Builder.
  • ChatKit.
  • Registro de Conectores.
  • Evals.
  • Integración con el SDK de Agentes.

Como Agent Builder y Evals se están retirando a finales de 2026, el SDK de Agentes es el camino más duradero para equipos de ingeniería. Esta guía del SDK de Agentes lo cubre de principio a fin.

¿Desaparece Agent Builder?

Sí. OpenAI anunció el 3 de junio de 2026 que está desaprobando Agent Builder y la plataforma Evals.

Fechas clave:

  • Evals pasa a solo lectura el 31 de octubre de 2026.
  • Agent Builder y Evals se cierran el 30 de noviembre de 2026.

ChatKit sigue disponible. Para flujos de código primero, OpenAI recomienda migrar al SDK de Agentes.

¿Puedo probar las APIs que llama mi agente de AgentKit?

Sí, y deberías hacerlo.

Cada herramienta que llama un agente tiene una solicitud, una respuesta y un contrato. Puedes:

  • Simular APIs mientras se construyen.
  • Validar respuestas contra el esquema esperado.
  • Probar errores y latencia.
  • Gestionar claves y URLs base por entorno.

Una plataforma como Apidog ayuda a cubrir esa capa para que las herramientas del agente se comporten de forma predecible antes de llegar a usuarios reales.

Conclusión

AgentKit dio a los desarrolladores una vía más rápida para crear agentes: Agent Builder para prototipos visuales, ChatKit para UI embebida, Registro de Conectores para acceso gobernado y Evals para medición.

Pero hacia finales de 2026, Agent Builder y Evals serán retirados. Para equipos de ingeniería, la apuesta duradera es construir sobre el SDK de Agentes, usar ChatKit cuando necesites una experiencia de chat e integrar conectores de forma gobernada cuando el agente necesite datos externos.

Independientemente del enfoque, la fiabilidad del agente depende de las APIs que llama. Simúlalas temprano, valida sus respuestas y organiza sus secretos por entorno. Apidog te da un lugar para probar y simular cada endpoint de herramienta del que depende tu agente antes de ponerlo en producción.

Top comments (0)