¿Será JSON Schema el contrato estándar de los agentes de IA?

Si has leído entradas anteriores de esta serie — la evolución de JSON Schema, Function Calling y MCP, Structured Output en la práctica, flujo de datos JSON en la cadena de llamadas del Agent — un patrón destaca: tanto el proveedor del modelo como la capa de protocolo, al describir «qué forma de datos intercambiar», la respuesta casi siempre es JSON Schema (o un subconjunto).

Eso plantea una pregunta natural: ¿se convertirá JSON Schema en el «Contract» estándar de los AI Agents — el lenguaje de handshake por defecto entre equipos, IDEs y proveedores cloud, como OpenAPI para REST o Protobuf para gRPC?

Partiendo de lo que «Contract» significa realmente, este artículo mapea la adopción en 2026, las brechas restantes y las decisiones de ingeniería. Spoiler: JSON Schema ya es el estándar de facto para los límites de E/S de Agent, pero no la única capa de contrato — transporte, autenticación y orquestación siguen perteneciendo a MCP, OpenAPI y Agent SDKs.

Qué significa «Contract» para los Agents

En ingeniería de software, un contrato especifica la forma, semántica y manejo de errores de los datos intercambiados. Los AI Agents son más difíciles que las APIs ordinarias porque el «llamador» incluye un modelo grande no determinista que puede omitir campos, inventar parámetros o derivar entre lenguaje natural y salida estructurada.

Así, la pila de Agent tiene múltiples capas de contrato; JSON Schema cubre principalmente la forma del payload:

Decir «JSON Schema se convierte en el Contract estándar» en la práctica significa: donde modelos y programas — o programas y herramientas — intercambian JSON estructurado, JSON Schema es la descripción por defecto. Cómo conectar y quién está autorizado es la capa superior.

Tres frentes que JSON Schema ya domina

1. Parámetros de Tool / Function Calling

Las APIs de Tools de OpenAI, Google Gemini y Anthropic Claude usan JSON Schema para parameters (o equivalente). El modelo lee description para la semántica; el Host valida arguments con el mismo Schema antes de la ejecución — coincidiendo con la cadena que desglosamos en el artículo de flujo de datos.

{
  "name": "create_ticket",
  "description": "Create a record in the ticketing system",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "description": "Ticket title" },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] }
    },
    "required": ["title"],
    "additionalProperties": false
  }
}

2. Structured Output (respuesta final del modelo)

Cuando el negocio necesita JSON en lugar de lenguaje natural, los modos Structured Output / JSON Schema de los vendors restringen tokens en tiempo de decodificación. Consulta la guía de Structured Output; para Gemini, el tutorial de JSON estructurado.

3. MCP Tool inputSchema

La especificación MCP exige que cada Tool exponga inputSchema como JSON Schema. Cuando Cursor, Claude Desktop y otros Hosts mapean herramientas MCP a Function Calling del modelo, Schema se pasa directamente o con un subconjunto ligero — la base de «escribir Schema una vez, reutilizar en IDE y modelos cloud».

Estos tres frentes cubren casi todos los límites JSON estructurados en el ciclo de vida del Agent — evidencia central de la tesis del «Contract» estándar.

Alternativas y competidores

Insight clave: ningún formato sirve de forma óptima tanto «legible por modelos» como «RPC de alto rendimiento». JSON Schema gana el enlace modelo ↔ programa; OpenAPI y Protobuf mantienen sus dominios y se conectan vía capas de conversión.

Por qué JSON Schema está ganando

1. Alineado con la distribución de entrenamiento LLM: JSON es abundante en pretraining; Schema type, enum y description actúan como hints de tipo suaves.
2. Legible por humanos y máquinas: PMs, backend y prompt engineers pueden revisar el mismo Schema — mejor para colaboración que Protobuf binario.
3. Ecosistema de validación maduro: ajv, jsonschema (Python), built-ins de APIs cloud — aún se recomienda validación en segunda pasada tras Structured Output para semántica.
4. Convergencia de vendors: 2023 tenía formatos de herramientas custom; 2024–2026 las docs de APIs mainstream estandarizan en subconjuntos JSON Schema para parámetros y respuestas.
5. «Compatibilidad descendente» de MCP y OpenAPI: MCP eligió JSON Schema en lugar de un DSL nuevo; los componentes Schema de OpenAPI 3 se reutilizan directamente.

