NEKTE: el protocolo que no quema tu contexto_

El impuesto invisible

Si usas agentes de IA con herramientas, estás pagando un impuesto que no ves.

Cada vez que tu agente hace un turno con MCP, el protocolo serializa el schema completo de todas las herramientas disponibles en la ventana de contexto. No importa si vas a usar una o veinte. El catálogo completo viaja en cada mensaje.

Con 20 herramientas, eso son miles de tokens solo en definiciones. Con 50 herramientas en un entorno enterprise, una medición publicada en febrero de 2026 registró 143.000 de 200.000 tokens consumidos en tool definitions con solo tres servidores conectados (fuente). El 72% de la ventana de contexto, quemada antes de que el modelo vea nada.

Denis Yarats, CTO de Perplexity, anunció en marzo de 2026 que la empresa deja de usar MCP internamente y vuelve a REST y CLI (fuente). No por un capricho técnico: por el coste de alimentar un protocolo que escala al revés.

Los números

Comparamos el consumo de tokens de MCP nativo, mcp2cli (que ya demostró que el lazy discovery funciona) y NEKTE en escenarios crecientes. Son estimaciones analíticas, no mediciones en producción; el detalle está en la nota "Cómo se calcularon".

A 50 herramientas, MCP quema 121K tokens por conversación. NEKTE usa 1.6K. La diferencia no es marginal — es un orden de magnitud diferente de eficiencia.

El landscape: quién hace qué

Antes de entrar en cómo funciona NEKTE, conviene entender qué ya existe y qué problema resuelve cada pieza.

MCP (Anthropic, 2024) es el estándar de facto para conectar agentes con herramientas. 10K+ servidores, 97M descargas del SDK. Funciona. Pero carga todo upfront — eager loading de schemas — y a escala el overhead es insostenible.

A2A (Google + Linux Foundation, 2025) cubre la coordinación agente-a-agente a nivel enterprise. 100+ partners, gobernanza seria. Pero no aborda eficiencia de tokens — no es su foco.

RTK (rtk-ai, 2026) comprime output de terminal antes de que llegue al contexto del agente. 17K+ estrellas en GitHub. Opera a nivel de shell, no de protocolo — capas diferentes.

mcp2cli / CLIHub (Open Source, 2026) convierte MCP servers a CLI con discovery on-demand. 96-99% ahorro en tokens de schemas. Demostró que el lazy discovery funciona, pero como hack, no como protocolo formal.

Las 5 primitivas

NEKTE (del griego nektós — unido, vinculado) se reduce a cinco operaciones. Nada más.

1. nekte.discover — Descubrimiento progresivo

Ningún agente carga schemas completos por defecto. El descubrimiento ocurre en tres niveles de resolución:

• L0 — Catálogo (~8 tok/capability): Lista de IDs + categorías + version hashes. "¿Qué sabes hacer?" en tokens mínimos.
• L1 — Resumen (~40 tok/capability): Descripción + inputs/outputs principales + cost hints. Suficiente para decidir si invocar.
• L2 — Schema completo (~120 tok/capability): JSON Schema tipado con ejemplos. Solo cuando realmente lo necesitas.

Esto es lo opuesto a MCP, que carga L2 para todas las herramientas en cada turno. Con NEKTE, un agente que solo necesita saber qué existe paga 8 tokens por capability, no 120.

2. nekte.invoke — Invocación zero-schema

Si un agente ya conoce una capability de una interacción previa, invoca directamente usando un version hash. Sin re-enviar el schema. El receptor valida el hash — si coincide, ejecuta. Si no (porque el schema cambió), responde con el schema actualizado en la misma respuesta. Cero roundtrips extra.

3. nekte.delegate — Delegación con contrato

Un agente delega una tarea completa a otro con un contrato explícito: ID, descripción, timeout, token budget, y context envelope con permisos. El receptor puede aceptar, rechazar, o negociar. No es un fire-and-forget — es un acuerdo bilateral.

4. nekte.context — Context Envelopes

Contexto compartido entre agentes con permisos explícitos: ¿se puede reenviar? ¿persistir? ¿derivar nuevos datos? Cada envelope tiene TTL y tres modos de compresión:

• none — raw, sin comprimir
• semantic — resumen optimizado por el emisor
• reference — solo un URI, datos on-demand