Lo que aún no está unificado

«Estándar de facto» ≠ «totalmente unificado». Los Agents de producción aún enfrentan:

• Dialectos Schema: OpenAI strict: true es estricto en additionalProperties y cobertura completa de required; Gemini y Anthropic difieren en unions, profundidad de $ref, etc. Prueba Schema complejos contra APIs objetivo.
• Versiones Draft: draft-07, 2019-09, 2020-12 coexisten; $defs vs definitions confunde herramientas de codegen.
• Sintaxis vs semántica: Schema garantiza «priority existe y es string», no «priority=high cumple política SLA» — reglas de negocio necesitan código o extensiones como JSON Logic.
• Payloads no-JSON: imágenes, audio, URIs de archivos — Schema envuelve metadatos, no contratos de almacenamiento de blobs.
• Orquestación y estado: Agents multi-paso, human-in-the-loop, delegación sub-Agent — JSON Schema no describe máquinas de estado; LangGraph, Temporal, etc. tienen sus propios DSLs.

Esperar «un Schema para gobernar toda la pila Agent» es poco realista; esperar «todos los límites JSON estructurados usan Schema por defecto» ya es en gran medida cierto.

Señales del ecosistema 2026

Si evalúas deuda técnica: invertir en habilidades y herramientas JSON Schema ahora es más seguro que apilar prompts sobre formatos JSON privados — incluso un futuro perfil «Agent Schema 2027» probablemente será un superconjunto o subconjunto JSON Schema, no un lenguaje nuevo.

¿Se convertirá en el «único» estándar?

Respuesta en dos niveles:

Sí (alta confianza) — como Contract por defecto para E/S estructurada de Agent: parámetros de herramientas, Structured Output, MCP inputSchema, cuerpos request/response OpenAPI. Nuevas herramientas y APIs de modelos sin descripciones JSON Schema se sienten incompletas.

No (igualmente importante) — como contrato Agent full-stack único: transporte (stdio/SSE/HTTP), auth, descubrimiento de herramientas, orquestación multi-Agent, SLA y cuotas quedan con MCP, OpenAPI y política de plataforma. JSON Schema es la «capa de tipos», no la capa de «red» o «gobernanza».

┌──────────────────────────────────────────────────┐
│  Governance / auth / audit (OAuth, RBAC, logs)   │
├──────────────────────────────────────────────────┤
│  Orchestration / state (Agent frameworks, flows) │
├──────────────────────────────────────────────────┤
│  Connection / discovery (MCP, OpenAPI, gRPC GW)  │
├──────────────────────────────────────────────────┤
│  ★ JSON Schema: tool args · output · payloads ★  │
├──────────────────────────────────────────────────┤
│  Executors (HTTP, DB, files, browser automation) │
└──────────────────────────────────────────────────┘

Recomendaciones prácticas

• Única fuente Schema: define modelos de dominio en Pydantic / Zod, genera JSON Schema para OpenAI, MCP y docs — evita tres definiciones que derivan.
• Subconjunto por API objetivo: mantén «Schema compatible» para OpenAI strict, Gemini, etc., o detecta keywords no soportados en CI.
• Trata description como Prompt: description provoca fallos; revísalo como el naming de campos.
• Structured Output + re-validación en servidor: la decodificación reduce errores de sintaxis; reglas de negocio usan el mismo Schema + validadores custom.
• Versiona y changelog: cambio de Schema = cambio breaking de API; fija versiones Schema o mantén compatibilidad hacia atrás.
• Valida localmente primero: JSON Toolbox para sintaxis schema y payloads de ejemplo antes de integración.

FAQ

Resumen y próximos pasos

JSON Schema se está convirtiendo en el Contract estándar para E/S estructurada de AI Agent — no una predicción, sino una vía trazada conjuntamente por OpenAI, Google, Anthropic, MCP y Agent SDKs mainstream. No reemplazará todo OpenAPI o Protobuf, pero para el handshake modelo ↔ programa, las alternativas tienen poco margen.

Siguiente: elige un camino de negocio real (p. ej. intención de usuario → extracción estructurada → API de tickets), impulsa Structured Output y parámetros de herramientas desde un JSON Schema, valida localmente en JSON Toolbox, luego conecta MCP. Orden sugerido de la serie: visión general de evolución → Structured Output → flujo de datos → este artículo (veredicto Contract).