Esto evita el problema de "te paso todo mi contexto y que Dios reparta suerte". El emisor decide qué comparte, cómo, y por cuánto tiempo.

5. nekte.verify — Verificación de resultados

Un agente puede pedir evidencia de que un resultado es fiable: hash de integridad, muestras representativas, y metadata de la fuente (modelo usado, items procesados, errores encontrados). No es confianza ciega — es trust but verify.

El Bridge: caballo de Troya

El elefante en la habitación: hay 10,000+ servidores MCP. Nadie los va a reescribir. Y no hace falta.

Agente  <---- NEKTE ---->  nekte-bridge  <---- MCP ---->  MCP Server
                                |
                          cache + hash
                         + compression

El bridge es un proxy que habla NEKTE hacia los agentes y MCP hacia los servidores existentes. Al arrancar, conecta con los MCP servers, descarga schemas, computa version hashes, y construye un catálogo L0/L1/L2 unificado.

Desde la perspectiva del agente, 30 herramientas de 3 MCP servers diferentes aparecen como un solo catálogo con categorías semánticas. Desde la perspectiva de los MCP servers, nada cambió.

Ahorro del 90%+ con cero cambios en el backend. Adopción sin fricción.

El coste real

Pongamos números de producción. Escenario enterprise: 50 herramientas, 20 turns por conversación, 1,000 conversaciones al día.

$10,744 al mes. En overhead de protocolo. No en razonamiento, no en generación, no en nada útil. Solo en decirle al modelo qué herramientas existen, una y otra y otra vez.

Implementación de referencia

NEKTE no es solo un paper. El código vive en github.com/nekte-protocol bajo licencia MIT: el spec y los tipos, el SDK TypeScript, el bridge MCP, una CLI y un SDK Python. Los cuatro paquetes del monorepo TypeScript:

• @nekte/core — Types, Zod schemas, hashing, budget resolution, codec
• @nekte/client — Lazy discovery, zero-schema cache, budget-aware invocation
• @nekte/server — Capability registry, multi-level results, HTTP transport
• @nekte/bridge — MCP-to-NEKTE proxy con cache, hashing y compresion

Un ejemplo de cómo se ve en la práctica:

// Client -> Server con lazy discovery
const client = new NekteClient('http://localhost:4001');

// L0: "¿Qué sabes hacer?" (~24 tokens)
const catalog = await client.catalog();

// Invocar con budget limitado
const result = await client.invoke('sentiment', {
  input: { text: 'El producto es genial' },
  budget: { max_tokens: 50, detail_level: 'minimal' }
});

// Segunda invocación — zero-schema (0 tokens extra)
const result2 = await client.invoke('sentiment', {
  input: { text: 'Pésimo servicio' }
});

La segunda invocación no paga nada en overhead. El client ya tiene el version hash cacheado. Si el schema no cambió, la llamada viaja con cero bytes de metadata extra.

Posicionamiento: NEKTE no compite

Esto es importante: NEKTE no reemplaza a nadie. Complementa.

• Con MCP: MCP conecta agentes con herramientas. NEKTE conecta agentes entre sí. El bridge permite adopción inmediata sin tocar un solo MCP server.
• Con A2A: A2A prioriza enterprise governance. NEKTE prioriza eficiencia de tokens. Para startups, indie devs, y apps de alto volumen donde cada token cuenta.
• Con RTK: RTK comprime output de CLI. NEKTE comprime overhead de protocolo. Capas diferentes. Combinables.

Roadmap

La pregunta que importa

Los protocolos actuales fueron diseñados cuando la ventana de contexto era el recurso más barato. Hoy, con agentes que operan durante horas, que coordinan con otros agentes, que manejan docenas de herramientas en entornos enterprise — la ventana de contexto es el recurso más escaso.

MCP resolvió el problema de conectar agentes con herramientas. A2A resolvió el problema de coordinar agentes entre sí. Pero nadie diseñó un protocolo donde la eficiencia de tokens fuera una primitiva arquitectónica, no un afterthought.

NEKTE es una apuesta: que el futuro de los agentes no es solo más inteligentes, sino más eficientes. Que un protocolo que respeta los tokens del modelo produce mejores resultados que uno que los quema en burocracia.

El spec es abierto (nekte-protocol/protocol). El código es MIT (github.com/nekte-protocol). La tesis está sobre la mesa.

// Fuentes